Odd Admin login problem 1.5.0

DrByte:

mprough:

DrByte:

mprough:

Okay... so I am finishing up about 5 1.5.0 stores and moved the first one in to it's permanent account.

~Same server
~Switched on SSL and renamed admin
~update pw for SSL when prompted

Locked out.... Security error when trying to login

How can i clear the lockout, I wasn't even done setting up when it timed me out LOL

~Melanie
"There was a security error when trying to login." appears when any of the following occurs:

• invalid username
• invalid password
• expired password
• locked-out account (too many failed logins locks the account for 15 minutes)
• securityToken invalid (which could be malformed HTML, caused by altered PHP code, or session cookie isn't being set properly either because of a PHP session configuration issue, or because the cookie is damaged since switching between NON-SSL and SSL)

Okay i did:

Re-import the whole database

Clear all cookies and cache, rebooted

Tried from a new my on a different IP

Login info is correct, works on the dev site.

So, I turn OFF SSl and log right in.

Suggestions? This sucks :(

Shared SSL? or dedicated?
Is the site using a domain name, or just an IP address?

There are known issues using shared SSL with different domain names than that of the store. And there are known issues with using an IP address as the HTTP_SERVER address.

Also, if you set both the HTTP_SERVER and HTTPS_SERVER to an https:// address, and clear your cookies, does the problem persist?

And the password you entered that let you in after you turned off SSL, was that the new password you entered after it prompted you for a new one when you turned ON the SSL? Or the one you used before turning on SSL initially?

And what happens if you use the password-reset method described in this article? https://www.zen-cart.com/tutorials/index.php?article=2
Does this affect all admin users in the database, or just that one?

Shared SSL? or dedicated?
Dedicated

Is the site using a domain name, or just an IP address?
aboutthetoys.com

There are known issues using shared SSL with different domain names than that of the store. And there are known issues with using an IP address as the HTTP_SERVER address.
SSL is for correct hostname

Also, if you set both the HTTP_SERVER and HTTPS_SERVER to an https:// address, and clear your cookies, does the problem persist?
Yes

And the password you entered that let you in after you turned off SSL, was that the new password you entered after it prompted you for a new one when you turned ON the SSL? Or the one you used before turning on SSL initially?
Set after prompt for change to SSL

And what happens if you use the password-reset method described in this article? https://www.zen-cart.com/tutorials/index.php?article=2
Prompted to rest the temp pass, successfully did so. Then cannot login. No error same as ever time, just no login happens. No logged error, on scre in cache or even in email as failed.

Does this affect all admin users in the database, or just that one?
All

I am open to server issues, we have dedicated servers and I can do whatever we need, but the other 1.5.0 stores that did not switch to SSL are fine. So i'm puzzled.

Thanks
Melanie

Hi Melanie,

In /admin/includes/functions/admin_access.php and /admin/login.php there are references to ERROR_SECURITY_ERROR, where $message or $error[] are set to that constant's value.
Can you edit each of those 3 instances and add some unique text after the constant, so we can narrow down which instance is triggering the problem?

ie:
$message = ERROR_SECURITY_ERROR . '-1';
$error[] = ERROR_SECURITY_ERROR . '-2';
$message = ERROR_SECURITY_ERROR . '-3';

Then trigger the error message the same way you've been replicating it previously, and report back which case is triggered based on the displayed error message.

Today I have had no errors. I made the changes, but both admin accounts, just do not login. no error in email, cache or screen.

Here is config

/**

• WE RECOMMEND THAT YOU USE SSL PROTECTION FOR YOUR ENTIRE ADMIN:
• To do that, make sure you use a "https:" URL for BOTH the HTTP_SERVER and HTTPS_SERVER entries:
  */
  define('HTTP_SERVER', 'https://domain.com');
  define('HTTPS_SERVER', 'https://domain.com');
  define('HTTP_CATALOG_SERVER', 'http://domain.com');
  define('HTTPS_CATALOG_SERVER', 'https://domain.com');

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

~
Thanks
~Melanie

"no login, with no error message" has always been symptomatic of session problems ... ie: cookie mismatch or failure to start a session.

Tests:

• does storefront allow login? Can you add anything to shopping cart, either before or after login?
• if using NON-SSL, does it work properly suddenly?
• did you run fix-cache-key.php after moving the site to the new server (ie: instead of dev machine), so that the SESSION_WRITE_DIRECTORY key is set properly to the correct path of the server the site is running on?
• try changing the values for SESSION_ADD_PERIOD_PREFIX or SESSION_USE_ROOT_COOKIE_PATH between False and True. (the PATH setting is normally False, and the PREFIX setting is normally True ... try changing the PREFIX one first, by editing the configuration_value in the configuration table, and flush your cache before testing again)

• does storefront allow login? Can you add anything to shopping cart, either before or after login?
  Yes, no problems on the front end at all

• if using NON-SSL, does it work properly suddenly?Yes
• did you run fix-cache-key.php after moving the site to the new server (ie: instead of dev machine), so that the SESSION_WRITE_DIRECTORY key is set properly to the correct path of the server the site is running on?
  Yes
• try changing the values for SESSION_ADD_PERIOD_PREFIX or SESSION_USE_ROOT_COOKIE_PATH between False and True. (the PATH setting is normally False, and the PREFIX setting is normally True ... try changing the PREFIX one first, by editing the configuration_value in the configuration table, and flush your cache before testing again)
  Tried all of those... in all configurations.

I got in, here's how. i changed the following from:

define('HTTP_SERVER', 'https://domain.com');
define('HTTPS_SERVER', 'https://domain.com');
define('HTTP_CATALOG_SERVER', 'http://domain.com');
define('HTTPS_CATALOG_SERVER', 'https://domain.com');

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

to

define('HTTP_SERVER', 'http://domain.com');
define('HTTPS_SERVER', 'https://domain.com');
define('HTTP_CATALOG_SERVER', 'http://domain.com');
define('HTTPS_CATALOG_SERVER', 'https://domain.com');

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

And now it works perfectly....

Odd stuff. Pretty sure my session handling is correctly configured on our servers. We set them up specifically for Zen Cart. The config we are running is years in the making to get it just right for security. But I am open to suggestions, comments to avoid this in the future.

~Melanie

I don't understand why it wouldn't work using full SSL on the entire admin. ie: HTTP_SERVER having a https: address.
This is the first I've seen a problem like that. In any ZC version.

Could it be a symlink issue with your SSL configuration?

SSL checks out correctly.

Common names 	aboutthetoys.com
Alternative names 	aboutthetoys.com www.aboutthetoys.com
Prefix handling 	Both (with and without WWW)
Valid from 	Tue Dec 14 00:00:00 UTC 2010
Valid until 	Thu Dec 13 23:59:59 UTC 2012 (expires in 10 months and 9 days)
Key 	RSA / 2048 bits
Signature algorithm 	SHA1withRSA
Server Gated Cryptography 	No
Weak key (Debian) 	No
Issuer 	PositiveSSL CA
Next Issuer 	    UTN-USERFirst-Hardware   TRUSTED
Chain length (size) 	3 (3770 bytes)
Chain issues 	None
Validation type 	Domain-validated (DV)
Revocation information 	CRL, OCSP
Revocation status 	Good (not revoked)
Trusted 	Yes

Most bizarre.

Updating this with some info.

On 5 different webhosts including Hostgator, BlueHost, DreamHost, HostDime and HostMonster.

All Linux running PHP 5.2.17 or better.

This problem perpetuates in any change of the configure files.

Issue 1, changed to SSL and changed from dev domain to final location of live site

Issue 2, upgraded old database in the 1.5.0 fresh file framework to allow only porting necessary tables in to a fresh rebuild. Once switched back to the original database in the configs... cannot login.

Issue 3, move dev site from /dev/ folder to live root... cannot login.

Issue 4, moved entire dev site to it's home. Changed domains ONLY in config files and cannot login.

**
Symptoms:**

NO errors are shown, nor logged.

NO failure is logged for the admin user in table admin.

NO attempt is logged for the admin user in table admin.

The failure is NOT IP based and seems to apply to all.

Clearing browser cookies, temp files, rebooting, etc as well as running fix cache key and dumping admin logs and sessions DOES NOT resolve the issue.

Live headers shown below for the most recent one. Note that the password and user is picked up in plain text in live headers and no error is shown, but a redirect is executed.

http://domain.comlogin.php?camefrom=index.php

POST /login.php?camefrom=index.php HTTP/1.1
Host: domain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://domain.com/login.php?camefrom=index.php
Cookie: zenAdminID=259ae033f318c26f6315ade4a7fe8e5c
Content-Type: application/x-www-form-urlencoded
Content-Length: 130
admin_name=handle&admin_pass=Pooy7565!&securityToken=ca53bb31205e1df0d767f69637786b34&action=doca53bb31205e1df0d767f69637786b34
HTTP/1.1 302 Moved Temporarily
Date: Wed, 22 Feb 2012 14:45:21 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://domain.com/index.php
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
----------------------------------------------------------
http://domain.com/index.php

GET /index.php HTTP/1.1
Host: domain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://domain.com/login.php?camefrom=index.php
Cookie: zenAdminID=259ae033f318c26f6315ade4a7fe8e5c

HTTP/1.1 302 Moved Temporarily
Date: Wed, 22 Feb 2012 14:45:21 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://domain.com/login.php?camefrom=index.php
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
----------------------------------------------------------
http://domain.com/login.php?camefrom=index.php

GET /login.php?camefrom=index.php HTTP/1.1
Host: domain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://domain.comlogin.php?camefrom=index.php
Cookie: zenAdminID=259ae033f318c26f6315ade4a7fe8e5c

HTTP/1.1 200 OK
Date: Wed, 22 Feb 2012 14:45:22 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 1047
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

This most recent one is one of our own servers... I am fully open to suggestions and have already disabled Security Tokens as a test with no avail.

~Melanie

mprough:

**
Symptoms:**
NO failure is logged for the admin user in table admin.

NO attempt is logged for the admin user in table admin.
That tells me you've got session problems, since none of the admin logging will happen if there's no session started.

So, since sessions are based on only a few factors, we're back again to the issues I've mentioned before:

1. session cookies.
   session cookies must be able to identify based on the URL
   So, either the session cookie isn't getting set or it's not matching domain names.
   Some browsers want the dot-prefix. Some don't care.

2. session directory
   If the session_write_directory is set to an invalid path or an unwritable path then you may have problems.

3. sessions table in database
   If the table is damaged then you'll have problems.
   I've never seen it necessary, but maybe you'll need to truncate the table when you're changing your config files

4. apache vhost misconfiguration
   if the ssl configuration isn't properly set up then you may be getting background domain name mismatches that are causing cookie confusion

5. php session support is misconfigured
   if this were the case then you'd likely be getting no sessions at all, regardless of http vs https

Well we know from before the SSL is okay, what do you recommend in setting

session cookies must be able to identify based on the URL
So, either the session cookie isn't getting set or it's not matching domain names.
Some browsers want the dot-prefix. Some don't care.

I've rarely had any problems with the default settings, and never on our own servers. We've seen occasional issues with IE wanting the dot-prefix setting switched for a small handful of merchants hosting on seemingly oddball servers.

We've also seen problems when running the site from an IP address instead of an FQDN in the HTTP_SERVER or HTTPS_SERVER definitions. And, since that's never a realistic scenario for a "live" site, it's basically moot.

The code in /admin/includes/init_includes/init_sessions.php for $secureFlag isn't new to 1.5.0 (was introduced in 1.3.9), but I'm wondering what happens if you were to test changing this:if (PHP_VERSION >= '5.2.0') { session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : ''), $secureFlag, TRUE); } else { session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : ''), $secureFlag); }to just this:```
session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : ''));

Does it have any impact on the symptoms you're experiencing?

That did the trick on the existing problematic site. I also switched a new site to SSL, the problem was the same could not login after password change for the SSL... made your change and logged right in.

Thanks a bunch

~Melanie

Puzzling.

Melanie,

Would you mind testing whether adding the parameters back works in any combination at all?

ie:
TRUE, TRUE
TRUE, FALSE
FALSE, TRUE
FALSE, FALSE (you already tested this case by the omission of the parameters altogether)

So, between the last 2 closing )) I gave you earlier, try adding each of these combinations, and test.

I'm trying to narrow down the issue to being whether your symptoms are related to the SecureOnly flag or the HttpOnly flag, or both.

Much appreciated.

mprough:

On 5 different webhosts including Hostgator, BlueHost, DreamHost, HostDime and HostMonster.
I just tested the original v1.5.0 code with a site on HostGator, and have no problems with it.
Shared SSL in this case though.

So, still searching for the needle in this proverbial haystack, unable to duplicate the symptoms you reported. Argh.

Recap:

When setting both admin urls to https

define('HTTP_SERVER', 'https://domain.com'); define('HTTPS_SERVER', 'https://domain.com');

Cannot login, no error, no failed logins nothing.

Setting

session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : ''));

CAN login with both https admin urls

Setting

session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : 'TRUE, TRUE'));

CAN login with both https admin urls

Setting

session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : 'TRUE, FALSE'));

CAN login with both https admin urls

Setting

session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : 'FALSE, TRUE'));

CAN login with both https admin urls

Restest original file, fail cannot login with both https admin urls

Test just

session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : ''), $secureFlag, TRUE);

Cannot login with both https admin urls

Test just

session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : ''), $secureFlag);

Cannot login with both https admin urls

I would be happy to provide you any info you need. I have tested all of our servers with the same issue.

The HG server we checked also the same, but also dedicated.

These servers are running PCI scans regular without a single fail.... even the non fails are near zero.
Maybe it's the cipher?

ECDHE-RSA-AES256-SHA384:AES256-SHA256:AES256-SHA256:RC4:HIGH:!MD5:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!DH:!ADH:!EDH:!AESGCM

as opposed to the standard

ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP:!kEDH

We changed because we were still getting fails for the level of encryption allowed.

Quote:
Setting

session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : 'TRUE, FALSE'));

CAN login with both https admin urls
Quote:
Setting

session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain : 'FALSE, TRUE'));

CAN login with both https admin urls
Did you literally put the code in the file exactly as you quoted here? If so, the syntax is incorrect, and thus needs retesting.

ie:
bad:
session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain** : 'FALSE, TRUE'));**
good:
session_set_cookie_params(0, $path, (zen_not_null($cookieDomain) ? $domainPrefix . $cookieDomain** : ''), FALSE, TRUE);**
... and all the other variants I suggested