Moving the user migration support into the user module (#2534042: Move module-specific migration support into the user module) breaks UserLoginTest. This is because the default password service is replaced with the MigratePassword class, to handle old MD5 passwords by prepending 'U' to their hash. While this support was in the migrate_drupal module, it was not apparent because this would only happen when the migrate_drupal module is enabled, but of course if it's in the user class it's always taking place. We need to ensure that the effect only occurs within a user migration process, not globally on the site.
Comments
Comment #1
mikeryanComment #2
mikeryanIt wasn't that broken, just didn't implement getCountLog2(), so adding that enables #2534042: Move module-specific migration support into the user module to move forward. I do find the password service substitution a bit hacky, though - it may be worth looking for an alternative approach once the migration support moves to the user module.
Comment #3
mikeryanuser migration move complete, so we can think about a better way of doing this.
Comment #4
Jaesin commentedWhat do you think about creating a super light weight authentication provider module to handle this for drupal 6 users?
Comment #5
Jaesin commentedOK, Maybe that is a little heavy.
How about a separate module that will override
@user.auth?If you have D6 passwords in your system as the result of a migration, you have need to have it enabled. Otherwise, there is no need.
Comment #7
mikeryanFixed by #2598038: Invalid passwords after D7 to D8 migration removing the MigratePassword service entirely - nice!