Other Entries

Log

Resolving a Movabletype Password Problem

Yesterday wanted to try it out Zempt, an open-source weblog posting application for Windows, so downloaded and installed it—always a fun process on Windows—and discovered that my Movabletype password didn’t work. It still worked in my browser, since it’s stored in a cookie. So I tried to change my password. Bad move.

I was completely locked out of Movabletype. As soon as the password change went through, the system kicked me out and repeatedly gave me an incorrect login error. Meanwhile, my cookie was deleted and I don’t have a backup here at work from which to restore it. So I got home and reverted the password from a previous mysqldump file. But that didn’t solve the problem. As long as I had a good cookie, I could login no problem, but without a good cookie, forget it.

I’m not entirely sure what the root cause is, but here’s a probable explanation. Here’s the problem as I understand it, which I discovered by installing a second instance of mt and creating a second MySQL database.

At some version upgrade between 2.x and 3.16, and I don’t know which, Movabletype’s database field for the password changed from 40 characters to 60. I’m assuming that the algorithm for checking and creating passwords changed with the same upgrade. Funny thing is, the database upgrade script didn’t change the field size in my database. But there are new fields in the mt_author table, which leads me to believe that they just forgot to include the table altering code.

So here’s the solution. First thing, backup your database using mysqldump! That way you can always restore from the backup.

In the mt_author table, change the author_password type to varchar(60):

ALTER TABLE mt_author MODIFY author_password varchar(60) NOT NULL;

Then using the encrypted password from the second mt database, update the author_password field:

UPDATE mt_author SET author_password = "[60 character long password string copied from 2nd database]" WHERE author_id = [author id];

Now, the problem is that in order to accomplish this second step, you need to set up a second fresh install of Movabletype with a clean database and change the Melody user to your username and password. You can then copy the password out of the fresh database:

USE [newDatabaseName]; SELECT author_password FROM mt_author WHERE author_id = 1;

To do this without a second install, I would imagine that you could modify mt-load.cgi to only update the mt_author table and then copy the resulting password field into your user’s author_password field. Of course, I didn’t do this and it could be risky, but that’s what the backup’s for, right? Or you could set the password field to an empty string and try to login without a password—I’m not sure if this would work or not.

In any case, my problem’s fixed and I hope that this can help someone in the same boat as I was.

07/08/05 04:06PM Geekiness

Recently Played on iTunes

  1. “Abierto”
    Soul Food Taqueria
    Tommy Guerrero
    10/06/08 16:28
  2. “Hit Or Miss”
    Punk Rock Days: The Best Of DBL
    Down By Law
    10/06/08 16:25
  3. “Start!”
    Compact Snap
    The Jam
    10/06/08 16:22

Last 100 Songs >