Document proper cookie settings for master and slave sites

Clearing your cookies will solve the problem for you. It is not browser-specific, happened to me on Chrome.

Yes, clear your cookies.

Given only 2 reports of the problem on d.o and no new ones on twitter since the launch yesterday I don't think we should look for a code based solution.

I assume this is fixed for you, trevorsheridan, since you were ultimately able to post this.

As a PSA - http://twitter.com/#!/drupal/status/29092956135

I'm not sure where else to mention it without being overly annoying to people who are having no problems.

Hm I am still experiencing the redirect loop with Firefox 3.6.11 and 3.6.12. Tried clearing cookies and all other caches multiple times - but still cannnot login.

As the login works flawlessly with another computer (both machines are running Windcows 7) I guess it must have something to do with the privacy settings of this notebook. The way cookies are written to the hard drive must be somewhat changed in the new bakery version.

Chrome is logging in fine.

Am willing to provide more helpful bug reports. ;)

@eigentor, based on our discussion in irc I thought you were able to fix this?

Can you try creating a new firefox profile on the affected machine and see if that fixes it?

I helped someone else via e-mail who cleared all cookies from any drupal.org site and was then able to use the site without problem.

Ah O.K.. Creating a new profile helped indeed. I can login again now with the affected Firefox.

So, creating a new profile was just for debugging as a way to absolutely clear all cookies, cache and other settings. Now we know it can work and you there is just something to clear in your other profile to make it work.

I can't reproduce at the moment so leaving fixed but at least three times in the last couple of hours I had a situation where I was using d.o and got the too many redirects error. I cleared cookies and re-logged in to d.o and a few pages worked (issues and project pages) and then on some page load a few pages into my browsing the site I again got the too many redirects. In each case I had session cookies set for both drupal.org and .drupal.org.

I just reproduced with these conditions.

1) I was using Safari and was logged in to d.o but hadn't visited any pages on d.o in something like 60-90 minutes.
2) In the URL bar I entered http://drupal.org/project/nodewords and got too many redirects
3) I visited any other page and got too many redirects message

Looking at my cookies I now had session cookies set for drupal.org and .drupal.org
I cleared page cache
I deleted the session cookie for drupal.org and attempted to load pages. The redirect message persisted. On any attempt to visit a page the drupal.org session cookie was set again with the same name but a different value.
I deleted the session cookie for .drupal.org (but no other cookies) and the site came up as expected.

I've seen this several more times on multiple computers each time when it's going to be a problem the drupal.org cookie is reset multiple times on a page load. Clearing the .drupal.org cookie resolves it temporarily in each case.

OK I found one way to reproduce this reliably so I'm re-opening it.

If I clear all caches and any cookies for any drupal.org related domain and then log into d.o I can browse around as much as I want.
If I then visit api.drupal.org the .drupal.org cookie is set.
When I next load a page on d.o itself i'll get the endless redirect. The drupal.org cookie is set several times in this process. In fact I can even delete the .drupal.org session cookie WHILE the redirect loop is happening and it will load the page right away.

#957608: 310 error in chrome is essentially describing the same symptom.

@jbrauer, I followed the steps in #13 and couldn't get a redirect.

Noting that I saw a report from wmostrey in IRC that this was happening in Firefox 4b6 but not Safari.

My first two attempts to post this comment met with the frequent placement of the .drupal.org cookie followed by redirects.

Thinking out loud
Is there anything in d.o logs that shows anything useful or indicates when/why the sessions are being regenerated?

Could it have anything to do with different levels of access on different d.o sites?

I got the same thing.
Chrome 7.0.517.41
OSX

Based on the reports it seems unrelated to access levels. I don't believe there are good logs (they are not aggregated).

For folks who can repeat this, that's somewhat useful information to know the size of the bug, but the question is: is this something ongoing or one time. If you can repeat it in a brand new firefox profile that would help increase the understanding of the problem.

