<p>Figured this out, the <code>appId</code> setting was the culprit: <a href="https://craftcms.com/docs/config-settings#appId" rel="nofollow">https://craftcms.com/docs/config-settings#appId</a></p>

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

CC BY-SA 3.0
2016-07-28T20:59:20.250Z
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
CC BY-SA 3.0
2016-07-29T11:16:47.920Z
Yep. Embarrassingly this is what I suspected first, thought I tested it, but apparently I didn't. (╯°□°）╯︵ ┻━┻
Tim Kelty
CC BY-SA 3.0
2016-07-28T11:58:35.440Z
2016-07-28T11:58:35.440Z
Tim Kelty
<ul>
<li>I have <code>defaultCookieDomain</code> set to <code>.site.com</code></li>
<li>I am logged into <code>www.site.com</code></li>
<li>I expected to also be logged into <code>sub.site.com</code> (which is pointing to the same web root), but I'm not.</li>
</ul>

<p>What am I missing?</p>

CC BY-SA 3.0
2016-07-26T23:36:44.927Z
Anything in the `craft/storage/runtime/logs` files about you being explicitly logged out for X reason?
Brad Bell
CC BY-SA 3.0
2016-07-27T11:08:00.153Z
I'll check, but I don't think I'm being "logged out", as I remain logged in on `www.site.com`.
Tim Kelty
CC BY-SA 3.0
2016-07-27T12:04:36.680Z
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
CC BY-SA 3.0
2016-07-27T16:50:56.570Z
Do you happen to be logging in on `www.site.com` over https and testing on `sub.site.com` over http?
Brad Bell
CC BY-SA 3.0
2016-07-27T21:36:27.957Z
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
CC BY-SA 3.0
2016-07-27T23:47:37.740Z
On a load balanced setup, maybe?  Just did a test locally with craft.dev and sub.craft.dev and the only thing I did was change `defaultCookieDomain` to `.craft.dev`. Logged into craft.dev and sub.craft.dev CP loaded fine. Can you verify in your browser's inspector that the cookie domain is being set to `.site.com`?
Brad Bell
CC BY-SA 3.0
2016-07-28T11:47:37.247Z
Weird, I just tried the same thing locally (MAMP) and it still didn't work. You think there might be another config setting that could be interfering? Next I'll try with just a straight vanilla Craft install.
Tim Kelty
<session><subdomain>
How do I preserve user sessions across subdomains?
# How do I preserve user sessions across subdomains?

(Asked by: username_0 on 2016-07-26)

* 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?

**Tags:** session, subdomain
> **Comments:**
> **username_1**: Anything in the `craft/storage/runtime/logs` files about you being explicitly logged out for X reason?  
> **username_0**: I'll check, but I don't think I'm being "logged out", as I remain logged in on `www.site.com`.  
> **username_0**: 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.  
> **username_1**: Do you happen to be logging in on `www.site.com` over https and testing on `sub.site.com` over http?  
> **username_0**: 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.  
> **username_1**: On a load balanced setup, maybe?  Just did a test locally with craft.dev and sub.craft.dev and the only thing I did was change `defaultCookieDomain` to `.craft.dev`. Logged into craft.dev and sub.craft.dev CP loaded fine. Can you verify in your browser's inspector that the cookie domain is being set to `.site.com`?  
> **username_0**: Weird, I just tried the same thing locally (MAMP) and it still didn't work. You think there might be another config setting that could be interfering? Next I'll try with just a straight vanilla Craft install.  

---

## 1 answers

### Answer by username_0 on 2016-07-28. Score: 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)`).

> **Comments:**
> **username_1**: 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.  
> **username_0**: Yep. Embarrassingly this is what I suspected first, thought I tested it, but apparently I didn't. (╯°□°）╯︵ ┻━┻  

---

