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

Jan van Diepen’s picture

I 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.

jdschroeder’s picture

What'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); with php $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.

dww’s picture

Title: Garbled user passwords » Insert users with already-hashed passwords
Category: bug » feature
Status: Active » Postponed (maintainer needs more info)

This isn't a bug at all. Look at the comment at the top of install_add_user():

// $Id: user.inc,v 1.1.2.6 2008/11/24 07:10:46 dww Exp $

/**
 * Add a user.
 *
 * @param $username
 *   User's username name.
 * @param $password
 *   User's plain-text password.
 * @param $email
 *   User's e-mail address.
 * @param $roles
 *   An array of role names to which the user should be assigned.
 *   For example: array('staff', 'moderator')
 * @param $status
 *   User's status. 1 = active, 0 = blocked.
 */
function install_add_user($username, $password, $email, $roles = array(), $status = 1) {
  ...

Notice what it says about "$password":

* @param $password
* User's plain-text 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?

dww’s picture

Marked #335528: User Save Functionality duplicate of this.

jdschroeder’s picture

In 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.

Boris Mann’s picture

Status: Postponed (maintainer needs more info) » Active

Profile 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.

dww’s picture

Version: 5.x-1.1 » 5.x-2.x-dev
Component: Profile Wizard » CRUD functions and includes

I guess that added flexibility wouldn't hurt if people actually need it.

digitalpro’s picture

I'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

James Andres’s picture

Version: 5.x-2.x-dev » 6.x-2.x-dev
Status: Active » Needs work

If anyone is still interested in this functionality, please provide a patch to the DRUPAL-6--2 branch of core/user.inc.