The problem comes when trying to create cookies in custom/contrib module under the same cookie domain as the Drupal session, which is the cookie_domain defined at PHP level.

Being able to create cookies under the same domain as the Drupal session, makes it possible to share the cookies for the same exact sites as the Drupal session.

The "www." part of the domain cookie is stripped out in conf_init() since this patch, like this:

  if (strpos($cookie_domain, 'www.') === 0) {
    $cookie_domain = substr($cookie_domain, 4);
  }

So there's no way for a site to use different cookie_domains for www.example.com and example.com. Both will blindly become example.com.

This is often no problem for the Drupal session, as both sites will likely be using the same sessions database. But if I need to use separate session tables for each site, then a session created for one site will need to be created for the other site, but Drupal will generate the same cookie name for both, and one login will override the other.

This scenario does not probably exist, as sites are using the same database for www.example.com and example.com, but the fact that "www." is stripped out from the cookie_domain causes problems for other cookies that attempt to be created under the same cookie domain as the session cookie.

Question: is there any reason to strip out "www." from the cookie_domain? If not, then would it be possible to remove the above mentioned lines from conf_init() ?

For reference, here's an issue for the Persistent Login module where I noticed this problem: #456334: Problems when cookie domains are www.example.com and subdomain.example.com (drupal removes www.).

If this is fixed for D7, then pleas consider backporting to D6. Thank you

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

markus_petrux’s picture

I've tried to research a little more, trying to figure out where's the origin of the code that removes "www." from the cookie domain. And I think I've found it:

http://drupal.org/node/108663#comment-490298

Well, I think that's ok when Drupal generates the cookie domain, which may be good enough for the average site. But current implementation does not allow a site to define different cookie domains for www.example.com and example.com. Worst, if you have 2 sites, say www.example.com and xxx.example.com, then the first cookie domain becomes example.com and the second xxx.example.com, but the browser will send all the cookies defined for www.example.com to xxx.example.com, which is a problem.

Aside from session cookies, almost no one else is using the cookie domain to create cookies, in other core components (has_js or comment module cookies), or custom/contrib modules. But this is a problem because these cookies cannot be shared with other sites that use the same cookie domain. When no domain is specified when creating a cookie, the browser will take the one that's currently in the URL. If something needs to share the cookie between sites, it needs to use the cookie domain.

But if "www." is removed from the cookie domain, then we have a problem.

Maybe the solution would be to only remove "www." from the cookie domain when it has not been explicitly defined in settings.php ? That would cover the default site layout (www.example.com + example.com is the same site), but would allow other layouts, such as www.example.com + xxx.example.com, or even www.example.com + example.com as different sites.

brianmercer’s picture

It seems this would also be true if you have static files at static.example.com and the main domain at www.example.com.

It will set the cookie as .example.com and clients will send the session cookie for each static file request, when one of the supposed advantages of a static file subdomain is not sending cookies.

tic2000’s picture

Status: Active » Needs review
FileSize
901 bytes
915 bytes

@brianmercer
Yes it does. http://developer.yahoo.com/performance/rules.html#cookie_free

I really don't understand why the code is in conf_init. And I don't understand why the behavior is not documented in settings.php.
IMO the cookie domain should be that from settings.php. If I choose to have www.example.com don't change it behind my back. If I have login problem like people describe, well, you have settings.php to set the cookie domain to example.com, nothing stops you to do so.

What it puzzles me is that there were people that said that could be a problem, but they were ignored.

I attach a patch against HEAD and one for D6

Damien Tournoud’s picture

Status: Needs review » Needs work

Let's just move the www.- prefix and port stripping above, just below:

$cookie_domain = check_plain($_SERVER['HTTP_HOST']);
tic2000’s picture

Why removing the www. if there is no cookie domain set? If someone really wants that removed he sets the cookie domain without www.
Anyway, it needs work, cause as it's now, it ads a point before www. I changed the code to remove that, but the SESSID cookie it's still has a .www.example.com domain while has_js for example it works as it should. I tried to figure why is that, but I couldn't for now.

Damien Tournoud’s picture

