Problems when cookie domains are www.example.com and subdomain.example.com (drupal removes www.)
| Project: | Persistent Login |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Hi,
it is me again. I've thought that with beta6 we've resolved the issue, introduced through beta5 (I can not confirm that 100%, maybe it was the same also before, but working for me by chance, as described below - in any case, that's when I've noticed it for the first time...).
What I can confirm now for -beta6 and for the last -dev version (2009-May-02) is, that there is definitely still a problem with persistent logins in my case - I have 2 web sites: www.domain.ext and new.domain.ext (tested with Firefox 3.0.10).
If I clean all persistent logins and erase all cookies for both sites (Firefox CookieSafe extension shows cookies for new.domain.ext and for domain.ext, by the way - maybe it matters somehow...), there is no problem to login first into new.domain.ext with "remember me". I can safely close the tab or Firefox, and when I am back, I am properly recognized. I can login after that also into www.domain.ext, and it is properly remembered well (if "remember me" is checked, of course).
But, as soon there is some cookie for domain.ext present (it seems those are saved by www.domain.ext site...), it messes up everything. I can login into new.domain.ext also with "remember me", no problem. I can also close the tab, as long as I don't close the browser, I am recognized when reopen new.domain.ext properly. But, as soon as I close Firefox, I am not remembered for new.domain.com anymore. I see the record in the database, I see a "permanent login" cookie for new.domain.ext, but alltogether somehow simply doesn't work...
It may be also Firefox (or some of its extensions), or even Drupal itself - I would definitely prefer to see cookies for www.domain.ext and for new.domain.ext, which would probably work better, but for the moment there are only cookies for domain.ext and new.domain.ext (and, it seems in some circumstances cookies for domain.ext are considered instead of new.domain.ext...).
In any case, it is weird that if I permanently login for new.domain.ext first, it seems to work well after, so probably something could be done within premanent login, even if the source of the issue is elsewhere (always properly distinguishing domain.ext and somethingelse.domain.ext cookies...).
If it matters, I have 2 separate Drupal installations, one for www.domain.ext and another one for new.domain.ext (2 separate folders and 2 separate databases, but at the same Apache / MySQL server; that enables me to test everything and simply copy it to a production site after, almost without a risk to crash the whole production site...).
And yes, I have a setting in Drupal for www.domain.ext to use the whole site address for a cookie (exactly the same setting that for new.domain.ext site produces a complete new.doamin.ext cookie...). I don't know what is causing a "www" part to be skipped, but "new" to be kept (used), but I guess this is where to start digging...
#1
hmm... the 'www.' part of the cookie domain seems to be dropped in Drupal bootstrap.inc
<?php// 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.
#2
#3
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()?<?php- $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.
#4
For reference, I created a bug report to the Drupal issues queue: #458704: Removing "www." causes problems when creating cookies for www.example.com and example.com
#5
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. :(
<?php- $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?
#6
Can we simply redeclare a function messing with $cookie_domain? I believe Drupal supports some custom function declarations (the same name, just with module name included in the function name or so...), but don't know much about that.
Or, can we simply set a $cookie_domain variable so that it is different from URL / path and it doesn't begin with "www."? Would it work if I set it for example to "default.example.com" (or whatever that doesn't exist as another site)? I can not just try, as it is a production site, and I really wouldn't like to mess too much...
#7
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?
#8
As much as I am able to understand your feedback, it should be OK (for my case). But, I am not very familiar with this subject, so maybe I am not the most appropriate person to provide the evaluation. In any case, if you can implement both options, it would be a step ahead, as we can at least test it.
#9
@anyone having this issue: Could you please test the change in #3, and try the patch in the Drupal issue mentioned in #4?
#10
I've applied both patches, #3 (to the latest 6.x-1.x-dev version from 2009-Jul-20) and #4. As much as I've tested up to now, everything seems to work fine.
#11
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: Removing "www." causes problems when creating cookies for www.example.com and example.com
#12
Automatically closed -- issue fixed for 2 weeks with no activity.