If someone could mail me (greg at growingventuresolutions.com) all of their drupal.org cookies when this happens that would help debug as well. Perhaps we can detect these malformed cookies and delete them.

If you are worried that e-mailing cookies is insecure consider: 1) my permissions on drupal.org hardware let me impersonate anyone I want 2) they are bad cookies anyway 3) you should delete all the cookies after sending them so that you wouldn't be vulnerable to having them copied anyway.

Let's figure out how to stop the insanity.

If Bakery doesn't look for the "redirect" (oatmeal) cookie anymore this should stop the problem. I'll test this locally by downgrading my installs.

The solution in #21 does require rolling out updated bakery to all sites again. The hudson job to do that (and drupalorg and the one or two other common modules) automatically is feeling like a better and better idea.

Based on the cookies someone just sent me, the problem was caused by having:

1 drupal.org sess cookie. 1 .drupal.org sess cookie. 1 CHOCOLATECHIP cookie.

I'd still prefer to get full request/response headers for a redirect session to be sure that's the problem.

I'm able to reproduce #13 using Safari 5/WinXp. (Log in to drupal.org/user, visit api.drupal.org, visit drupal.org, receive "Too many redirects" error).

Based on the fixups from earlier in the week it appears that we "just" need to have the following values explicitly set.

$conf['bakery_domain']: .example.com
$cookie_domain on master: .example.com
$cookie_domain on subsites: sub.example.com or .sub.example.com - either works fine.

I think this should either be done via documentation or it could be something we validate as we build the form and say "Hey, you're on the [slave|master] and your cookies are wrong. Sad panda."

i get this same issue with organic groups ( Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.) would a similar solution work for me?

@yosisays, that seems completely different. I suggest posting in the organic groups issue queue and leaving it there.

You can also install the devel module and enable the setting on admin/settings/devel to "Display redirection page" that should show what is happening.

thanks, sorry for hijacking the thread, turns out that spaces OG module was the culprit

The chocolatechip cookie (auth cookie) needs to be read by all domains so it must be set with leading dot in the UI but I think the master's session cookie domain need not have a leading dot.

I'll test the settings.php cookie domains out again.

My test setup on localhost with vhosts:

Master: bakery.local
Slave: slave.bakery.local
Testing with non UID 1 account

Test case 1 "explicit":
master settings.php $cookie_domain = .bakery.local
slave settings.php $cookie_domain = .slave.bakery.local

* Login on master, authenticated on slave
* Logout of master, also logged out of slave
* Login on slave, authenticated on master
* Logout of slave, also logged out of master

Test case 2 "not explicit":
master settings.php #$cookie_domain = .bakery.local (commented out, cleared cache)
slave settings.php #$cookie_domain = .slave.bakery.local (commented out, cleared cache)

* Login on master, authenticated on slave
* Logout of master, also logged out of slave
* Login on slave, authenticated on master
* Logout of slave, also logged out of master

Test case 3 "mixed":
master settings.php $cookie_domain = .bakery.local
slave settings.php #$cookie_domain = .slave.bakery.local (commented out, cleared cache)

* Login on master, authenticated on slave
* Logout of master, also logged out of slave
* Login on slave, authenticated on master
* Logout of slave, also logged out of master

Findings:
Regardless of settings.php cookie_domain Bakery SSO and logout across sites worked without fault.

Based on what was seen today with London2011 I think we document the process of drupal.org subsites differently than Bakery's documentation. Bakery's documentation should include information on setting the settings.php cookie_domain in a troubleshooting section only.

Here's an updated troubleshooting section. greggles, were could I document the rollout of Bakery on d.o infra?

I like http://drupal.org/node/1030588 because it is public and doesn't have roundabout access for editing & viewing. There is also https://infrastructure.drupal.org/node/154 and https://infrastructure.drupal.org/node/149.

committed http://drupalcode.org/project/bakery.git/commit/02ea569