Monday, October 21, 2019

Drupal 7 / Ubercart 7 - Bulk Password Refresh with One Time Login Module

Drupal core 7.67 / Ubercart 7.x-3.13 / Stability Theme

Bulk Password Refresh with One Time Login Module

After moving thousands of customers from our Drupal 6 System to our Drupal 7 System, we became keenly interested in a way to ask them to refresh their passwords.

We were interested in this for two reasons:

1.  Many of the passwords selected by our customers were terribly weak and in need to strengthening in these days of massive website hacks


2.  While we could migrate many things, we were unable to migrate passwords between the Drupal 6 System (MD5) and the Drupal 7 System (SHA512).

The Drupal maintainers, in all their wisdom, had decided to change the password encoding strategy from  md5 to sha512 between Drupal 6 and Drupal 7 while providing nothing to production sites that would then need to migrate thousands of users across the major Drupal versions.  Terrible.

Seeing as we were confronted with the challenge of thousands of password changes in a relatively short period of time, we became keenly interested in ways to perform a bulk password refresh that, when coupled with a more stringent password selection process, would make our site much more secure.

Looking around, I found the he One-time login Module, which seemed custom-designed to enable me to do exactly what I wanted:  Force every selected user to re-set their password.

The One-time login Module features the following characteristics:

The promise of the One Time Login Module was that, using its interface after importing all I could from the Drupal 6 System into the Drupal 7 System, I could then issue a mass password recovery process that would send verification emails to all of the relevant users in one shot.

Oh, if only.

Initially, Installation of the One Time Login Module was fast and easy.  Once the module was in place some very interesting new options appeared in the Drupal Administration Console:

It all seemed so simple.  Deceptively simple, as it turned out.

Trying to be somewhat studied and cautious, I created a test user (GL) in code and inserted that test user into the back end:

I then navigated to the area of the Drupal 7 System responsible for user operations (which is named People, for some bizarre reason)

Selected the USERNAME GL 

And then invoked the recovery email process on that user (GL):

The update was an apparent success:

Next, I checked my email to see if a recovery email had been issued:

Opening the email, I read the contents, which includes a really looooooong URL:

Clicking on the URL led to the following screen:

Everything looked great, so I clicked on the LOG IN button and was presented with a screen featuring a pre-populated email address block and blank password blocks:

So I started to enter a new password, and as I did so the criteria for a good password appeared:

These criteria a perfectly satisfactory for our new password strategy, and all I needed to do was come up with a password that met them.  Great!

Feeling pretty good about this process, I confirmed a couple of other pieces of information (Language settings, Locale settings) and then clicked on the SAVE button

Uh Oh

It seems that the Drupal 7 System thinks the email is wrong somehow - but that's the validated email that the Drupal 7 System provided in the first place!  

Also, my handy-dandy passwords have now vanished!

What's interesting about this situation is that if I choose to enter a different email address, even one that isn't validated - the process completes successfully:

Here's what I got when I supplied an email address different than the validated one:

And then I was able to log in to the website with the new password and unverified email:

So, the issue seems to be somehow linked to the email address being improperly flagged, which makes me think that there's something internal to Drupal 7 going on behind the scenes...


After some further investigation and Internet sleuthing, I discovered that the problem has to do with a conflict between the One Time Login Module and the Login Toboggan Module.  

Once I disabled the Login Toboggan Module, the One Time Login Module started to function correctly and users could refresh their passwords without having to supply a new email.

For now, simply turning the Login Toboggan Module off helps me to accomplish what I want, but eventually I will want to turn the Login Toboggan Module back on because I want to offer its functionality to my customers.


No comments:

Post a Comment