I think this best describe the issue: #1884596-1: Intermittent access denied for bakery/login on master coming from slave., reproduce here:
I think you can reproduce the problem by logging out of the slave site (this deletes the CHOCOLATECHIP cookie and the slave session but the master session cookie is untouched)
CHOCOLATECHIP cookie is gone now so no auto-login will occur, when trying to log in with username/password it redirects to the master andn I think it gets confused because there is a Session cookie for you. So basically you're trying to re-login to master while there already is a cookie for the master.
As soon as you delete the Master session cookie (manually or by logging out of master) one can log in with username/password again from the slave.
Original issue:
I have this setup, tested in Chrome 25:
Master: http://master.test.local.org/
Slave: http://test.local.org/
Cookie Domain: .test.local.org
Logging in on Master site:
- sets CHOCOLATECHIP cookie in test.local.org domain
- sets SESS* cookie in master.test.local.org domain
- logs in successfully
Loading the Slave site:
- consumes CHOCOLATECHIP cookie
- sets new CHOCOLATECHIP cookie in test.local.org domain
- adds SESS* cookie to test.local.org domain
- logs in successfully
Logging out from Slave site:
- deletes CHOCOLATECHIP cookie from test.local.org
- deletes SESS* cookie from test.local.org
- SESS* cookie in master.test.local.org stays
Loading the Slave site:
- CHOCOLATECHIP cookie is missing so no auto-login
Logging in on the Slave site:
- redirects to Server: http://master.test.local.org/bakery/login
- returns "Access denied"
Only when logging out from the master _and_ the slave one can login to the slave again. As long as the master session cookie is present the slave cannot log in.
Bakery should delete the master Session cookie when logging out from a slave.
Comment | File | Size | Author |
---|---|---|---|
#21 | bakery-slave-login-fix-1945936-21.patch | 1.66 KB | dajjen |
#20 | bakery-slave-login-fix-1945936-20.patch | 1.66 KB | dajjen |
#17 | bakery-slave-login-fix-1945936-17.patch | 1.65 KB | miax |
Comments
Comment #1
Jeroen CreditAttribution: Jeroen commentedSeems to be a duplicate of this one: http://drupal.org/node/570018
It's still not fixed though and the problem was logged in 2009. Has any progress been made?
Comment #2
Jeroen CreditAttribution: Jeroen commentedHere's a patch I made. I think it works, but check it out.
It used to be so that the bakery_login on master had an 'access callback' => 'user_is_anonymous'.
In case you logged in on master, logged out on slave (which deletes the slave session cookie) and log in on slave again then we'd get an access denied from the master because we're not anonymous (master still has the session cookie).
So, now the 'access callback' for bakery_login() is just TRUE. When logging in anonymous we keep the flow that we already had, but when there's a session cookie for the master, meaning we're not anonymous, don't send call submit_login_form() in bakery_login as that will end you up on the master site, but just call user_authenticate to validate the slave's username and password.
Comment #3
Jeroen CreditAttribution: Jeroen commentedComment #4
coltraneMarked #1884596: Intermittent access denied for bakery/login on master coming from slave. as a duplicate of this issue since they both are about the access denied message when re-authenticating on slave. #1884596: Intermittent access denied for bakery/login on master coming from slave. has a possible fix for this issue.
Comment #5
Jeroen CreditAttribution: Jeroen commentedApplying the patch from #1884596: Intermittent access denied for bakery/login on master coming from slave. does not really seem to solve the issue. It still throws the "access denied" error.
It does not change the fact that bakery/login is called on the master which has an access callback of user_is_anonymous. The master _has_ a session cookie so Drupal does not consider you anonymous.
Comment #6
solotandem CreditAttribution: solotandem commentedBased on my tests of the login workflow in each of these environments:
- using bakery with HTTP only
- using bakery with mixed HTTP/HTTPS in conjunction with securepages module
a consistent behavior occurs using FireFox and Chrome (or Chromium), namely:
- testing with non-root user
-- login to one site makes you logged in to other
-- logout of one site makes you logged out of other
- testing with root user
-- login to one site makes you logged in to other
-- logout of slave does NOT cause logout on master
---- re-login of slave fails with redirect loop
-- logout of master does NOT cause logout on slave
---- re-login of master works
I have not concluded whether the different behavior is attributable to core or bakery.
Agreeing with the earlier comments above, I have found the redirect loop mentioned above is due to the presence of a session in the master, so that the access callback to user_is_anonymous() for the 'bakery/login' URL on master fails.
Testing by myself and others on a production site has produced inconsistent results, e.g. #1536188: Strange Behavior Logging In, but the explanation seems to be in the values returned in $_COOKIE not the bakery code. That said, if the cookie values are off, it wreaks havoc with bakery code and causes undesirable results.
Comment #7
coltraneThe 403 message on /bakery/login on a slave was fixed with #1965634: Authenticated users get 403 if they land on bakery/login I think this issue should stay open for fixing the user_is_anonymous() check on master.
Comment #8
neclimdulThe continuing with user_authenticate and the rest seems a bit odd though since they're already logged in so "failing" to log them in is a bit weird IMHO. If I'm reading the code right, we'll pass back the "you failed to login" message but at the same time the chocolate chip cookie has already been baked in hook_boot so they will still get logged in.
Comment #9
neclimdulAlternative approach I've been testing. Seems to work well. -w version supplied to show actual changes since its mostly indenting.
Comment #10
brandy.brown CreditAttribution: brandy.brown commentedI tried both versions of #9 without success change in behavior.
My workaround: create a rule that when a user logs out they are redirected to the master site's user/logout page. Then the user is logged out of both and once they log back in they can access the slave site.
Comment #10.0
brandy.brown CreditAttribution: brandy.brown commentedAdded some more info.
Comment #11
coltraneComing back to this issue is confusing so if anyone is still experiencing an error here would you please update the summary with what the current issue is?
The title "Master Does Not Delete Session Cookie When Slave Logs Out" is not accurate nor the summary's points in "Logging out from Slave site:". Logging out of a slave site does not redirect you to the master, so there's not way for your master SESS cookie to be deleted until you visit the master. That said there's no risk to that session-reuse on master since the SSO cookie isn't valid.
Comment #12
ckngComment #13
ckngUpdated title as previous title is misleading.
Patch in #9 missed baking the chocolatechip cookie. Attached patch fixes that.
Comment #14
ckngLooks like I run into another issue after solved it with patch #13:
Master: User A still logged in
Slave: User A logged out
Slave: User B logged in successfully but as User A, due to we are baking the chocolatechip based on User A.
What's the solution for this?
1 - Logged out User A on Master and logged in User B?
2 - When user logout, should logout from all sites?
Comment #15
ckngAfter reviewed existing patches, it seems patch #2 is the correct working version for solution 1 in previous comment.
Comment #16
btopro CreditAttribution: btopro at Pennsylvania State University commentedConfirming that patch in #2 works
Comment #17
miax CreditAttribution: miax commentedI can also confirm that the code in #2 works. But I had some problems applying the patch to latest dev. Attached is a patch containing the same code but with some tweaks so it is able to apply on latest dev.
Hope someone find this useful.
Comment #18
pwolanin CreditAttribution: pwolanin at Acquia commentedDiscussion with davidstrauss - seems like the real fix is to delete the Drupal session if there is no bakery cookie
Comment #19
renefreund CreditAttribution: renefreund commentedAlso keep in mind, that you visiting "bakery/login" as guest so the page is cached. If someone somehow get a 403 everyone else will get a 403 too.
D7:
so first line in bakery_login() and bakery_register() should be:
drupal_page_is_cacheable(FALSE);
Comment #20
dajjenReroll patch against latest dev
Comment #21
dajjenAhh missed a small thing in the reroll
Comment #22
aitala CreditAttribution: aitala commentedI'm running into this issue with patch #21 installed with a D6 to D7 Bakery setup.
Thanks,
Eric
Comment #23
btopro CreditAttribution: btopro at Pennsylvania State University commentedhere's the patches we run for elmsln -- https://github.com/elmsln/elmsln/tree/master/core/dslmcode/shared/drupal...
Also this comment may shed some light eric -- https://github.com/elmsln/elmsln/issues/2512#issuecomment-466424857
Session setting that helped an adopter fix this in their setups.