Can no longer log on to the admin pages

[ContextSwitch]

It's possible this is an s9y bug but I'm not 100% sure.

I can no longer log in to the admin pages but get the following message:

You appear to have entered an invalid username or password

I am using postgresql as the database store. s9y has no trouble reading the data and displaying the blog pages as normal it seems that only logging in is affected. It is possible that my recent server upgrade (a few weeks ago) has caused this, I'm using Debian stable and the postgresql version in use is 8.4.7.

I have checked the data in the database by running my own SQL queries and checking the passwords with the SQL md5 function and all seems ok.

--
Geoff

[garvinhicking]

Hi!

Which s9y version are you using? Did you try another browser, maybe your current one sends stale information?

Recent s9y versions no longer use MD5 hashing, but sha1 with a salted hash. The salt can be found in the serendipity_config table with the name "hashkey".

The easiest way is to write a small php file like "test.php":

Code: Select all

<?php
include 'serendipity_config.inc.php';

$username = 'X'; // Your username!
$password = 'Y'; // The password you try to login with!

$r = serendipity_db_query("SELECT * FROM {$serendipity['dbPrefix']}authors WHERE username = '" . serendipity_db_Escape_string($username) . "'");
foreach($r AS $row) {
  echo "Found user with password: " . $row['password'] . " and hashtype: " . $row['hashtype'] . "<br />\n";
  echo "Expected password: " . serendipity_hash($password) . "<br />\n";
}
echo "done.";

HTH,
Garvin

[ContextSwitch]

Garvin,

that was very useful - thank-you. Using the test php script you provided it became clear that the hashing has changed at some point but I still have passwords created with the old one.

Using the results of the test script I have manually changed the data in the database to match the expected key, however I still cannot log in. In order to change to the new password I had to change the length of the password field (it was varchar 32 so I extended it to 64) also I notice that the s9y_authors table has no hashtype field.

I made a guess and created a new field thus:
hashtype character varying(8) NOT NULL DEFAULT 'sha1'::character varying

and filled it with 'sha1' but still I can't log in.

My s9y version is 1.5.3-2 (i.e. what's in Debian stable).

--
Geoff

[ContextSwitch]

Ok - I have a breakthrough! I returned the passwords back to their md5 values and placed 'md5' into the hashtype fields and I can log in again. I notice that hashtype has been changed by s9y from 'md5' to '1' but nevertheless things seem to be back to normal.

Thanks for your help.

[garvinhicking]

Hi!

If you didn't have the "hashtype" column, it seems you might have upgraded to s9y 1.5.x at some point without executing the database upgrades. Do you remember how you performed the upgrade? Usually, after uploading files, you should be greeted with a admin notice that changes need to be executed.

S9y has a fallback mechanism, when the hashtype is "non-1", it will use md5 login, then properly store the new sha1 value and switch hashtype to 1. So in your case, you should've repaired that mechanism properly. Before, supposedly the serendipity_config value for the "hashkey" was still empty...

Regards,
Garvin

[ContextSwitch]

Hi Garvin!

I have not manually updated s9y but I suspect that when debian stable went from lenny to squeeze then the package manager did the update ... <scans debian packages> ... yup, s9y went from 1.3.1-1 with lenny to 1.5.3-2 with squeeze. It appears that the package manager does not run any database updates when the package is updated (maybe I should file a bug with debian).

So I guess I need to run some of the sql files in the s9y directory tree (can't see which ones now because I'm at work) in order to bring the database up-to-date. Not sure how that will affect the changes I've already made but I can always backup the database first.

Cheers!

[garvinhicking]

Hi!

Sadly I'm not so involved in the debian/packaging maintenance scripts. Usually, s9y performs and detects all changes on its own. It does that by checking the serendipity_config_local.inc.php file (versionInstalled) and compares it with the version foudn in serendipity_config.inc.php

That way, you can also re-execute the update, by editing serendipit_config_local.inc.php and setting versionInstalled to 1.3.1. Then open your blog, and it should show you an update screen that you can accept.

I'd recommend to try that. Make a SQL dump of your database before, just in case the upgrader conflicts with your serendipity_authors DB changes. But I believe this won't be a problem.

Re-Executing the upgrade procedure again now is the best way to go, otherwise you might miss any specific updates. If you prefer manual updating though, just check the sql/db_update*.sql files for what s9y would perform. It's not plain sql, but substitues a few parameters in {brackets}.

HTH,
Garvin