Problems when cookie domains are www.example.com and subdomain.example.com (drupal removes www.)

hmm... the 'www.' part of the cookie domain seems to be dropped in Drupal bootstrap.inc

  // Strip leading periods, www., and port numbers from cookie domain.
  $cookie_domain = ltrim($cookie_domain, '.');
  if (strpos($cookie_domain, 'www.') === 0) {
    $cookie_domain = substr($cookie_domain, 4);
  }

I didn't noticed that before. Look like a bug, or in need of more documentation because it says what it does but not why.

So... what can we do? ...hmm... what if the PL cookie name is derived from the Drupal session name? Then it would be different for each site, so there would be no conflicts of this kind?

PS: Before the changes I introduced to PL affecting all this stuff was because the domain cookie was not specified, and then the browser takes the domain in the URL, and that makes impossible to share PL cookies, and that needed a solution. Maybe little by little we can find one that works in all situations.

How about using a name for the PL cookie that's derived from the session cookie?

Could you please try the following change to persisten_login.module, function _persistent_login_get_cookie_name()?

-    $cookie_name = 'PERSISTENT_LOGIN_'. md5($GLOBALS['base_path']);
+    $cookie_name = 'PERSISTENT_LOGIN_'. substr(session_name(), 4);

This approach should ensure a different cookie name for PL is used for each different Drupal session.

For reference, I created a bug report to the Drupal issues queue: #458704: Don't automatically remove "www." from admin-set cookie domains

Unless Drupal defines a different cookie_domain for www.example.com and example.com. I think the mini-patch will still not work, since the same PL cookie name will be generated.

Here' another approach, but it will fail as well, because the path to settings.php is probably the same for www.example.com and example.com. :(

-    $cookie_name = 'PERSISTENT_LOGIN_'. md5($GLOBALS['base_path']);
+    $cookie_name = 'PERSISTENT_LOGIN_'. md5(conf_path());

So... how can we generate a different cookie name for each separate site? I think it should be based on something unique to each site that Drupal has already elaborated, which is sanitized, etc. That's the cookie_domain, but Drupal strips "www." from there, so... what else?

Nope. We cannot use anything for the cookie domain, as it is subject to security issues. We can only use the host name in the URL or a domain which is part of that.

Before the change I made to PL, the cookie domain was not explicitly specified when creating the PL cookie, and then it defaults to the whole host name in the URL. But, that has the problem that a site cannot share the PL cookie. And I wanted to resolve this.

What I did was using the same exact cookie domain as the one used for the Drupal session, which is one that a site can customize from settings.php. And it can be set to share the cookies between several subdomains or not. You have choices.

The problem is that Drupal blindly removes the "www." prefix for a cookie domain. A fact that I missed. :( And that's the cause of your problem. Hence I opened that bug to the Drupal issues queue. I'm afraid, though, that this issue will end up lost in the queue, because the current Drupal behavior does not affect the typical usage, and it's a complex thing to change.

We cannot alter the cookie domain used by Drupal. There's no hook that allows us to undo the "www." removal. So now I think the only way for sites with a use case like yours, is to have the ability to define the PL cookies as it was before, with no explicit domain. If it's an option, then we have a choice again.

Now, if I implement this as an option (Something like "Domain for PL cookie: a) Same as session cookies, b) Use host name in URL"), then it should be done in a way that the cookie name itself is affected by this option. Otherwise, if the cookie name does not change when this option is changed, it could cause problems due to visibility of the cookies and the fact that PHP cannot see the same cookie for different scopes ($_COOKIE array keys are just cookie names).

Makes sense?

@anyone having this issue: Could you please test the change in #3, and try the patch in the Drupal issue mentioned in #4?

Thanks for the feedback. I have committed the patch in #3 to CVS.

@all: Please, try out the patch to Drupal core and give feedback to that issue. Hopefully this encourages core maintainers validate the patch. See: #458704: Don't automatically remove "www." from admin-set cookie domains

Have you applied the patch to Drupal after upgrading Drupal core?

For reference: #458704: Don't automatically remove "www." from admin-set cookie domains

If that patch works for you, then please bump that issue in the Drupal queue. No one else seems to care about this. :(

If it is not missing that patch, then I don't know where else to look. This is working ok for us.

Re: "!Could it be that something within cron jobs is messing with sessions so that saved sessions are somehow discarded (or lost) after?"

I guess it depends on what these cron jobs are doing. Try scanning your modules for implementations of hook_cron(), any function like MODULE_cron(), and see what they're doing.

Re: "Could this information be of any help?"

Not too much. We need to identify where are the cookies being removed, then see why and what we can do to prevent it.

Nope, these are different strings. It's ok that they don't match with what you see in the browser cookie names.

Still, no idea what might be causing this. PL is working like a charm here. I think browsers may loose cookies sometimes. cookie storage is not 100% reliable, so maybe your issue is related to that. Without a method to reproduce the issue, I'm short on ideas.

"used" means PL has logged you in using the PL cookie, which is the first time after a while you visit the site and see the "Welcome back" message, if enabled.
"stolen" means PL has detected an invalid PL cookie.

hmm... I found (yesterday) that the part of the code in PL that detects a stolen cookie had a bug, making it impossible to log an additional watchdog() error, which is something that could help analyze what happens when "stolen" PL cookie is detected. I would suggest trying out the patch here: #621916: PHP notice before security alert.

Well, the patch for Drupal core was applied to the D7 branch. It is now waiting to be backported/applied to Drupal 6 as well. If anyone is interested in this, please provide feedback on the following issue: #458704: Don't automatically remove "www." from admin-set cookie domains Thanks!

It sounds like this issue should have been resolved with patches to core, and a correct cookie domain configuration.