The UserPasswordResetTest::testUserPasswordReset() is bogus, since the drupal_get_hash_salt() uses a different $databases array to create the salt.

On the first request the databases connection does not contain the simpletest prefix, on the call initiated from user.pages.inc (user_pass_reset function) it does contain the prefix, so the return value is different #sadpanda

Possible solution: use a test module and hook_boot to set $drupal_hash_salt.

CommentFileSizeAuthor
#4 pass-reset-tests-2207497-4.patch2.15 KBJvE
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

attiks’s picture

attiks CreditAttribution: attiks commented
Issue summary: View changes
attiks’s picture

attiks CreditAttribution: attiks commented

I fixed this for the ga_login module, since I needed to test if the password reset link is still usable (patch can be found at #2207161-13: Automated testing), but this is an ugly fix.

If you want to test this patch, make sure your settings.php contains 'prefix' => '' inside the $databases in your settings.php file.

The proper solution is to set $drupal_hash_salt at install time and write it to settings.php.

PS: This is not a problem in Drupal 8, since it already writes the hash during install.

attiks’s picture

attiks CreditAttribution: attiks commented

PS: For some reason update_fix_d7_requirements does write a salt to settings.php

JvE’s picture

JvE CreditAttribution: JvE commented
Component: simpletest.module » user.module
Priority: Critical » Normal
Status: Active » Needs review
FileSize
pass-reset-tests-2207497-4.patch2.15 KB

I'm not sure I understand the summary but it does not look critical to me.

I've attached a patch with some extra checks in testUserPasswordReset().

Does this fail on prefixed databases?

Status: Needs review » Needs work

The last submitted patch, 4: pass-reset-tests-2207497-4.patch, failed testing.