1
  • I have defaultCookieDomain set to .site.com
  • I am logged into www.site.com
  • I expected to also be logged into sub.site.com (which is pointing to the same web root), but I'm not.

What am I missing?

7
  • Anything in the craft/storage/runtime/logs files about you being explicitly logged out for X reason?
    – Brad Bell
    Jul 26, 2016 at 23:36
  • I'll check, but I don't think I'm being "logged out", as I remain logged in on www.site.com.
    – Tim Kelty
    Jul 27, 2016 at 11:08
  • Nothing in the logs. Just the devMode stuff for the /admin/ request. To be clear - to test this I am just going to /admin/. While I am logged in on www.site.com but not on sub.site.com, I can log into sub.site.com (same user), and then be logged in on both.
    – Tim Kelty
    Jul 27, 2016 at 12:04
  • Do you happen to be logging in on www.site.com over https and testing on sub.site.com over http?
    – Brad Bell
    Jul 27, 2016 at 16:50
  • I suspected that and I actually tested it both ways, but got the same result. Also testing logging in at just site.com and switching to www.site.com, with .site.com as defaultCookieDomain. Same result.
    – Tim Kelty
    Jul 27, 2016 at 21:36

1 Answer 1

1

Figured this out, the appId setting was the culprit: https://craftcms.com/docs/config-settings#appId

If using this setting, you probably don't want to set it to something dynamic (as I was, e.g. md5($url)).

2
  • Ahh... that's basically the path I was going when I asked about a load balanced setup. They need to share a common appId value in order for sessions to work across multiple servers.
    – Brad Bell
    Jul 28, 2016 at 20:59
  • Yep. Embarrassingly this is what I suspected first, thought I tested it, but apparently I didn't. (╯°□°)╯︵ ┻━┻
    – Tim Kelty
    Jul 29, 2016 at 11:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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