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:

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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jeroen’s picture

Seems 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?

Jeroen’s picture

Component: Documentation » Code
FileSize
1.8 KB

Here'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.

Jeroen’s picture

Status: Active » Needs review
coltrane’s picture

Marked #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.

Jeroen’s picture

Applying 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.

solotandem’s picture

Based 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.

coltrane’s picture

The 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.

neclimdul’s picture

The 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.

neclimdul’s picture

Alternative approach I've been testing. Seems to work well. -w version supplied to show actual changes since its mostly indenting.

brandy.brown’s picture

I 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.

brandy.brown’s picture

Issue summary: View changes

Added some more info.

coltrane’s picture

Issue summary: View changes
Status: Needs review » Postponed (maintainer needs more info)

Coming 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.

ckng’s picture

Version: 7.x-2.0-alpha4 » 7.x-2.x-dev
Issue summary: View changes
Status: Postponed (maintainer needs more info) » Active
ckng’s picture

Title: Master Does Not Delete Session Cookie When Slave Logs Out. » Access denied to /bakery/login after logged out from slave when still logged in to master
Status: Active » Needs review
FileSize
1.87 KB

Updated title as previous title is misleading.

Patch in #9 missed baking the chocolatechip cookie. Attached patch fixes that.

ckng’s picture

Status: Needs review » Needs work

Looks 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?

ckng’s picture

Status: Needs work » Needs review

After reviewed existing patches, it seems patch #2 is the correct working version for solution 1 in previous comment.

btopro’s picture

Confirming that patch in #2 works

miax’s picture

FileSize
1.65 KB

I 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.

pwolanin’s picture

Discussion with davidstrauss - seems like the real fix is to delete the Drupal session if there is no bakery cookie

renefreund’s picture

Also 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);

dajjen’s picture

Reroll patch against latest dev

dajjen’s picture

Ahh missed a small thing in the reroll

aitala’s picture

I'm running into this issue with patch #21 installed with a D6 to D7 Bakery setup.

Thanks,
Eric

btopro’s picture

here'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.