Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When installing a new installation using a profile created by the Profile Wizard all user passwords have been completely garbled. It's impossible to log in to the new installation using any of the copied user accounts. Only after copying the encrypted passwords from the old users table's pass field into the new database, you're able to log in again. Seems the already encrypted passwords are encrypted again when stored in the profile.
Comments
Comment #1
Jan van Diepen CreditAttribution: Jan van Diepen commentedI forgot to mention that the e-mail system in the new installation was not working either, so I was unable to request for a new password.
Comment #2
jdschroeder CreditAttribution: jdschroeder commentedWhat's happening is that the user's password is stored as a hashed value. The hashed value is then re-hashed when the new user accounts are imported. The function install_add_user in crud.inc is calling Drupal's user_save function, where the password is being run through an md5 hash.
As far as I can figure, the easiest workaround would be to create a function within crud.inc that duplicates user_save with the exception of replacing
$v[] = md5($value);
withphp $v[] = $value;
and$values[] = md5($value);
to$values[] = $value;
.I know that replicating a core module function within a module is far from ideal, but it's probably the easiest way to go about it.
EDIT: I've now tested this to confirm that it works.
Comment #3
dwwThis isn't a bug at all. Look at the comment at the top of install_add_user():
Notice what it says about "$password":
You're just trying to do something weird, which is to use this function to insert users where the password is already hashed.
I'm not sure I understand the use-case for creating install profiles that generate users where the password is from a real user's password already hashed on a real site. I have two install profiles that create users, both of them are for creating test sites with some well-known users that have a dummy password (known via plain-text ahead of time, so people other than me can install the profile and have a test site they can log into).
Can you please explain why you think the Install Profile API should support creating sites with real pre-existing users where all you know is the password hash?
Comment #4
dwwMarked #335528: User Save Functionality duplicate of this.
Comment #5
jdschroeder CreditAttribution: jdschroeder commentedIn my environment we are dealing with passwords that have been synchronized from a central LDAP server, so we don't know the passwords to enter them as plain text (nor do we want to know them). This workaround suits our needs just fine.
Comment #6
Boris Mann CreditAttribution: Boris Mann commentedProfile wizard is pretty much deprecated at this point. One thing that would work would be to add a $hashed = FALSE at the end of install_add_user, and an IF statement around whether or not to md5 the passwords. Feel free to submit a patch that implements this.
Comment #7
dwwI guess that added flexibility wouldn't hurt if people actually need it.
Comment #8
digitalpro CreditAttribution: digitalpro commentedI'd love to see a flag like that (allowing for pre-hashed passwords) for user_save for a similar reason. I have an existing forum site that I'm integrating with drupal and would like to transition to drupal doing the password & user management. I've written the code to create a new drupal user, except I get a "twice-cooked" password when I use user_save with the previously md5'd password. Presumably raw SQL will do the trick but user_save is so perfect that it'd be great to be able to use it.--David Cardinal
Comment #9
James Andres CreditAttribution: James Andres commentedIf anyone is still interested in this functionality, please provide a patch to the DRUPAL-6--2 branch of core/user.inc.