Cannot login after setting 301 redirect in htacccess file

[conor]

Hi Ralph,

I had set the configure files to be without the www so I turned off the Ceon module and changed both configure files to www. but I was still not able to login?

Would I have to uninstall the Ceon module?

No, I'm afraid that it's not the cause of the problem so removing it would have no effect.

Are you still having the problem.. on

http://comra-therapy.co.uk/index.php?main_page=login

things look okay?

All the best..

Conor
ceon

[ibloomdrop]

I'm having this problem as well. When I add the redirect to www in htaccess, I cannot login.

I checked configure.php and it was set wrong. I updated that to include the www but I still can't login to admin.

Other suggestions? Thanks in advance.

[ibloomdrop]

an answer somewhere else suggested to add the following to htaccess:

# to turn off session-trans-sid
php_value session.use_trans_sid 0

This actually fixed the problem. I don't know how right or wrong that is, but it's working now...

[Vger]

Your server's php.ini file SHOULD have that set to off, as in:
session.use_trans_sid = 0

So you've done the right thing.

Vger

[ibloomdrop]

ok good!

At the risk of completely changing the topic of this thread, could you point me in a good direction to understand more about this? I'm wondering if I need to make any permanent changes to the php.ini on this or my other websites...

Thank you for helping!

[Vger]

That's one of those "how long is a piece of string" questions.

What should or should not be in your php.ini file will not only depend on the server setup, but on the hosting company's default settings, and on which control panel is being used on the server.

What php.ini functions you can overwrite using .htaccess will also depend upon what your host allows to be modifed by .htaccess.

What access you have to php.in will depend upon the server control panel - for instance, with Ensim Pro each website has its own full local copy of php.ini which you can modify, but with cPanel there is one server-wide php.ini file.

What difference does this make? A lot! If you modify php.ini settings via a local php.ini file then it should be a copy of the full php.ini file, otherwise all your website's php.ini file has in it is the settings you set in it - all other server-wide settings are ignored (and that's not good for security).

So if you have no access to a full local copy of the php.ini file then ask your hosts for a full copy of the server php.ini file, which you can then modify certain settings in without losing all other settings. They may not give you a copy for security reasons.

If you can modify certain settings using .htaccess then that's fine.

Vger

[ibloomdrop]

Thank you for that... so I'll just leave it at the htaccess modifications. :)

[ozetrade]

Hi this topic seems to be the only one valid that relates to my problem. I've recently built a website (http://featherart.com.au) that is working perfectly as featherart.com.au however, I realised that all URLs didn't have the WWW in front. I decided to correct this by change these lines in the configure.php file:

// Define the webserver and path parameters
  // HTTP_SERVER is your Main webserver: eg-http://www.your_domain.com
  // HTTPS_SERVER is your Secure webserver: eg-https://www.your_domain.com
  define('HTTP_SERVER', 'http://featherart.com.au');
  define('HTTPS_SERVER', 'https://featherart.com.au'); 

To this

// Define the webserver and path parameters
  // HTTP_SERVER is your Main webserver: eg-http://www.your_domain.com
  // HTTPS_SERVER is your Secure webserver: eg-https://www.your_domain.com
  define('HTTP_SERVER', 'http://www.featherart.com.au');
  define('HTTPS_SERVER', 'https://www.featherart.com.au'); 

When I did this, the website seems to function properly using the WWW in front of all URL, but customers are unable to login to the website or create an acccount.

I'm using Zencart 1.3.9h. I would have preferred to us zen1.5.0, but I needed the Stock by Attribute mod.
I have numerous mods installed, one being CEON URI Mapping. If I turn CEON URI Mapping off, the problem still exists.

This is my current HTACCESS file content:

RewriteEngine On

# ONLY rewrite URIs beginning with /
RewriteCond %{REQUEST_URI} ^/ [NC]
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite any URIs for some, popular specific file format extensions,
#   which are not covered by main file extension condition above
RewriteCond %{REQUEST_URI} !\.(mp3|mp4|h264)$ [NC]
# Don't rewrite any URIs for some specific file format extensions,
#   which are not covered by main file extension condition above
#   Uncomment the following line to apply this condition! (Remove the # at the start of the next line)
#RewriteCond %{REQUEST_URI} !\.(3gp|3g2|h261|h263|mj2|mjp2|mp4v|mpg4|m1v|m2v|m4u|f4v|m4v|3dml)$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/myadmin [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L] 

How do I solve this problem?

[RodG]

How do I solve this problem?

First up, ensure that you made the changes to BOTH configure.php files.

Secondly, you can delete that sh1t from the .htaccess file (If that is all the file contains just delete the file).
Zencart doesn't need this kind of rewrite 'trickery', it has its own rules and methods that does what these rules are attempting to do, and as such, additional reqrites do nothing other than complicate things and cause needless problems.

Cheers
Rod

[RodG]

PS. Unrelated to your problem, but whilst checking your login problem I couldn't help notice that your shipping quotes are innacurate.

Test Item < 500gm

Your quote:
Registered Parcel $9.10 Actual cost $9.65
500gm Satchel $7.00 Actual Cost $7.20

OK, not a LOT of difference in this case, but with larger parcels the difference will probably be greater.
Good for your customers. Not so good for you.

Cheers
Rod