Odd Admin login problem 1.5.0

Hi Melanie,

Have you had any time to test these variants?

Thanks

okay, I verified these findings. Also spoke with the nix admin for our rack and he said he thinks* that it may be because of using mod_ssl over open_ssl for certificate install. But.... we do that for compatibility for MACs and XP machines to be able to use the lesser key, they cannot handle the full 256b key.

open ssl is present and running all negotiations, we just install the mod_ssl version of ssls for compatibility then open SSL handles all of the negotiations but can fall back to straight mod_ssl if needed.

~Melanie

Hi Melanie,
A few more research questions for you :)

• When you did the testing with session_set_cookie_params() adjustments earlier, did it seem to you that the problem was with the 4th parameter ($secureFlag) or with the 5th param? Sorry, I can't tell by your last post whether you were able to make any determinations about that (or give me individual test results so I can make those determinations).
• Is there any commonality in versions of Apache where this is happening?
• And with versions of mod_ssl?
• Who was the certificate issuer for these sites that are having these problems?

We found a tiny bug report at Apache about potential problems with some versions of mod_ssl having a problem turning on secure mode with certain certificates ... so I'm trying to isolate whether what you're reporting is related to that or not.

$secureFlag

All Apache various versions 2.2.22 or higher.
mod_ssl 2.8.30
OpenSSL 0.9.8m

All COMODO 256b, with 4096 keys

This may be a related post: http://www.zen-cart.com/showthread.php?193599-Configure-php-with-SSL-Shared

I actually think it's related to strict Cookie IP validation on our servers. We don't use any shared SSLs.
I suspect that the IP tied to the "old" cookie before I am forced to create a new password due to swapping to SSL is not released in Zen Cart

mprough:

I actually think it's related to strict Cookie IP validation on our servers. We don't use any shared SSLs.
I suspect that the IP tied to the "old" cookie before I am forced to create a new password due to swapping to SSL is not released in Zen CartInteresting thought. I looked it up, hoping to find something that would explain the possibilities further. But ...
Judging from the following description, I don't think this is the issue. Why would the IP be changing at all?> Cookie IP validation

Validate the IP addresses used in all cookie-based logins. This will limit the ability of attackers who capture cPanel session cookies to use them in an exploit of the cPanel or WebHost Manager interfaces. For this setting to have maximum effectiveness, proxydomains should also be disabled. Strict validation requires the current IP address and the cookie IP address to exactly match. Loose validation only requires they are in the same /24.If you're using non-shared SSL, then unless you're using a completely different "server" to proxy all SSL activity, the SSL cert is tied to the same IP as the non-SSL side, and thus any IP-matching would not be a problem.

Hi Melanie,

We've been talking more about this topic internally, and wondered if it's possible to get access to a simple test account on one of your servers. The idea being that we can then test what challenge/response stuff is happening between ZC and your server's config.

And, if this is possible, then if you don't mind also installing your "packaged" ZC install in that account too, it would be appreciated.

You can put a bogus domain name into the account, and we'll just access it using a hosts. file entry for DNS lookup.

Does this sound do-able?

Thanks,
Chris

Sure can, but even out of the box I have the issue. I will PM details once setup

I am finishing up 2 install for you guys.

/fresh/ is just a straight install
/mods/ is our starting backup that we begin shops with. This copy is from 8/7/12 and a new one is created when an installed mod or the software is upgraded. You will find a folder called resources which contains the normal mods we install as well for reference.

The SSL is installed for the domain, because you need it to see the issue. The issue:

When setting admin configure as follows you cannot login when SSL is enabled:

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

The issue is seen when set like that... and when switching from to to SSL in the configs.

Be a few minutes and I will PM full access

~Melanie

Hi Melanie,

Just following up on this old discussion. Wondering whether you've encountered any other instances where you've had to make any of these sorts of changes to work on any particular server, using v1.5.1.

1 other webhost, inmotion =P

Our new servers have been fine w/o issue since we changed platforms and size and such

Okay. If it's still happening, I'd be curious if you can replicate the problem using v1.6.0 (you can download a zip from https://github.com/zencart/zencart/tree/v160 )