<p>You could write a plugin and put some code in it's <code>init()</code> method which would get fired on every request.</p>
<p>In the <code>init()</code> method, that plugin could call <code>craft()-&gt;httpSession-&gt;getCookieParams()</code> (which is just a wrapper for PHP's <a href="https://www.php.net/manual/en/function.session-get-cookie-params.php" rel="nofollow noreferrer">session_get_cookie_params</a>.</p>
<p>From there you could check the existing session cookie domain and if it's <code>site1.domain.com</code>, nuke the cookie.  The request should automatically generate a new session cookie with the <code>.domain.com</code> domain set.</p>

CC BY-SA 3.0
2016-10-17T10:25:10.010Z
Except, by your own admission, [plugins can't listen for Yii's `onBeforeRequest` event because they haven't been initialised when it fires](http://craftcms.stackexchange.com/a/1731/153). Which leaves me with `onBeforeLogin`. Will this work for returning users who have used the 'remember me' feature and are logged back in via their cookie? Or will it only fire when users actually login using the login form?
Steve Rowling
CC BY-SA 3.0
2016-10-17T17:14:45.037Z
Doh, you're right. Updated the answer, but I think the plugin's `init()` would be the right place, then.
Brad Bell
CC BY-SA 3.0
2016-10-23T16:21:25.813Z
An update on this. It turns out that for old visitors, Craft was picking up the old CSRF cookie, rather than the new one, which resulted in CSRF errors when users tried to submit forms (including trying to login). This is because I ended up with two CSRF cookies, one for `site.domain.com` and one for `.domain.com`. I was also still having problems with the session cookie and unsuccessfully tried various tricks to delete the old cookies. I've ended changing the `phpSessionName` and `csrfTokenName` config settings, which works as it creates new cookies and ignores the old ones.
Steve Rowling
CC BY-SA 3.0
2016-10-16T16:41:20.033Z
2016-10-17T17:14:16.590Z
2023-11-17T20:38:18.640Z
Brad Bell
<p>I'm in the process of adding a second site to a Craft installation using custom locales. The two sites will be accessed on different sub-domains, e.g. <code>site1.domain.com</code> and <code>site2.domain.com</code>.</p>

<p>I need to ensure that logged in users can access both sites.</p>

<p>When I developed the first site, I didn't know that there would be a requirement to add a second site at a later date, so I set the <code>defaultCookieDomain</code> config setting to <code>site1.domain.com</code>.</p>

<p>Now that I am developing the second site, I have changed this config setting to <code>.domain.com</code>, which should mean that sessions are recognised across both sites.</p>

<p>However, in my testing, due to the fact that cookies still exist for <code>site1.domain.com</code>, Craft is not recognising that I am logged in when I visit <code>site2.domain.com</code>.</p>

<p>If I delete the cookies from my browser and log into either site, Craft correctly recognises that I am logged into both sites.</p>

<p>This is fine for me to do, if a little annoying. However there are over 4000 registered users of <code>site1.domain.com</code> and I don't want to have to expect them to delete their cookies to enable them to access both sites. Is there something I can do to get Craft to avoid this problem by automatically delete their existing cookies and regenerate ones for <code>.domain.com</code> with no user intervention?</p>

<localization><session><cookies>
Session cookies
# Session cookies

(Asked by: username_0 on 2016-10-16)

I'm in the process of adding a second site to a Craft installation using custom locales. The two sites will be accessed on different sub-domains, e.g. `site1.domain.com` and `site2.domain.com`.

I need to ensure that logged in users can access both sites.

When I developed the first site, I didn't know that there would be a requirement to add a second site at a later date, so I set the `defaultCookieDomain` config setting to `site1.domain.com`.

Now that I am developing the second site, I have changed this config setting to `.domain.com`, which should mean that sessions are recognised across both sites.

However, in my testing, due to the fact that cookies still exist for `site1.domain.com`, Craft is not recognising that I am logged in when I visit `site2.domain.com`.

If I delete the cookies from my browser and log into either site, Craft correctly recognises that I am logged into both sites.

This is fine for me to do, if a little annoying. However there are over 4000 registered users of `site1.domain.com` and I don't want to have to expect them to delete their cookies to enable them to access both sites. Is there something I can do to get Craft to avoid this problem by automatically delete their existing cookies and regenerate ones for `.domain.com` with no user intervention?

**Tags:** localization, session, cookies


---

## 1 answers

### Answer by username_1 on 2016-10-16. Score: 1 | Accepted answer

You could write a plugin and put some code in it's `init()` method which would get fired on every request.

In the `init()` method, that plugin could call `craft()->httpSession->getCookieParams()` (which is just a wrapper for PHP's [session\_get\_cookie\_params](https://www.php.net/manual/en/function.session-get-cookie-params.php).

From there you could check the existing session cookie domain and if it's `site1.domain.com`, nuke the cookie. The request should automatically generate a new session cookie with the `.domain.com` domain set.

> **Comments:**
> **username_0**: Except, by your own admission, [plugins can't listen for Yii's `onBeforeRequest` event because they haven't been initialised when it fires](http://craftcms.stackexchange.com/a/1731/153). Which leaves me with `onBeforeLogin`. Will this work for returning users who have used the 'remember me' feature and are logged back in via their cookie? Or will it only fire when users actually login using the login form?  
> **username_1**: Doh, you're right. Updated the answer, but I think the plugin's `init()` would be the right place, then.  
> **username_0**: An update on this. It turns out that for old visitors, Craft was picking up the old CSRF cookie, rather than the new one, which resulted in CSRF errors when users tried to submit forms (including trying to login). This is because I ended up with two CSRF cookies, one for `site.domain.com` and one for `.domain.com`. I was also still having problems with the session cookie and unsuccessfully tried various tricks to delete the old cookies. I've ended changing the `phpSessionName` and `csrfTokenName` config settings, which works as it creates new cookies and ignores the old ones.  

---

