Importing users with password

A FeedsTarget plugin

You'll need at least implement a FeedsTarget plugin. You can find existing FeedsTarget plugins in src/Feeds/Target. If you want to import plain text passwords, it seems like that the target will need to call setPassword() on the user object, according to the docblock of \Drupal\user\UserInterface::setPassword():

/**
 * Sets the user password.
 *
 * @param string $password
 *   The new unhashed password.
 *
 * @return \Drupal\user\UserInterface
 *   The called user entity.
 */
public function setPassword($password);

Importing hashed passwords

Importing an already hashed password will be more challenging. I don't know at what point in the process Drupal hashes the password and if there are ways to avoid the hashing and save the password as is. In the D7 version of Feeds, the hashed password was set via a separate database call, after the user was saved. If you need to go that route, you may need to override a method of \Drupal\feeds\Feeds\Processor\EntityProcessorBase in \Drupal\feeds\Feeds\Processor\UserProcessor.
The D7 issue where support for importing hashed password was added: #1611554: Support for encrypted passwords.

Great! Do you want to supply an unit test for this as well? The unit test should be added to tests/src/Unit/Feeds/Target.

It would be useful to have a functional test for this as well, to ensure an user can log in with the password that gets imported. But if you would like to supply the unit test first, that would be great. (An expanded base class for Feeds functional tests is expected later today as I'm busy finalizing #2939503: Unpublish/Delete nodes not included in feed.)

The test is working well, Many Thanks @Anas_maw

Code looks good. One thing I noticed is that the password gets trimmed. While I agree that having passwords that start or end with a space is bad UX or can cause confusion by the user, I wonder if Drupal also specifically ignores spaces at the beginning or end when you enter a new password in the UI?

#2939503: Unpublish/Delete nodes not included in feed is committed which means there is now a better base class for functional tests. Do you want to write a functional test for this as well? The test could be written in a similar way as FeedsCSVtoUsersTest::testMD5() (in tests/feeds_processor_user.test) from the D7 version of Feeds, with the difference that importing a plain password is tested, not a MD5 hashed one. The CSV file with users can be taken from the D7 version as well without modification. Take tests/feeds/users.csv and in the D8 version of Feeds, place it in tests/resources/csv.
You can call the test class PasswordTest and place it in tests/src/Functional/Feeds/Target.
For creating the feed type in the test, I think \Drupal\Tests\feeds\Kernel\FeedsItemTest::testUpdateItemsWithoutFeedsItem() could be a good example.

Why the patch was hidden? Let's show it again :)

Updated the patch. The patch from the #5 comment adds the password field and fills password data, but users can't login after import with old emails and passwords. Maybe we have some updates in the module or Drupal core.
To fix it, I added the flag "pre_hashed" to the password Target. Now it works nice - Feeds writes to the DB website hash from the D7 website and on the first user login it will be rehashed for D8 format automatically (Drupal 8.6.14).

Users from D7 now can login with old email and password.
Please note, we use hashed D7 passwords (MD5). Trim we use to clear spaces before/after of the password hash (if CSV/XML adds it).

Maybe we need the upgraded password importer with the setting to select hashed or source password type. But looks like the new feature.

@mikhailkrainiuk
Thanks for the updated patch. Your comment about that after import an user login failed shows that this issue requires a functional test to get in. Do you want to write one? Instructions are in #8.

Hi MegaChriz,

I'm importing users so need password field.

I followed this thread and patch 10 by manually creating two files, Password.php and PasswordTest.php in the respective folders. I had to create the Target folder. Then cleared the cache, then created a new feed type of user, but in the Target dropdown I don't see a Password listed. I uninstalled Feeds and reinstalled it, yet password doesn't show in the list.

Drupal 8.6.10
Feeds 8.x-3.0-alpha5

Perhaps this is misunderstanding on my part. Are file and folder names case sensitive?

Any ideas?

Oh, cancel my #12. The password does appear in the drop down. The mistake was all mine.

I'm using Feeds 3.0-alpha6

I tested both patchs.

#5 works for non-hashed passwords and new accounts (non existing users), but didn't work for update current users.

#10 I couldn't get this working with non hashed passwords.

Related code is in PasswordItem.php preSave() function.

@ dariogcode

I got same experience.

Patch #5 Working fine with plain password.

Patch #10 not working with plain password even I have field hashed=0 like this:
email,full-name,name,password,hashed
user-c@gmail.com,Coba C,coba-c,Password123C,0

#5 isn't a working solution.
#10 gave a good start. So, here is a patch.

It sill needs a functional test, I didn't find the time to do it. Sorry for that.

I've added the option to choose the type of password (Hashed or Plain) as a config.
I've also fixed the unit test.

Here's how Drupal will handle the imported passwords:

1. if it's a plain text, it's hashed normally then saved.
2. if it's pre-hashed, we should set the $values['pre_hashed'] to TRUE in prepareValue(). This tells Drupal that this password is pre-hashed. Drupal will save it as it is. When the user logs in for the first time, Drupal will automatically re-hash the password and save the new hash.

Oops. Fixing the patch that didn't apply.

Tested and works well!

I've tested the patch as well, but I noticed that when importing passwords in MD5 format, logging in failed.

I made the code now follow more the solution that is in the D7 version of Feeds. I also ported the functional tests from the D7 version. This means that instead of the setting called "pre_hashed" - which was presented as a checkbox in the UI - we now have a setting called "pass_encryption", which has three possible values:

• plain
• md5
• sha512

The last option is equivalent to "pre_hashed" being true.

I think this is ready.

Committed #19 with small coding standard fixes.