2

I have a site that is in French and English. I am able to successfully setup so that users can switch back and forth between the two domains to view either language, however I cannot seem to keep users logged in. When they are logged into the english domain and then switch to the french domain they are required to login again. However if they switch back to the english domain they are still logged in.

As an example we'll use www.english-domain.com as the base (default) domain and www.french-domain.com as the secondary domain

In settings.php I have modified the following, however it doesn't seem to be keeping them logged in. Am I missing something?

/**
 * Drupal automatically generates a unique session cookie name for each site
 * based on its full domain name. If you have multiple domains pointing at the
 * same Drupal site, you can either redirect them all to a single domain (see
 * comment in .htaccess), or uncomment the line below and specify their shared
 * base domain. Doing so assures that users remain logged in as they cross
 * between your various domains.
 */
$cookie_domain = 'english-domain.com';

Note: That I have also flushed both site and browser cache as well as deleted any cookies left on my machine.

Update:

Here are my language settings:

enter image description here

enter image description here

5
  • 1
    What do you mean by, "keeping the user logged in"? Are users automatically logged out when they switch between the two domains?
    – apaderno
    Nov 23, 2012 at 18:58
  • When they are logged into the english domain and then switch to the french domain they are required to login again. However if they switch back to the english domain they are still logged in. Nov 23, 2012 at 19:04
  • Add a dot before site name('.english-domain.com') and check again Nov 23, 2012 at 19:08
  • Unfortunately that didn't work either. I have updated my answer with a bit more info that may or may not be pertinent. Nov 23, 2012 at 19:29
  • I also came across this in my research but not sure if it applies to my situation and how to properly add it to settings.php drupal.org/node/1348784 Nov 23, 2012 at 19:37

2 Answers 2

3

Cross domain cookies are not allowed; this means that english-domain.com cannot set a cookie for french-domain.com.
Cookies can be shared between sub-domains, though: english.example.com can set a cookie that is seen from french.example.com, and vice versa.

To allow users to be logged-in on sub-domains of the same domain, you can use the Bakery Single Sign-On System module.

As far as I know, there aren't Drupal SSO modules for different domains. There are web sites that allows SSO between different domains, such are the ones that are part of Stack Exchange network, where users having an account on Stack Overflow can be automatically logged in on Drupal Answers, or Super User, if they have an account on those sites.
The code to write is more complicated, in this case. What Stack Exchange sites do is the following:

Initial login

  • Login proceeds as usual
  • At the end, the user is given a global login token (attached as a cookie)
  • The next page the user visits takes that token, and (via an IFrame) shovels it to StackAuth
  • StackAuth verifies the token, and attaches a session key via localStorage

Visiting a different site

  • JavaScript is used to hit StackAuth via an <iframe>
  • StackAuth checks localStorage for a session, and sends it to itself if it is
  • StackAuth validates the session and passes a login token to the Stack Exchange site via postMessage when the session is valid
  • The Stack Exchange site validates the token, looks up the user, and logs the user in

Using cookies, and sub-domains is much simpler. The code used by Stack Exchange requires a browser supporting localStorage, but it works for every domain, not just sub-domains.

3

A cookie can only be read from the same domain that set it. This is a fundamental security feature in browsers to prevent other sites from potentially stealing login sessions, and there is nothing simple you can do about it.

With that said, the comment in the settings.php file seems to contradict my statement, and I'm honestly not really sure how to intrepret that. Perhaps it's only meant to be relevant to sub-domains, which are allowed to share cookies, but if so the comment should probably be re-phrased.

There are a number of ways to work around this, where the easiest is to use language prefix sub-domains instead of separate domains.

Baring that, I believe the "best" one is to use a Single sign-on system. There's a comparision of different SSO modules here. This could be a Drupal based solution, which is the way that is most likely to "nicely" integrate with your current Drupal sites, but that's not really necessary.

The Bakery module which is used by *.drupal.org itself is relevant to mention, as well as this related DA answer How drupal.org single sign on works

More info about cross-domain cookies in a Stack overflow question.

3
  • I can understand using SSO if these were different sites, but these are just two domains pointing to the same drupal installation and Drupal is handling the domain switching through the language settings. Nov 23, 2012 at 19:58
  • "Just two domains" doesn't help. As I said, it's a browser feature, and the browser can't know, nor does it care, that you run both domains off the same code and they should entrust each other with their cookies. Why that isn't a feature I don't know, but you can probably find out if you read RFC2109 :)
    – Letharion
    Nov 23, 2012 at 20:02
  • Gotcha. It all makes sense now. I have done some further research and there is no way to use a native Drupal SSO module to achieve what I need. If they were two different installations, I could use SSO server/client because one can be setup as the master and the other as a slave. But I cannot set one site to be both a master and a slave. As in the case of using two domains on one install for multilingual. Going to chalk this up to "can't be done, easily" and moving on. :) Thanks for your help. Nov 23, 2012 at 20:26

Your Answer

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

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