1

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?

1 Answer 1

1

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.

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.

3
  • Except, by your own admission, plugins can't listen for Yii's onBeforeRequest event because they haven't been initialised when it fires. 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? Commented Oct 17, 2016 at 10:25
  • Doh, you're right. Updated the answer, but I think the plugin's init() would be the right place, then.
    – Brad Bell
    Commented Oct 17, 2016 at 17:14
  • 1
    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. Commented Oct 23, 2016 at 16:21

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.