@tic2000: the default setting (if you have not explicitly set $cookie_domain in settings.php) should be: take the host, remove the www prefix, remove port numbers, and add a "." in front. That's a sane default setting, that will work for most users.

On the other hand, if you explicitly set $cookie_domain, Drupal should use that as-is.

tic2000’s picture

Then I think all that block of code should be moved inside the else. If the $cookie_domain is explicitly set it won't contain the port number. If it does it's not Drupal's job to fix bad settings.

Damien Tournoud’s picture

@tic2000: that's what I was suggesting in #4.

tic2000’s picture

Status: Needs work » Needs review
FileSize
1.63 KB
1.65 KB

Patches with the suggested changes.

Status: Needs review » Needs work

The last submitted patch failed testing.

tic2000’s picture

Status: Needs work » Needs review
markus_petrux’s picture

Code looks good to me. Now, site admins has the full potential to define cookie domains as they wish, which is great. :-D ...and if not if cookie domain is not explicitly defined in settings.php, it will work as before, so it seems good to go.

BTW, thanks a lot for the patch to D6.

daemon’s picture

@brianmercer: my issue is the same as you but I am not using www on my site, leading me to having a shared cookie on my static subdomain. Also outlined in http://www.phpied.com/www-vs-no-www-and-cookies/.

I guess I will need to park a new domain!

Status: Needs review » Needs work

The last submitted patch failed testing.

markus_petrux’s picture

Status: Needs work » Needs review
FileSize
1.68 KB
1.66 KB

Patches in #9 re-rolled.

Status: Needs review » Needs work

The last submitted patch failed testing.

markus_petrux’s picture

Status: Needs work » Needs review
FileSize
1.65 KB

Patch for D7 in #15 re-rolled.

Patch for D6 in #15 still applies.

Status: Needs review » Needs work

The last submitted patch failed testing.

markus_petrux’s picture

Status: Needs work » Needs review
FileSize
1.68 KB

Oops! Patch in #17 was not relative to Drupal root. Sorry.

Status: Needs review » Needs work

The last submitted patch failed testing.

markus_petrux’s picture

Status: Needs work » Needs review
FileSize
1.68 KB

Re-rolled.

lastnico’s picture

Please backport this to D6. This is really painful to manually modify the Drupal source code (at each update) in order to remove this 'www' trailing that is not required.

This is particularly troublesomes when you try to provide a cookie less subdomain (like static.example.com)

Thank you.

brianmercer’s picture

Applying patches is problematic if you don't have shell access. Unfortunately, Drupal policy is to only apply bug fixes to existing releases. They do not to apply new features.

The patch at #15 works with the latest Drupal 6.x and the latest Pressflow if you do have shell access.

lastnico’s picture

Yes, I agree about the policy, but this patch _could_ easily be considered as a bug fix, as the system modify a value setted explicitly from a configuration file, where it is totally optional to define it or not. And more over, cookie-less subdomain is not possible with Drupal 6.

srobert72’s picture

Subscribe

Damien Tournoud’s picture

Title: Removing "www." causes problems when creating cookies for www.example.com and example.com » Don't automatically remove "www." from admin-set cookie domains
Status: Needs review » Reviewed & tested by the community

#21 is RTBC.

As a reference, the bug described by @markus_petrux ("it causes issues when modules try to set their own cookie"), is not actually a core bug. Drupal modules *have to* use the session name within the cookie name, because several Drupal installation could share the same cookie path.

Dries’s picture

