admin password problem

[sadie]

I upgraded my site to 1.5, changed the admin cofigure files to allow ssl in the admin in order to install the authorize.net module.

1. I still cannot install authorize.net (AIM), it still says:
ALERT: For security reasons, Installation of this module is disabled until your Admin is configured for SSL.

2. Every time I log on as admin, It forces me to reset the password. Here is the error:

Note: Your password has expired because your site has changed from non-SSL (less secure) to being SSL-protected (more secure). Changing your password under SSL is an important step to greater security. Sorry for any inconvenience. Standard password expiry rules apply.

I found another post about issue 2 above in June, but there were not any replies.

Sadie

[DrByte]

Simply set your admin HTTP_SERVER and HTTPS_SERVER to BOTH be an https URL, as explained here: http://www.zen-cart.com/content.php?...alled-zen-cart

And make sure the file actually gets uploaded (it won't be uploaded if the file is read-only).

Under normal circumstances (ie: a traditionally configured server with traditional correctly installed SSL certificate, and no URL-rewriting or redirects in .htaccess), none of your symptoms in your "#2" would persist beyond the first instance of requiring the new password.

[sadie]

I've already made those changes. After the changes the 1.3 store works fine, but the other 1.5 store I am building gets errors: Here is my admin configure file, with my website removed:

define('HTTP_SERVER', 'https://www.____.net');
define('HTTPS_SERVER', 'https://www.##########.net');
define('HTTP_CATALOG_SERVER', 'https://www.##########__.net');
define('HTTPS_CATALOG_SERVER', 'https://www.##########__.net');

// secure webserver for admin? Valid choices are 'true' or 'false' (including quotes).
define('ENABLE_SSL_ADMIN', 'true');

// secure webserver for storefront? Valid choices are 'true' or 'false' (including quotes).
define('ENABLE_SSL_CATALOG', 'true');

[DrByte]

Here's how it works:

AIM expects that the URL being used at the point of accessing the module's installation screen must be an https URL.
If it's not https, then you'll see the message you're reporting.

The password reset because of changing from NON-SSL to SSL is triggered by logging into the Admin over NON-SSL and then later accessing over SSL.
So, if you're triggering that, then it means your admin has let you log in without using only https URLs.

Thus, that tells me you're flipping back and forth between modes.
So, this suggests that you're using multiple configure.php files when accessing the same database. This would be a problem with your development environment.

[sadie]

Here's how it works:

AIM expects that the URL being used at the point of accessing the module's installation screen must be an https URL.
If it's not https, then you'll see the message you're reporting.

The password reset because of changing from NON-SSL to SSL is triggered by logging into the Admin over NON-SSL and then later accessing over SSL.
So, if you're triggering that, then it means your admin has let you log in without using only https URLs.

Thus, that tells me you're flipping back and forth between modes.
So, this suggests that you're using multiple configure.php files when accessing the same database. This would be a problem with your development environment.

Your were right. When I watched my admin clicks, every other click was non-SSL. I'm not sure why there was a problem, since I made changes to each the secure and non-secure admin configure files when I made changes. I have a copy of my entire store in the secure (SSL)section of my hosting account. I deleted the configure file from the secure section, and then copied the configure file from the non-secure section over to the secure section, and the problem was fixed.

[DrByte]

I have a copy of my entire store in the secure (SSL)section of my hosting account. I deleted the configure file from the secure section, and then copied the configure file from the non-secure section over to the secure section, and the problem was fixed.

I STRONGLY suggest that you work with your hosting company to find a way to symlink your "secure" section to look directly at your non-secure section. There's NO good reason to have to separate them on contemporary webservers nowadays. If your host can't do that, then you've got a lotta work to do every day when trying to keep things in sync between the two places. It's a very outdated server architecture, and not well-suited for ecommerce or any other dynamically-driven site.