By manObject on

I have discovered a weird problem that seems to be due to a password recognition issue. I do most of my development on my own PC using WampServer, serving to localhost only.
I have numerous instances of Drupal versions 5 and 6. Obviously with a localhost setup on a PC, I can't get Drupal to send me an email with details of how to log in temporarily, so when I forget the admin login password..., I am stumped! I assumed it would be a simple matter to go into the associated database using phpMyAdmin and change the password in the users table. With Drupal however, it seems a hashing algorithm is used to encode the password even before it gets the usual encryption using the MySQL PASSWORD(...) function.
I would be very grateful therefore to find out how this hashing is done, so that I can replicate it in order to re-create the encoding to pass on to the database. Someone out there must know roughly which script to look at?
Any help would be most appreciated, as I have a lot of content to revise!

⋅ Categories: Drupal 5.x, Drupal 6.x

Comments

manObject’s picture

manObject commented

I found a workaround for this problem and knowing just how frustrating it can be I would like to share it with all you other Drupalers:

As if creating a new Drupal installation, copy the entire file hierarchy of the problem site (custom modules and themes can be omitted) to another folder and name it something like drupal_temp.
DELETE the existing settings.php file and re-create it anew from settings_default.php
Create a new empty database for use with the temporary instance.
Make a note of the database username and password shown in the problem site's settings.php file.
Run the installation script for the temporary instance. Insert noted details for database username and password.
Be sure to set up the administration account username exactly as that used on the problem site.
Next set up the administration account password to whatever you would like to use with the problem site.
The temporary instance should install cleanly.
Check you can log in, log out and log in again to your temporary instance.
If all is well, open up your database administration program (I used phpMyAdmin) and browse to the users table of the database for the temporary instance.
Copy the encrypted admin user's password to the clipboard.
Now browse to the users table of the problem site's database and paste over the existing encrypted admin user's password.
You should now be able to log in, log out and log in again ad infinitum on what was the problem site.

A bit of a sledgehammer to crack a walnut perhaps, but at least it avoids delving into Drupal code.
It also leaves you with a clean Drupal instance ready for your next website!

Alex Ruis’s picture

Alex Ruis commented

I am new to Drupal and had to deal with this problem as soon as I logged out. Usually CMS's
do not work right out of the box, but the impact of this problem is rare ...

Since I usually start immediately tweaking code I dislike, I inspected all directories within
Drupal (7.12). To answer your question: you must look for the file "password-hash.sh" in directory "scripts"; in 7.12, cannot speak for any other release.

In the file you see a fragment of code:

/**
#!/usr/bin/php
<?php

* Drupal hash script - to generate a hash from a plaintext password
*
* Check for your PHP interpreter - on Windows you'll probably have to
* replace line 1 with
* #!c:/program files/php/php.exe
etc.
*/

So I moved the first line to line 3, commented the line out, added "original line 1" (in order to
recall what I did later) and replaced line 1 with the EXACT path to php.exe. If you simply replace that is enough.

When you think of how simple this is you wonder why the developers of the installation process did not add a field there in which administrators can enter the path to php.exe ... Do they expect to look for the password-hash file first?