The problem

A large site uses separate instances of Magento for different geographic regions so the businesses are isolated. Example:

  • site.com
  • north.site.com
  • south.site.com
  • east.site.com
  • west.site.com

Users may visit the root + regional sites, log in directly on a regional site, or log into (site.com) with their regional credentials (we have an authenticator + redirect in place).

Some are unable to login after previously being able to, and get no error feedback. We can replicate the fault which is having two cookies with the same name but different domains. Example:

  • Name: frontend, Domain: .site.com
  • Name: frontend, Domain: .north.site.com

Deleting the cookies resolves the issue in most browsers. The cookies seem to get stuck in some browsers and we're stumped other than waiting for them to expire which sucks for users.

What we tried

Initially our config was blank (as below) for all sites. This triggered the problems. As I understand it, we need to set the domain explicitly for all sites to ".site.com" so only one cookie can exist with that name/domain.

Does that resolve Magento's issue of not knowing which "frontend" cookie is the correct one — or is there a preferred config?

The Question

What is the correct cookie config in Magento's admin for a multi-domain setup?

See: "System > Config > Web > Session Cookie Management"

Magento cookie config

  • I have the exact same problem. With blank config, my subdomain could not login to admin. That's because of cookies (obviously). Clearing all browser cookies from the main domain allowed logging into the subdomain, but as soon as you would log into the main domain, the subdomain admin would redirect to the login screen and logging in again would be impossible. Commented Jun 26, 2015 at 18:52
  • Please, write solution. I have same problem...
    – Sylon
    Commented Oct 31, 2016 at 9:32
  • This fixed my problem. magento.stackexchange.com/questions/71283/…
    – Qiong
    Commented Mar 6, 2017 at 8:07

2 Answers 2


We had to do something similar recently:

  • Cookie Path: /
  • Cookie Domain: .site.com

That did the trick in our case.

  • Right, that's what we thought. Actual docs would've come in handy here... Commented May 18, 2015 at 16:02
  • Did you use that setting for the main domain installation only, or for subdomain installations only, or for all installations? Commented Jun 26, 2015 at 18:54
  • Does not work. I tried using these settings (Cookie Path and Domain) on only the main domain installation. Then I tried using it both the main domain and a subdomain (e.g. http;//north.site.com). Then I tried changing the subdomain Cookie Domain to .north.site.com (with a dot in front of the subdomain). Then I tried removing the dot in front of the subdomain Cookie domain (north.site.com). I am shooting in the dark and hitting nothing. Nothing works. Now main domain and subdomain won't allow admin login at all. Cleared cache, went back to default cookie values. Commented Jun 26, 2015 at 23:46
  • 1
    Buttle, did you also cleared your browser cookies between each step ? Commented Jun 29, 2015 at 17:23
  • 1
    Hello! Please, write solution. I have same problem. Need write .site.com only for site.com storeview?
    – Sylon
    Commented Oct 31, 2016 at 12:41

We had something similar to this getting sessions to be shared between a Wordpress instance and a Magento instance. Our solution was (as you say) to set the domain to .site.com, but we also had massive grief because we didn't immediately clear the sessions data.

  • Yeah, that's the issue we're facing now. Some browsers make cookies very sticky and users can't clear them. Just waiting till they expire (ugh). Commented May 18, 2015 at 16:03
  • Things will be kinda janky until then. My boss got an email from the CEO of the client in question complaining that he'd suddenly been logged out. Changing things like this is perilous. At least you know now. Commented May 19, 2015 at 17:20
  • Hello! Please, write solution. Need write .site.com only for site.com storeview?
    – Sylon
    Commented Oct 31, 2016 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.