+++ includes/bootstrap.inc	26 Aug 2009 22:58:55 -0000
@@ -555,6 +555,13 @@ function drupal_settings_initialize() {
     // We escape the hostname because it can be modified by a visitor.
     if (!empty($_SERVER['HTTP_HOST'])) {

This comment looks a bit odd. The rest of the patch looks OK though. Will commit shortly -- maybe someone wants to revisit that PHP comment.

Damien Tournoud’s picture

Good catch, this escaping is not even necessary anymore (since we now strongly validate HTTP_HOST).

kewlguy’s picture

+1 subscribing for D6

tic2000’s picture

That comment was there before, it's not added by this patch.

Dries’s picture

I know it is not added by this patch. I'll simply remove the comment when I commit the patch.

Dries’s picture

Oddly enough, the patch doesn't apply anymore. Can we get a quick re-roll?

kewlguy’s picture

Thank you all for your efforts with creating this patch!

The d6 patch from #9 applied fine for me with no hunks failing. I do notice now that when I view the cookies for my site I see the www has been retained for has_js and Drupal_l10n_client though my session cookie as well as for my persistent login cookie each have a leading dot i.e. .www.example.com?

My default site, I like to call my error site, has the session cookie with the leading dot i.e. .example.com and my has_js cookie does not have the leading i.e. example.com

I'm not quite sure where to report this, or if I should other than here, as well as how exactly this is going to affect my site. I would appreciate the thoughts of another more experienced user, time permitting of course.

I will try this on my recent test site for d7 and will report back.

I hope I am being helpful and not getting in the way! Thank you again for the patch and your patience with me.

kewlguy’s picture

Tried to apply this patch to the d7 I set up last night from the downloads page and this is the result. I explicitly checked that I had set the cookie in my settings.php 1st.

patch -p0 < cookie-domain-458704-21-D7.patch
patching file includes/bootstrap.inc
Hunk #1 FAILED at 555.
Hunk #2 succeeded at 607 with fuzz 2 (offset 34 lines).
1 out of 2 hunks FAILED -- saving rejects to file includes/bootstrap.inc.rej

I hope this is helpful!

Dries’s picture

Status: Reviewed & tested by the community » Needs work
tic2000’s picture

Status: Needs work » Needs review
FileSize
1.38 KB

Seems that comment was "enhanced".

kewlguy’s picture

Thanks again for all the work on this patch and the reroll.

I have downloaded and installed a fresh copy of drupal 7 alpha3 and applied the patch. The patch applied cleanly with not errors to report.

After clearing out all my cookies and reloading the page I find that my sub-domain that I set in the settings.php is maintained though I find that I end up with 2 cookies one for the session that has a leading dot and another for has_js that does not have the leading dot.

I do not see any cookies from my domain name without the sub-domain.

Sorry, I cannot specifically test with the www because I needed to utilize a subdomain of my domain name to install drupal 7.

Anyone have any ideas of where I can have the has_js cookie with no leading dot addressed?

tic2000’s picture

Status: Needs review » Reviewed & tested by the community

Test passed, back to RTBC

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Looks good now. Committed to CVS HEAD. Thanks.

tic2000’s picture

Version: 7.x-dev » 6.x-dev
Status: Fixed » Patch (to be ported)
markus_petrux’s picture

Status: Patch (to be ported) » Needs review
FileSize
1.62 KB

Re-roll for D6.

tic2000’s picture

Status: Needs review » Needs work
+++ includes/bootstrap.inc	25 Apr 2010 23:47:16 -0000
@@ -366,6 +366,13 @@
+      $cookie_domain = '.' . $cookie_domain[0];

In D6 there is space only between the dot and the variable.

Powered by Dreditor.

markus_petrux’s picture

Status: Needs work » Needs review
FileSize
1.62 KB

Oops! Space removed. Patch re-rolled.

tic2000’s picture

Status: Needs review » Reviewed & tested by the community
LUTi’s picture

I have a patch #41 (slightly adapted to make Coder happy, as #42, just with a space only between the dot and the variable, but not also between the string '.' - what is alltogether unimportant...) applied since March, and it doesn't seem to cause any troubles (but seems to help "Persistent Login" module to perform better).

So, I definitely vote to accept this patch (in form #41 or #43 or - as in my case - something in between...) for future Drupal releases.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Committed #43, thanks.

advseb’s picture

I'm not sure if it was a good idea to do such a fundamental change in a stable branch. You at least broke CKFinder plugin: http://drupal.org/node/817062

foutrelis’s picture

I came across an issue, possibly caused by this patch, where users were unable to log into the site after upgrading to Drupal 6.17. I had $cookie_domain set to 'example.com' in settings.php and the old code (Drupal 6.16) appears to unconditionally add a period (.) at the beginning of the cookie domain. In Drupal 6.17, this code was moved inside the else clause of a conditional statement and only runs when $cookie_domain isn't set in settings.php.

The above causes new session cookies to be set with 'example.com' as their domain. The problem with this is that the browser keeps sending the old session cookies that have their domain set to '.example.com' and contain invalid session data.

My solution was to add a period (.) at the beginning of the $cookie_domain variable in settings.php. I hope this is the advisable way to overcome this issue.

Gábor Hojtsy’s picture

@foutrelis: yes, that is the right approach. You should set the cookie domain to whatever you want it exactly. If it was modified by Drupal earlier, now modify it to what it Drupal modified to before.

cog.rusty’s picture

It is true that if you set a wrong $domain_setting it is your problem, but a change in behavior in a stable version is Drupal's problem. The change of behavior in D6.17 will at least need very visible documentation, perhaps in the release announcement.

There are many sites out there that have set $domain_cookie="example.com" to support multisites with shared sessions (or for no particular reason), and they are now broken because they need to change it to $domain_cookie=".example.com". Support requests have started to roll-in.

By the way, an example test of what happens to a multisite with subdomains and shared sessions with a now-wrong $domain_cookie="example.com" setting:

Site "sub.example.com"
Setting $domain_cookie='example.com'

Logged out:
- printing 'session.cookie_domain': ".sub.example.com"
- session cookie in browser:
--- Domain: empty!
--- Host: sub.example.com

Logged in:
- printing 'session.cookie_domain': empty!
- session cookie in browser:
--- Domain: "sub.example.com"

The "wrong" setting does not appear anywhere, it just breaks things.

cog.rusty’s picture

I should also add, from experience from the support forums, that
- the last configuration kept relatively quiet the support requests for login problems for a very long time
- before that, we had serious (in quantity) problems of one kind or other, also for a very long time.
- I hope the change made here, besides it logic, has been actually tested in a fair number of "normal" use cases.

Damien Tournoud’s picture

I edited the release announcement to add some more details about the session cookie change. Copy-proofing is appreciated.

cog.rusty’s picture

Also:

/**
 * Drupal automatically generates a unique session cookie name for each site
 * based on 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
+ * shared base domain with a front dot. Doing so assures that users remain logged in as they
 * cross between your various domains.
 */
-# $cookie_domain = 'example.com';
+# $cookie_domain = '.example.com';

One last though: What is now the purpose of $cookie_domain if it behaves (almost?) the same as ini_set('session.cookie_domain', '.example.com');? I think it was introduced just as an easy "bulletproof" setting. Or did it have another purpose?

foutrelis’s picture

@Gábor Hojtsy: I don't mind the cookie being set as a domain cookie. Ideally, I would have liked the pre-6.17 behavior to not mess with the value of $cookie_domain in settings.php, and set a host cookie as intended. At this point, I don't think I can force a host cookie ('example.com' instead of '.example.com') as the existing domain cookie seems to take precedence and it's the one sent by the browser.

@Damien Tournoud: Looks good to me, only correction needed is that the variable is called $cookie_domain, not $domain_cookie. And then, there's the issue I faced, where the 'example.com' setting doesn't work because Drupal <=6.16 automatically converted that to '.example.com'. Unless I'm missing something on how cookies work (do domain cookies have precedence over host cookies, as my brief experience indicated?), it's not straightforward how to switch to 'example.com'.

Damien Tournoud’s picture

@foutrelis: actually, far as I know, it was never possible to use a straight 'example.com' setting, because of this check in conf_init():

  // Per RFC 2109, cookie domains must contain at least one dot other than the
  // first. For hosts such as 'localhost' or IP Addresses we don't set a cookie domain.
  if (count(explode('.', $cookie_domain)) > 2 && !is_numeric(str_replace('.', '', $cookie_domain))) {
    ini_set('session.cookie_domain', $cookie_domain);
  }

This check is actually ill-conceived, because no browser I know of (except Lynx) respects the domain matching specified by RFC 2109.

In all versions of Drupal 6, the only way to set a 'example.com' seems to directly issue a ini_set('session.cookie_domain', 'example.com');. This is pretty much inconsistent, but we have to fix that in Drupal 7 first.

cog.rusty’s picture

Oh, that too. Since the introduction of $cookie_domain, ini_set('cookie_domain') doesn't work any more in settings.php -- it is overrided. Even if $cookie_domain is not set.

foutrelis’s picture

@Damien: You're right. However, now that Drupal 6.17 doesn't unconditionally add a dot in front of a manually defined cookie domain, that check fails and session.cookie_domain remains empty. This means that the cookie's domain defaults to the host name of the server, which, in my case, is the same as the value of $cookie_domain. But yeah, you make a valid point that the setting isn't taken into account when it's set to 'example.com'.

Edit: Also, in RFC 2109 I read:

Domain=domain
Optional. The Domain attribute specifies the domain for which the
cookie is valid. An explicitly specified domain must always start
with a dot.

So, I guess my 'example.com' setting was actually incorrect! With this in mind, I like cog.rusty's suggestion in #53 about emphasizing the importance and necessity of the leading dot.

cog.rusty’s picture

Heh, my intent in #53 was not to emphasize the dot, just to correct what the comment was suggesting because it was wrong.

But I do believe that the dot never hurts anyone and always leaves room for a more specific domain setting in a subdomain.

cog.rusty’s picture

Status: Fixed » Needs review
FileSize
810 bytes
cog.rusty’s picture

Version: 6.x-dev » 7.x-dev
FileSize
806 bytes

Cookie domain comment correction in default.settings.php

cog.rusty’s picture

A couple of points for documenting the current behavior:

1. With no $cookie_domain setting, or with a "good" setting, such as $cookie_domain=".example.com", a session.cookie_domain is computed and set.

In both cases, a set_ini('session.cookie_domain', 'anything') in setting.php has no effect.

2. A $cookie_domain="example.com" setting now has no effect. No session.cookie_domain is set.

The reason is the check which Damien mentioned in #55 which used to work, because a front dot was being added just before that check, but now it doesn't.

However, in this case an additional set_ini('session.cookie_domain', 'example.com') in setting.php does work, and can set the session.cookie_domain. You need both $cookie_domain and ini_set() to set "example.com".

----- Edit:

to clarify that by "used to work" I meant that "a cookie domain was set", although not an "example.com" cookie domain -- that was not possible before. To fix the current abnormal behavior of the "example.com" setting, the > 2 check must change to > 1 or completely removed.

The user case of "example.com" is that you have subdomains sharing ".example.com" but you don't want the main domain to be part of the sharing. Maybe I am nitpicking here because the front dot never hurt anything.

cog.rusty’s picture

We could replace

count(explode('.', $cookie_domain)) > 2

with

count(explode('.', ltrim($cookie_domain, '.'))) > 1

to eliminate the "example.com" anomaly that I described, if we want to keep the "at least one dot other than the first" specification.

The old code was working with the assumption that there would always be a front dot.

neclimdul’s picture

Honestly, this seems like a bit of a regression. Something worked before and now doesn't. Even if it shouldn't have worked before, the documentation lead you to believe it would and it did. So it seems like at least for D6, we should probably add the ability to specify 'example.com' as the cookie_domain back.

Gábor Hojtsy’s picture

@neclimdul: well, how would you specify the case then if you'd not want to have your cookies set for subdomains but only for the bare top domain? (What you suggest is we consider example.com as if .example.com was specified, right?)

neclimdul’s picture

@gabor yeah, I think that'd be correct.

There is actually another regression here too. The session name changes for people that had been specifying the cookie_domain as 'example.com' since it will now be using '.example.com' for the session name. This is causing issue with an Java application on a different sub-domain was looking for this cookie to communicate with Drupal for a single sign-on authentication.

cog.rusty’s picture

I too believe that the dot change backport required much more review and testing, as it affected existing installation.

But we need to make the best of it now. There is a bug to be fixed in #60. User instructions which have now become incorrect. Please review.

thinkyhead’s picture

Same issue here @foutrelis. In my case it disrupted our very active production site, so we ended up with lots of people unable to login after the update to 6.17. We instructed them to clear their cookies, but not everyone has been savvy enough to delete both the disruptive 'mysite.com' cookie and the newer '.mysite.com' cookie.

After the upgrade I examined the cookies in my own browser, and I could see one login cookie was set under 'mysite.com' and another under '.mysite.com' so I added the dot to the front of $cookie_domain and deleted old sessions from the sessions table. But unfortunately, for many users Drupal was still seeing the old cookie and blocking login. So last night I also reduced the cookie lifetime (I assume this is passed to sess_gc?) to 48 hours (from the default 23 days!). With any luck this will finally allow users who have old cookies lying around to login!

Anyway, the simple and obvious fix would be to change the code again so it always adds a dot to the front of the $cookie_domain if there isn't one already. Meanwhile, many site admins are going to update to 6.17 and run into this issue, and reverting to 6.16 will probably be the general solution... though I'm not sure that will even fix it.

cog.rusty’s picture

Just to add that if a rollback is considered, it won't break existing sites, whether or not they have manually added the dot.

mhenning’s picture

Is this line on http://drupal.org/drupal-6.17 correct?

'example.com' if you want sessions to apply to the example.com domain, and none of its sub-domains (especially not www.example.com),

That is not how I understand it to work. If you specify example.com, it will work on all of its sub-domains (especially www.example.com).

Also, we had our $cookie_domain in setting.php set with the www. in front (www.example.com). We ran into the login errors reported here (the key to diagnosing this error was that you don't get a "invalid login" error, you get a "you don't have permission to view this page error").

As I understand it, the www.example.com cookie domain was translated to .example.com in 6.16 and now in 6.17 it stays at www.example.com. But those old cookies at .example.com have precedence and screwup any login.

We went ahead and changed setting.php to .example.com since it didn't matter for our site, but for those that it does matter, they can't do this. What is the fix in that case? Sounds like deleting the sessions table doesn't do it.

mhenning’s picture

Actually, now that I think about it more, I don't understand the whole point of the session handling section on http://drupal.org/drupal-6.17

This line is stupid:
Most people don't need to have this setting set, but if you have an explicit $cookie_domain set in settings.php, verify that it is set to a sensible value:

Nothing changes about how you should set your $cookies_domain in 6.17 and even if you had your settings set to a "sensible value", they are still going to break.

What I think it should say is:

If you had your $cookie_domain set to either "www.example.com" or "example.com" individuals who had logged in successfully and have a cookie set on their machine will no longer be able to login. Instead of a "invalid login" error they will see a "permission error". To fix this problem, you need to change your $cookie_domain to ".example.com" or have your users clear their cookies (they will need to clear the .example.com one).

cog.rusty’s picture

The first line in that text looks wrong. It should probably say "example.com if you want drupal not to set a cookie domain at all, but to let each browser interpret RFC 2109 in the absence of a cookie domain as it sees fit."

advseb’s picture

As mentioned before, we also had lots of users unable to login. I think there is another quickfix if your users experience problems being unable to login: clear the sessions table.

Can any developer confirm that existing cookies are ignored if no counter part in the sessions table can be found?

frjo’s picture

If the instructions correction patch #60 had been committed I would have saved some time last night. Updated a site with a single sign on solution based on "$cookie_domain = 'example.com'".

The fix was simple, just add a dot "$cookie_domain = '.example.com'" but it was a bit hard to track down since the instructions in default.settings.php still says that "$cookie_domain = 'example.com'" is the correct way.

So please commit patch #60 to 6.x-dev.

mikemccaffrey’s picture

Unless I am mistaken, the patch that was rolled into the 6.17 release breaks the ability to have different Drupal installations on different ports.

Previously, you could specify a port number in the $cookie_domain variable. Obviously, since ports are not allowed in cookie domains, it was stripped out before the session.cookie_domain was ini_set. However, it still used the version with the port for the $session_name variable, which is in turn used for the md5 hash to create the actual session cookie name.

Now, if you include the port in the $cookie_domain in settings.php, things break because browsers won't accept a port in the cookie name. And if you leave the port out, different installations on different ports end up with the same value for $session_name and the same session cookie name. Then there is no way to be logged into both sites, because every time you visit one, it overwrites the session cookie for the other.

Attached is a patch that puts the port stripping action back for manually entered $cookie_domain. It is not an ideal solution, as it misrepresents the port as being included in the cookie domain, but it would help get people's sites back up and running.

erald’s picture

Version: 7.x-dev » 6.19

Nice. This patch in version >6.17 broke my site. I am reluctant to upgrade quickly on production servers and test everything on a test installation.

In this case I had test.example.com set as cookie and with the upgrade to 6.19 had no problems. However when I installed it on the production server which had the cookie domain set on www.example.com things went wrong.

I am using amember to log in to the drupal site which uses the SESS cookie. But since the www was not stripped anymore I ran into login problems. My users were not able to log in anymore because had 2 SESS cookies, one with www.example.com and one with example.com. Deleting the www.example.com made it working again, but try to explain that to your users. Just deleting the cookies was not enough since both were created again. Tried to set the cookie domain to example.com but that did not work either. One of the problems was that if you had deleted the wrong cookie it miraculously worked and even logging off clearing all cookies and log in again was no problem.??? Very strange behavior which I do not understand. This made that some users were able to log in and others not. The why is unclear to me (have not much knowledge on cookie handling)

Thinking it came from the session table I deleted all entries there but was not the solution till I found this thread which made me checking the bootstrap.inc. I seen it but it was about drupal 7 so skipped it at first)

By reversing the patch and always stripping the www things went back to normal. But this took me several hours to figure out.
I understand why it might be a good thing not to strip the www, but as it can break a lot of things by changing this, I think it is not a good idea to implement this patch without proper documentation and even think it might be good if there is a configuration option to strip or not to strip.

I just took the code;

      // 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);
      }
      $cookie_domain = explode(':', $cookie_domain);
      $cookie_domain = '.'. $cookie_domain[0];

And placed it back where it was in the bootstrap.inc in version 6.16 and this solved all my issues. So have to be careful with new upgrades.

MiMe’s picture

Everything works perfect, its the documentation that has a bug in it. The documentation in the settings.php has an example of the cookie domain set to:
# $cookie_domain = 'example.com';

But the cookie domain should be replaced with .example.com since the . is added in the bootstrap.

So the correct documentation should be:
# $cookie_domain = '.example.com';

cog.rusty’s picture

Bump! Review the patch in #60.

cog.rusty’s picture

Version: 6.19 » 7.x-dev
MiMe’s picture

Patch works for me!

Gerhard Killesreiter’s picture

Version: 7.x-dev » 6.x-dev
Status: Needs review » Active

I am rather displeased that such a modification made it into the supposedly stable code branch. This has caused us some headscratching in conjunction with the bakery setup at d.o. This is the 2nd time after the lock.inc desaster that patches that did only address problems of a very small subgroup of users affected a potentially large installed userbase.

jbrauer’s picture

As a result of the issues Killes mentioned in #80 I was prompted to follow-up on some outstanding issues on other sites. I found that reverting the patch here and putting the settings back solved the problem.

Without doing that two SESS cookies are set for .example.com as it appears we end up attempting to set a cookie for ..example.com.

reglogge’s picture

I posted a new issue for Drupal 7 relating to this here #1005570: Document leading dot requirement for $cookie_domain in settings.php. Usually problems like this should be fixed in HEAD first and then backported, but since this issue here has jumped back and forth between Drupal 6 and Drupal 7 quite a bit, I chose this path.

reglogge’s picture

I posted a new issue for Drupal 7 relating to this here #1005570: Document leading dot requirement for $cookie_domain in settings.php. Usually problems like this should be fixed in HEAD first and then backported, but since this issue here has jumped back and forth between Drupal 6 and Drupal 7 quite a bit, I chose this path.

Marko B’s picture

NROTC_Webmaster’s picture

Status: Active » Needs review
FileSize
766 bytes

Why can't this be fixed the same way for D6 as they did for D7. I have ported the patch. Please test and let me know your results.

Status: Needs review » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.