Movable Type authentication system integration

(This article was originally written in early 2005 and has been imported into this wiki. Some of the formatting may be off-kilter — sorry.)

(Also, there had been a warning indicating that this no longer worked with Movable Type 3.34. That was a lie.)

notes on integrating SNF’s login system with Movable Type

This page is a dump of my experience integrating the user authentication system of this site with our Movable Type installation, essentially replacing TypeKey. The following notes are very rough and disorganized, and they are not intended to be a comprehensive guide to the subject; moreover, they describe issues that may or may not be generally useful to other web sites. Nevertheless, I do offer this with the hope that the information here may prove of some use to other web developers.

the existing authentication system

Spaceship No Future’s existing authentication system is very simple, working like this:

  1. User clicks login link
  2. User enters username and password
  3. Backend checks username and password: the given password is hashed and compared to a password hash stored in the database
  4. If the login succeeds, a login cookie is created, and the user is redirected to the original page
  5. Any page that finds a valid login cookie can assume that the user is logged in

The login cookie consists of the username plus a hash of the username. The idea is that the cookie can’t be manually faked, because the secret word used to generate the hash would have to be known. However, the cookie can be intercepted and used in playback attacks, so this obviously is not a completely secure system. Because this web site is not used for anything particularly sensitive or important (e.g., $$$), I’ve assumed that this system is adequate. The TypeKey system seems to be more thoughtfully defined and a little more secure, and by integrating MT with my site’s login system, I’ve probably lost some of TypeKey’s advantages in the process.

creating a TypeKey replacement

A quick interjection of thanks: Throughout the process of integrating the SNF auth system with Movable Type, I found the Everything TypeKey wiki to be invaluable, and Six Apart’s document Creating a Drop-in Authentication Service for Movable Type was essential. If you’re developing your own drop-in authentication system for MT, that document may be all you need.

By default, Movable Type supports user authentication using its TypeKey system. Movable Type also supports using a third-party user authentication system, but, as I found, its user authentication support is tightly bound to the TypeKey model, making this a harder task than I initially expected. Note that what I’ve done here is a little unusual in that my login system does not work exclusively with Movable Type, but must also interact with other custom apps on this web site (link-o-matic, shoplifters, unite, and, eventually, the bulletin board). Because the Movable Type authentication model differs so greatly from mine, I ended up with a single login system with two slightly different interfaces — not ideal, but good enough.

From a high level, my login system must have two entry points:

  • “Native” logins handled exclusively by my auth system. The custom apps on the site use this method.
  • Movable Type logins handled both by the MT code and my auth system.

finally, my notes

After reading Six Apart’s documentation, I quickly realized that the login system would need to be able to generate a DSA-encrypted signature, something beyond my coding skills. Luckily, this particular problem had already been solved by Stuart Parmenter’s tk. tk includes a sample login system, but more importantly, it includes a PHP dynamic library that computes signatures needed by the Movable Type authentication system. Importing this library at runtime requires support for the PHP dl() call, which is disabled in some PHP environments. For dl() to work on this shared server, I had to configure PHP to be invoked as a CGI script instead of as an Apache module.

I modified my login method to call the tk_do_stuff() function of, which, when given a user’s email address, username, nickname, and the current timestamp, returns a TypeKey signature.

I configured Movable Type to use my authentication system. This simply involves modifying the following configuration properties to point to my system’s URLs: SignOnUrl, SignOffUrl, RegKeyUrl, and IdentityUrl.

At this point, if a user attempted to log in to MT for commenting, MT would hit my login system’s SignOnUrl, and the login system would pass the URL parameters to, which would then return a signature that would be passed back to MT. I assumed my work was over.

I immediately identified a problem because my auth system’s login cookie expires after a few weeks; the MT login cookies expire much more quickly. The solution was to modify lib/MT/App/ so that the expires property of any cookie set by MT matched the timeout used by the login system. The file lib/MT/ actually contains a configuration property called CommentSessionTimeout which is intended for this purpose. However, doesn’t always look for this property when it should, which is why you must directly modify When this is fixed in MT, you’ll then simply need to add a setting for CommentSessionTimeout in your mt.cfg.

