This is an article from NovusWeb: http://www.novusweb.com/fix-for-passing-magento-session-ids/
Fix for Passing Magento Session IDs
Author: Brett Williams
Posted November 9, 2011
Fixing Magento Session IDs
We often use shared SSL’s when building e-commerce sites. It’s a convenient way of hosting multiple stores without having to purchase separate SSL certificates for each site. Most of our e-commerce clients manage multiple stores within a single Magento or OpenCart installation. Recently, we found a problem with Magento where the customer’s session ID was not being passed successfully between their initial visit to the site and their page views after logging into the store as a registered customer. Magento was not passing the same session IDs, and this meant that a customer who had previously logged in and added items to their cart, would lose the contents of their cart after returning later and logging in. Not a great situation.
In looking at the cookies created during a session, I found that when going from an unsecure domain (i.e., http://) to a secure domain (i.e., https://), the session ID was being passed successfully and a new cookie for the secure domain was created with the same session ID as the unsecure domain. However, when the customer logged in, a new cookie was created for the secure domain with an entirely new session ID. Magento was now using the newer cookie, and whenever the customer clicked to go back into an unsecure domain page (e.g. product detail page), they were no longer logged into Magento as the unsecure domain was using its cookie/session ID, not the new session ID created at login. The solution would be to find where the new session ID was being created and prevent that from occurring.
So, I began digging into the code to see if I could find where Magento was creating the new session.
In app/code/core/Mage/Customer/Model/session.php, I found this at lines 177-189 (Magento CE 1.5.1):
public function login($username, $password)
{
/** @var $customer Mage_Customer_Model_Customer */
$customer = Mage::getModel('customer/customer')
->setWebsiteId(Mage::app()->getStore()->getWebsiteId());
if ($customer->authenticate($username, $password)) {
$this->setCustomerAsLoggedIn($customer);
$this->renewSession();
return true;
}
return false;
}
My solution was to comment out the line: $this->renewSession():, so that Magento would not create a new session when the customer logged in. The changed code looks like this:
public function login($username, $password)
{
/** @var $customer Mage_Customer_Model_Customer */
$customer = Mage::getModel('customer/customer')
->setWebsiteId(Mage::app()->getStore()->getWebsiteId());
if ($customer->authenticate($username, $password)) {
$this->setCustomerAsLoggedIn($customer);
//$this->renewSession();
return true;
}
return false;
}
So far in our testing, everything is working just fine, and the customer’s session is being retained between domains. Now, before you rush to change this core file, do the following:
Backup your databases (you should always do this before making any modifications).
Build the following directory hierarchy: app/code/local/Mage/Customer/Model/.
Put a copy of session.php into this new directory.
Comment out the appropriate line, shown above, and save your file.
By putting your modifications into the app/code/local directory, you’re telling Magento to use these files instead of the core files. More importantly, you’re preventing the loss of your modifications should you update Magento in the future.
It also provides a convenient way to store and manage your code modifications, as you only need to keep modified files in the app/code/local directory.
Be sure to leave a comment if you know of a more elegant solution, or if you find this works or doesn’t work for you.
You write in your question:
they face the issue that they can't login and no error message is displayed
This is a good indicator that you have a cookie issue. This error pattern is just that the login was successful for Magento (username and password did match) but there is no session to keep the successful login. Hence the login page is displayed again with no error message.
My research leads me to believe that this is a cookie problem, stemming from the fact that the example.com cookie is set, and then causes problems when the user is redirected to sub.example.com
You're pretty close, here is what happens.
- You have not specified a cookie-domain for both sites.
- Not specifying a cookie-domain means, the browser when it receives a cookie will file it under the domain of the request.
- The login will then set the session ID to example.com. In that session the user is logged in.
- After redirect a new session ID will be set to sub.example.com. In that new session the user is not logged in.
- If the browser requests a page under sub.example.com then, it needs to decide which of the two same-named cookies for the session is to be taken: The one for example.com or the one for sub.example.com? And if both in which order? Answer: You can't say as browsers vary here.
- And not only the browser, also the server needs to decide here. So what happens here? Answer: For PHP, it can't handle two cookie values with the same name. It only takes the first one. And which one that is, you can't say (see browsers).
- So this is already flawed. No wonder it won't work until you start fresh and remove existing cookies under both domains.
This is what you experienced and hopefully the listing sheds some light.
So how to handle this in your case?
My suggestion would be to configure the cookie domains as "example.com
" for all the two sites in your case. That means that both sites will share their session which I assume is what you're looking for.
Not setting the cookie-domain in the first place was causing you the trouble then as this resulted in two different cookie domains, but you want to share the session cookie, so you want one session cookie and not two.
Also: Set the cookie to HTTP only so it can't be spoofed in a browser-script.
Changes in your configuration:
- Cookie domain: example.com (was: (empty))
- Use HTTP only: Yes (was: No)
Best Answer
Sounds like wrong settings in cookie domain.
In short, the problem are two cookies with the same content, and magento/apache/php doesn't know which one to use.
I think it isn't important wether frontend or backend, have a look on this blog entry by philwinkle about the problem:
http://blog.philwinkle.com/i-cant-login-to-magento-admin/
Images stolen from philwinkle' blogpost, if it is not ok, tweet me.