When deploying users, user passwords are not preserved.

I've looked into code and this appears to be a limitation that comes from the fact that deploy module uses services module, which in turn uses drupal_execute on either "user add" or "user edit" forms.

So, on one hand you got the md5 password with no way to regain the password in clear, and on the other hand you got the services module which wants to execute a form with the password typed in clear.

The quick fix for this must be that we set a standard password and expect the users to change it.
Long term solution is to use a custom module on the destination server to do the md5 saving straight to database.

Feedback anyone?

CommentFileSizeAuthor
#7 deploy.newuser.patch444 bytesbrad.bulger

Comments

pokadan’s picture

pokadan commented

Currently what happens is that user passwords get re-hashed(md5(md5(pass)) (if user does not exist on destination server).
If the user exist on destination server, not even using the initial hash from source server does not get you logged in the destination server.

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
commented

This SHOULD not be true. There is code in lines 206-211 of deploy_uuid.module to handle this very situation. (It manually sets the double-md5'd password back to the one that was originally sent.) Can someone verify that this is or is not working? Note that you must actually have deploy_uuid.module enabled on the dest server.

pokadan’s picture

pokadan commented

OK, I've seen the code, but it happed to me. The only way to login after a user deployment, was to provide the hash from original database thus having the system perform an md5(md5(pass) to get match.

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
commented
Status: Active » Closed (won't fix)

If someone can come up with repeatable steps to reproduce this I'm happy to look at it. Closing until then.

archvan’s picture

archvan commented

I am also facing the same problem. Deployment rehashes user password when users are deployed to destination server. Has anyone found any solution.

brad.bulger’s picture

brad.bulger commented
Status: Closed (won't fix) » Active

i am able to recreate this without trouble - add a new user account, switch to the new user, create a node, and deploy the node. i put a dd() call into deploy_uuid to see what was happening there, and it looks like the problem is that it is expecting $account['deploy'] to be set, and it isn't, so the password update is not done. this is the account record it saw in my test:

Array
(
    [name] => newerguy
    [mail] => newerguy@localhost
    [pass] => 5ef64bad8f9d7e0c85f821580e4d6629
    [status] => 1
    [roles] => Array
        (
            [2] => 1
            [3] => 3
        )

    [uuid] => 2557798434d852b9e3295c8.66431647
    [init] => newerguy@localhost
    [created] => 1300573336
    [access] => 1300573336
    [uid] => 48
)

i also had the user_service_save() function dump out the data that was being sent to it, and the 'deploy' value is there as it ought to be. so it looks like that 'deploy' value is being filtered away out of the account data at some point in its passage through the wilds of the user module, though i haven't tracked down exactly where or why yet.

brad.bulger’s picture

brad.bulger commented
StatusFileSize
new deploy.newuser.patch444 bytes

i updated the deploy_uuid_form_alter() function to add a hidden field named "deploy" and that does the trick. there might be some other way to do it, or you might want to use a different name - i just needed to get it working in the short term.

dixon_’s picture

dixon_
he/him
Primary language English
Location France
commented
Status: Active » Fixed

I can confirm this bug by following the steps in #6. I can also confirm that the path in #7 does the job. And that's good enough for me. Committed!

Thanks brad.bulger for a good description of the problem, and the patch! Much appreciated!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.