Explicitly set $subsite.drupal.org as the domain for cookie_domain and .drupal.org as the bakery_domain

Hi Andrew,

This is a problem that came up yesterday as we deployed a new version of the Bakery module on drupal.org.

It's affected several folks, but based on the reports not a very large number. I'm sorry you're one of them :(

But, the good news is that it's relatively easy to fix. If you can clear all drupal.org and *.drupal.org cookies (Edit > Preferences > Privacy > Remove individual cookies in Firefox on Linux) and also clear the browser cache (Edit > Preferences > Advanced > Offline storage > Clear now) and then log in again it should work fine.

Changing category and status based on my belief that this will fix the problem, but please reopen if not.

Thanks, greggles, that helped. I spent most of the day using d.o. from Google's cache until I went to Chrome and found your post!

Had the same problem for a couple days, clearing cookies for drupal fixed it.

Cookie clearing did fix the problem for me when this issue got me just now.

Greggles, you say "not a very large number" - maybe a look at the logs will show how much the number of 302 responses has risen since the new Bakery deployment?

Might just be that only a small number identified the workaround in order to make a report about it.

EDIT: There's only a half dozen or so rumblings on Twitter, so you're probably right that it's not a huge portion of the population.

Updating topic - this issue is not Firefox specific, it's cookie specific. (I was using Chrome.)

Related Bakery issue: #956540: Document proper cookie settings for master and slave sites

@grobot, I based my comment on several metrics. First, what do people do when they can't access a site and want to complain? Tweet - http://search.twitter.com/search?q=drupal+redirect The vast majority of the tweets are helping not complaining.

I also created a report of visitors by hour Google Analytics on Friday (the day after this code was rolled out) comparing traffic Friday to the previous Friday and they were within a reasonable margin of each other (sometimes this Friday was higher, sometimes last Friday was higher).

I haven't seen this personally and none of the reports have let me repeat it, but I'd gladly accept patches to fix it.

Heh - thanks @greggles, yes I used the Twitter metrics myself and figured that the number can't be too huge :) Just speculating there. Thanks for the update.

As well as the Bakery issue (in which jbrauer says he has a method to reproduce), there's #957608: 310 error in chrome also which is pretty much a dupe of this. (Maybe this is a dupe of #956540: Document proper cookie settings for master and slave sites, to me it looks like that's the Bakery issue and this one relates to the issue as seen on d.o.)

I've been seeing this problem since mid-late last week in Safari. Clearing my cookies lets me log in, but the problem recurs in 10-15 minutes.

See #958772: cookie problems with firefox, safari and chrome is also about this (and probably a dupe)

I've seen this problem too.

Clearing my cookies allows me to access the site, but then I can't log in!

Seems to be fixed. I could reproduce the issue consequently by the "Forgot your email" and clicking the reset password link. Since today it redirects as it should.

The other thing that could help debugging would be to get full http headers for your redirect session using something like live http headers or a proxy that logs the full request/response headers.

Again, send the text of the headers to my e-mail address listed in #11.

Hi, we are still seeing significant reports of this. I am getting emails and there's reports on Twitter.

http://search.twitter.com/search?q=drupal.org+redirects

Should this issue marked: fixed?

I've tweeted using @drupal to get more people to provide debug data.

I tweeted using @drupal on Friday. If you look at the content of the tweets since the introduction of the problem you'll see it's split about 70-30 people helping and people suffering. Be sure you only count the 30.

The issue to fix it is #956540: Document proper cookie settings for master and slave sites.

Erasing all *.d.o cookies has solved the problem for me. I was only experiencing the issue in Safari however, with Firefox and Chrome both logged in as well. Is there any clean way to invalidate user cookies (to fix this problem) other than resetting all sessions?

I had this problem too (in Firefox). I had to BOTH clear all *.drupal.org cookies AND clear my cache before it started working again. Seems to be working now though.

also had the redirect loop right now, clearing cookies helped

I had the same issue but only on one of my machines (Win7/Firefox), others were fine (1 Win7/FF, 1 Linux/FF).. clearing cookies has solved it, thanks.

this only solves the problem temporarily. I just had the issue again and needed to delete my cookies again (I'm using latest safari on mac os x 10.6)

After some discussion in irc, it appears that there are a couple of problems here.

One of them is that drupal.org is not using the same domain consistently on all cookies. Sometimes it is drupal.org and sometimes it is .drupal.org

The redirect problem can be repeated after clearing cookies and cache in at least safari.

We started to set all sites to use 'drupal.org' as the cookie domain on all sites, but we were still able get the redirect problem to happen.

neclimdul suggested that after Drupal 6.17 it was important that your domain has two . in it so we should use .drupal.org (see #458704: Don't automatically remove "www." from admin-set cookie domains for more details).

We changed security.drupal.org to use '.drupal.org' and after making that change it seemed to fix it for all subsites. That doesn't make much sense, but it's what jbrauer, coltrane, killes and I all saw.

So, we think we should switch to '.drupal.org' to fix this, but wanted to get more feedback before doing that.

There are at least three places we need to change that:

$cookie_domain = '.drupal.org' in settings.php
ini_set('cookie_domain', '.drupal.org'); in settings.php
$conf['bakery_domain'] = 'drupal.org'; in settings.php

Thoughts?

FWIW I'm still encountering this issue in Firefox (the 302 redirect loop).

Drupal.org is fine (at the moment) , but l.d.o gets me stuck in the redirect loop. (Even after clearing all drupal-related cookies.)

was able to access d.o. again after clearing all *drupal.org cookies in Chromium, will report if i have more issues..

To be clear, my 3 suggestions in #23 are for review. If we do them for one site and not others it will likely screw things up.

@wulff - killes updated some values that were improper for localize.drupal.org. It should now work.

@greggles it works. thanks guys!

subscribe

.drupal.org should be fine as cookie domain. Previous Drupal versions added stuff which made you basically unable to set up the domain in certain ways. Now it does not do that munging, so we should set our domains properly.

Let's try this again.

The idea of setting cookie_domain to .drupal.org caused each subsite to set that cookie whenever someone came there. Effectively when you visit d.o you get the session cookie and a CHOCOLATECHIP cookie both on .drupal.org domain. Then you go to a subsite and it sees your CHOCOLATECHIP cookie, sees your session cookie on .drupal.org doesn't match anything that it knows about, so it creates a new session cookie on .drupal.org effectively logging you out of the master site.

So, new proposal:

• we should explicitly set $cookie_domain (in settings.local.php) to be the "sitename.drupal.org".
• I think we should also set the $conf['bakery_domain'] to be '.drupal.org'

After discussion with Killes in irc, that step is now done on all the subsites in the bakery setup and I hope and believe this will fix it.

jbrauer tested for infinite redirects and found none.
coltrane and neclimdul helped review the concept.

Let's see how many sessions we can break this time.

I'm not sure this is fixed for all subsites and drupal.org.

What needs to happen:

1. The cookie domain in Drupal's settings.php (or settings.local.php) needs to be the domain of the site with a leading dot. Example for drupal.org: .drupal.org Example for groups.drupal.org: .groups.drupal.org
2. The Bakery variable bakery_domain needs to be (on all sites): .drupal.org

Deploying for API.drupal.org now. BZR revision 132 for those following along there.

I have now deleted EVERY cookie on my firefox, and I still can't log in -- just go straight back to the main page and the 'login/register' tab is still there.

Closing this issue, as there hasn't been any movement on it either way for close to three years. Please re-open if required.