Bakery for Drupal 7: testing and synch-repair system

Yes, I really would be interested in this and also be able to help. If bakery for drupal 7 would be able to handle drupal 6 slaves (or vice versa) that would help us greatly in a careful upgrade of our sites.

Updated patch from the one in #2 by juliangb.

Applying patch to D7 CVS HEAD site and 6.x of Bakery on a Atrium site and I'm getting SSO to work. Need to test synchronizing fields next, email works though. Update: no syncing works yet.

One issue: the list of slaves isn't populated after saving, but it's set in the variable. Not sure why it's not filling in the text area correctly.

Working sync! only tested with email so far though

Edit: After spending so much time in bakery_user_presave() I realize the $_SESSION storage there isn't necessary ... Will update soon

I've created 6.x branch and 6.x-1.0-alpha1 release. That lets HEAD become the D7 compatible version.

http://drupal.org/node/528018 is the 7.0 release, though it needs 12 more hours to get re-generated to get a real tarball.

Thanks juliangb!

Updated patch:

* There was a leftover watchdog() for debugging, removed.
* Have to store updated fields in the session because we need to implement hook_user_presave() and hook_user_update() so updated fields are pushed on update, but not insert (like user register).
* Translated menu item was using old drupal_get_destination() style
* Form alter on user forms wasn't accessing user object correctly
* Updated bakery_uncrumble_validate() user search -- but, not sure if user_load_multiple() hashes 'pass' in the condition array. Haven't tested bakery repair.

Of considerable note:
In bakery_user_authenticate_finalize() I'm calling drupal_session_regenerate(). The D6 code has a similar line commented out but in my testing of a slave d7 site running drupal_session_regenerate() the user gets logged in correctly, and stays logged in to the master site. So it seems like it should be in to protect against unlikely session fixation attacks. juliangb, let me know if anything odd happens with your tests.

I think this could be set to RTBC pending some more tests. The remaining issues could be discussed and handled in followups.

I think it's good for dev branch.

Cool - committed - http://drupal.org/cvs?commit=355086

Thanks coltrane and juliangb!

Back to needs work and an updated title to better reflect the status. I'll update the project page to point to this.

This patch fixes the bakery slaves not being displayed after submitting the form. Problem was the default_value was being cleared by http://api.drupal.org/api/function/_system_settings_form_automatic_defau...

This patch corrects the error on d7 slave site. The translated menu link was use the destination string instead of the array.

Now committed - #18: http://drupal.org/cvs?commit=360148 and #19: http://drupal.org/cvs?commit=360150.

Thanks for finding them and fixing them, juliangb and coltrane!

Here's working account repair for D7. On my D7 slave site I get an error about the stroopwafel key not being present in POST, but no code during bakery/repair should be calling bakery_taste_stroopwafel_cookie() that I can tell.

@juliangb - you mean as an anonymous user?

yeah, @juliangb can you describe how you get a 403?

The first hunk seems wrong to me:

-        $result = db_query("SELECT COUNT(*) FROM {users} WHERE init = :init", array(':init' => $cookie['init']));
-        $record = $result->fetchObject();
-        if ($record['count(*)'] == 0) {
+        $count = db_select('users', 'u')->fields('u', array('uid'))->condition('init', $cookie['init'], '=')
+          ->countQuery()->execute()->fetchField();
+        if ($count == 0) {

Do we need to count or just say "is there at least one record?" If we need to count, we should use a sql count(1) style query. If it's a test for "at least one record" we should do a range query to limit the number of rows it will scan.

NEVERMIND! I didn't notice the little ->countQuery() in the chain. Brilliant work.

I think we should move the 403 when anonymous hits user/login on slave to a new a issue.

Here's an updated patch for account repair. I'm still not certain why bakery_taste_stroopwafel_cookie() is called on bakery/repair, but this patch does an isset() to avoid the message.

Fixed - thanks coltrane!

http://drupal.org/cvs?commit=361266

I agree about the 403 vs. redirect. I suggest we revisit that flow as a whole.

Minor update, the INSTALL.txt :)

Hottest! http://drupal.org/cvs?commit=361278