When a user is created on the slave, the profile fields are not touched and left empty.
Only when a user edit's the profile on the master the changes are pushed.

I think after a user is created on the slave, the slave should request the profile fields information and receive them from master.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drumm’s picture

Status: Active » Closed (duplicate)
coltrane’s picture

Title: when a user is created on the slave, the profile fields are not updated » Update user data on subsite account creation
Status: Closed (duplicate) » Active

I'm reopening this issue to keep the code and discussion separate from #556666: Sync hooks: Enable sharing of arbitrary data

drumm and I talked about this at CPH and he argued for keeping with the master push mechanism as currently designed. The subsites need to trigger this though on the user's first request so our current thought is to have the subsite RPC to master to tell it to call user_save() which will then push out. A push fail would have to be reported potentially to the user, and we may want to consider a job queue rather than handling all in the first request.

coltrane’s picture

Title: Update user data on subsite account creation » Request account information from master
Category: bug » feature
Status: Active » Needs review
FileSize
4.69 KB

Altering the title to reflect the purpose better. I'm going to add the use case of creating the account on the subsite separately from the user requesting a subsite page. The attached patch is the first step of this.

It follows the stroopwafel method of a POST "cookie" for sending data. The subsite POSTs to the master a username and the master responds with name, email, and uid. Both request and response sign and encrypt. If the response is valid the account gets created.

Next need to loop over profile fields to send, call this during user login for the first time, and provide an accompanying sync hook implementation.

Question, is the callback path 'bakery' being used on the master ok? I can do bakery/create but will need to create the top level bakery path on the master.

coltrane’s picture

Here it is with the bakery_supported_fields. I realized when I was about to add a call to bakery_request_account() in bakery_init() that the chocolatechip cookie has been previously used to carry across user data. Since cookies are limited in the amount of data they can pass I don't think the chocolatechip cookie should be used for arbitrary data synchronization.

What about changing the account creation in _bakery_taste_chocolatechip_cookie() to use the bakery_request_account() POST and response?

coltrane’s picture

mebak caught a few cases of !name and !message and to be safe I've changed to @name and @message. He also spotted a missing period (.)

coltrane’s picture

This patch changes bakery_taste_chocolate_chip to not creating the account from the cookie but using the new bakery_request_account() request. I talked to David very briefly at the CPH sprint and without looking at the code he seemed to be generally ok with this.

Gerhard Killesreiter’s picture

This patch looks good to me, but it needs to be tested. It is now applied to scratch.d.o and api.scratch.drupal.org.

coltrane’s picture

Hmmn, I just created an account on scratch.drupal.org, followed the log in link, and when I jumped over to api.scratch.drupal.org I was an anonymous user. Going back to scratch.drupal.org I was still logged in. I'll need to attempt this again, and check if the chocolatechip cookie is set, but Bakery is all set up and running on scratch and api.scratch?

Gerhard Killesreiter’s picture

I actually don't know if it is, I assumed it was.

I need to check this later.

coltrane’s picture

scratch.drupal.org and groups.scratch.drupal.org testing hasn't gone so well today, but thanks to cyberswat and greggles for their help. I'm posting here the config that worked for me to test Bakery on my local machine.

Master:
Vhost record for master.bakery.local
settings.php has commented out $cookie_domain
Bakery variables:
Is master=TRUE
Master=http://master.bakery.local/
Slaves=http://slave.master.bakery.local/
Key=secretkey
Cookie domain=master.bakery.local

Slave:
Vhost record for slave.master.bakery.local
settings.php has commented out $cookie_domain
Bakery variables:
Is master=FALSE
Master=http://master.bakery.local/
Key=secretkey
Cookie domain=master.bakery.local

coltrane’s picture

Status: Needs review » Needs work
FileSize
7.41 KB

Here's a reroll now that slave site registration is in. It's mostly the same but accounts for the rearranged menu order and adds some comments. Marking CNW though since I want to test this more once #947692: Slave site registration when confirmation is required does not send email is fixed.

greggles’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Needs work » Patch (to be ported)

Committed to 6.x-2.x - http://drupal.org/cvs?commit=442758

Thanks, Ben!

Amazon’s picture

Drumm has confirmed this has been deployed on drupal.org and security.drupal.org.

fuzzy76’s picture

As far as I can tell, this is already ported to 7.x?

drumm’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev
Issue summary: View changes
Status: Patch (to be ported) » Closed (fixed)

Yes, it has been.