Auto rebake cookies if logged-in on master

Example (found while testing new sept 6th ver)

Previous Bakery disabled, folders deleted, new bakery folders uploaded, enabled, original bakery settings maintained by db (bug http://drupal.org/node/574160 )

http://BAKERY_SITE user Beta logs in
navigates to
http://store.bakery_site
get's message

The name beta is already registered. please contact...

Which makes sense in one way, because yes, a previous version of bakery created beta on that site, but doesn't make sense in that the original key and info is the same from the db.

So, the user clicks the login link, which takes them back to http://BAKERY_SITE
Where they receive the message

Access denied
You are not authorized to access this page.

But are still logged in as themselves.

I have 1 master site and 4 slaves.

It sometimes happens that a person is not logged in in a slave while logged in in the master, don't know why, configuration is done right.
What happens is that when he goes to user/login in the slave he is forwarded to user/login on the master where he gets a

Access denied
You are not authorized to access this page.

I think when this happens the user should not get a "access denied", but that the cookies are rebaked, and user sent back to requesting site. This will help improve stability of login process of bakery sites.

There seem to be two issues here:

- OP/#1: Need for something to happen on slave://user/login so that login links still work.
- #2/#3: Refers to access denied on master://user/login after login problems on the slave.

The first is being handled in #787090: Use hook_menu_alter rather than aliases, so I suggest this issue changes to focus on automatically rebaking cookies and returning to slave if a user is still logged in on the master.

Julian's summary and proposal make sense to me.

@catorghans

Make sure that you have also placed your cookie domain information in the $cookie_domain variable in each site's settings.php file. The setting in Bakery's configuration will only tell Bakery which cookie domain to use when baking the cookies, Drupal still needs to be told which cookie domain to respect via the settings.php file.

As long as every site has the correct $cookie_domain set in settings.php, when you log out of one site, it will invalidate the cookie thus logging you out of all sites that share that cookie domain. This will prevent users from being logged in on master but logged out of slave.

Updated issue summary to be about #4 point 2, rebake cookies if already authenticated on master.

To allow access to bakery/login to rebake the cookies we'd need to change the access argument from user_is_anonymous(). On a Drupal 5 site the access callback is (because core doesn't have this check)

function _bakery_user_is_anonymous() {
  $type = 'OATMEAL';
  if (ini_get('session.cookie_secure')) {
    $type .= 'SSL';
  }
  return isset($_COOKIE[$type]) || !$GLOBALS['user']->uid || !empty($GLOBALS['menu_admin']);
}

However, it's not enough to allow authenticated user's to pass through bakery_login() to have the chocolatechip cookie rebaked and be sent back to the subsite. bakery_login() executes the login form which does a drupal_goto() if the user is authenticated.

I'm having trouble reproducing this on http://bakerym-drupal.redesign.devdrupal.org/ and http://bakerys-denver2012.redesign.devdrupal.org/.

Deleting the bakerys Drupal session, either by removing the cookie from the client, or removing the session from the DB, always results in a fresh session being created.

Deleting the chocolate chip cookie logs out of both sites immediately, via _bakery_taste_chocolatechip_cookie() invoked from bakery_boot(). If we want to do this, we also need to "Logging out the user with the bad cookie." only on slave sites.

Since we do log people out everywhere if bakery cookies are bad/missing, I'm tempted to mark this as won't fix. To me, it seems like that behavior will ensure logging in is consistent on all sites and avoid this problem.

Does this happen all that often?

IMO we could just change the access callback and behavior of bakery/login to detect this scenario and do something right.

If properly configured, it shouldn't happen, all the cookies expire at the same time.

If I'm understanding this correctly, changing this isn't just changing bakery/login. We also need to change bakery_boot().

I think by changing bakery/login we could reduce the pain/confusion of a user who just tries to login again.

I'd also be fine won't fixing this. I don't think it happens much any more.

There was some login confusion for DrupalCon Denver registrants, and Munich too. I think the upgrade will solve some cases. We should upgrade and see what's left.

Marking this as won't fix.

I had this occur on a site I designed today, thought it worth sharing.

Logged in on slave site (7.x.2-alpha3), redirected to example.com/bakery/login (D6) with access denied error.

Appears only way to resolve is to logout of master site and login again (on master or slave).

Just to be sure I'm not misunderstanding this issue.

I have a D6 (Open Atrium site, slave) and a D7 (master).
On both sites I've enabled the -dev modules.

I had some errors with the D6 version, which is posted here: #1885058: Loggin in from client site results in Duplicate entry error

With this patch, logging in and pulling users works fine. However, there is one use-case still failing; logging in from the slave site.

Steps to reproduce

- Verify cookie_domain is set in settings.php
- On master and slave, both log out.
- Go on slave (D6) to /user and enter credentials of an exiting account on the D7 account. This account does not exist yet on the D6 site
- I'm logged in on the master site but am redirected to bakery/login with an Access Denied, instead of being looped back to the slave site
- When I navigate back to the slave, I'm NOT logged in there.

Seems related to this thread, but I have no clue what's going wrong.

Please re-close if I'm missing something. Because it might be related to the D6 version, I'll change the version as well.

Re #16, closing this as a duplicate of #1945936: Access denied to /bakery/login after logged out from slave when still logged in to master because it has a patch and detailed reproducible steps

Updated issue summary.