views:

89

answers:

3

For data security and privacy reasons I want to know why Magento uses two cookies for one frontend session.

All I know is that one of them is being set in Mage_Core_Model_Cookie::set(..) and the other one in Zend_Session::expireSessionCookie(), but still I can't seem to figure out what they are used for.

I just can't think of any reason why one would need a second cookie for the same domain.

+3  A: 

I'm going to call this one vestigial code. Varien relies heavily on the Zend Framework as the underpinning for Magento, so many of the classes (Zend_Session for instance) are used as parent classes for Magento implementations.

The Varien-set cookie labeled "frontend" is namespaced for the section of the site you visit (e.g. you will have a separate "admin" cookie if you log in through the backend), whereas the Zend cookie appears to be global.

Also note that I was able to delete the Zend cookie without any apparent deleterious effects (my login session and cart remained accessible, and the cookie was not immediately replaced).

Joseph Mastey
Thanks! I just tried to delete the second cookie as well and it seems as if it is not needed at all. So I might be able to remove the this cookie completely without any side-effects.
André Hoffmann
+1  A: 

That is interesting. I just checked on an install of enterprise edition and only "PHPSESSIONID" is set, "frontend" and "admin" are missing even when logged into both. Perhaps this is something still actively being developed.

clockworkgeek
A: 

I was able to fix this by reversing the order of the session_start() call and the statement that sets the cookie in Mage_Core_Model_Session_Abstract_Varien::start(..). Those two lines now look like this:

$cookie->set(session_name(), $this->getSessionId());
session_start();

It now only creates one single cookie and it does not seem to have any side-effects.

BTW: The other cookie was not created in Zend_Session as I assumed, but instead both of them came from Mage_Core_Model_Session_Abstract_Varien::start(..).

André Hoffmann
Nice solution, but be careful editing the core files. You should (at least) create a copy in the `app/code/local` file hierarchy rather than directly editing the core. This should minimise breakage for upgrades/patches.
Jonathan Day
Yes, you are right, in fact I actually did it this way. I don't like having to hack core files, but in cases like this I guess one just doesn't stand a chance.
André Hoffmann