By the way, logging in through MT causes two cookies to be created: tk_commenter, which stores the user’s login signature (which is computed by, and commenter_username, which holds the user’s (urlencoded) username.

The next problem was that logins directly invoked via MT worked fine, but if a user logged in directly through my login system somewhere else on the site (remember, my login system must work not only with MT but with other apps on the site), then they would not be able to post comments to an MT entry. Simply put, the two login methods didn’t actually do the same things. I realized that “native” logins (those not handled at all by MT) must duplicate every action performed by logins handled by MT; otherwise a user would have to log in to MT separately, which would defeat the purpose of this exercise.

The first step was obvious: to create the same login cookies created by MT. Easy enough: First, create the commenter_username cookie and store the urlencoded username in it; then, create the tk_commenter cookie and store the urlencoded TypeKey signature in it, which is generated by

“Native” logins still weren’t working for MT commenters, though. I didn’t have much of an understanding of what MT was doing behind the scenes, and figuring out what to do next took me a few days, because I assumed that my existing logic was sufficient but simply buggy. To make a very long story short, I ended up having to work my way through the source code in lib/MT/App/ to follow the execution flow when a commenter is authenticated. (Adding logging while doing this is very helpful.) I nevertheless don’t claim to know exactly what is going on under the hood there, but I found that, when authenticating a commenter, MT stores commenter session information in its mt_session table, and it stores commenter identity information in its mt_author table. So any time a “native” login occurs, I need to insert rows into these tables to mimic MT’s behavior.

For commenter sessions, inserting a row into the mt_session table like so does the trick:

$query = "INSERT INTO mt_session (session_id, session_email, session_name, 
    session_start, session_kind) VALUES 
    ('$sig', '$email', '$name', $now, 'SI')";
$result = $db->query($query);

What’s SI? I don’t remember exactly, but it seems to indicate commenter sessions. A different possible value used in other contexts is KY.

An author record must also be created in the mt_authortable. MT will use this to populate the Commenters section of the MT admin interface.

$query = "INSERT INTO mt_author (author_name, author_nickname, 
    author_password, author_email, author_type) VALUES ('$name', '$nick', 
    '(none)', '$email', 2)";
$result = $db->query($query);

An author type of 2 is obviously a commenter, as opposed to a weblog author. If an author record with the same name already exists, I simply catch the exception and move on. Remember that in the TypeKey system, the username is a unique value, while the nickname can be anything.

When a user logs out, the session record in mt_session should be deleted. And with that, the main gotchas are essentially covered.


I did have some problems with, however. Some usernames caused it to crash when tk_do_stuff() was called. The problem seemed to have something to do with usernames that were either above a certain length or contained non-alphanumeric characters. Editing makesig.c and doubling the sizes of the variables msg and ret in the ZEND_FUNCTION(tk_do_stuff) section seemed to fix this. However, I don’t do C programming, and I don’t fully understand the workings of this code, so I’m a little nervous. At some point, I’d like to dig into this code and make sure it gracefully handles bad input.

Another potential problem with is that, unless I’m mistaken, it supports the TypeKey 1.0 protocol instead of TypeKey 1.1, so it’s possible that future versions of MT could break it.

in summary

In summary, the updated authentication system does the same things described earlier in this document, but adds additional sub-steps to step 4:

  1. Compute signature based on the user’s email, username, nickname, and current timestamp
  2. Create commenter_name cookie
  3. Create tk_commenter cookie
  4. Add new session to mt_session table
  5. Add commenter info to mt_author table

You can contact me at I welcome comments, but I am afraid that I cannot help you write your own web sites, and I will not respond to such requests.

[ article last updated 2008-07-31 14:53:14 by cobra libre ]