Tokens in cookie value and other feature enhancements

Issue Summary

Hi,

I'm developing a site at the moment that requires a single sign on system. We decided to use Drupal as the login 'hub', and since the Services module allows other web apps to get full profile info on a drupal user with the user.get method, we just needed a way of allowing the non-drupal app to see which Drupal user is logged in. I figured the best way to do this was to set a cookie on login and set about using this module to do that.

However, the module does not go far enough, so I have made the following amendments to it:

1. Allowed use of Token module tokens in cookie value, so you can use [uid] etc.
2. Added extra tokens for data from Profile module (if installed)
3. Added extra global token for unix timestamp
4. Added special token [sig] and an extra field for a configurable secret. If [sig] is used, secret is appended to cookie value (excluding '[sig]') and then SHA1ed and inserted where [sig] was specified.
5. Interpreted expiry time of zero as 'session cookie', which the module otherwise doesn't support.

The cookie 'value' I'm currently using is now:

[uid];[user];[profile-fullname];[mail];[account-edit];[timestamp];[sig]

Of those, profile-fullname and timestamp are my new bespoke tokens ('fullname' is a field I've added to the standard user account profile using the profile module and timestamp is always the current unix timestamp), and sig is the signature-generating token.

When I log in I get a cookie that looks like this:

1%3Bandrew%3BAndrew+Betts%3Bandrew%40example.com%3B%2Fuser%2F1%2Fedit%3B1269718201%3B562150d2d979d8f1c930e54a09f01358b1925b32

The non-drupal app, assuming it's on a subdomain of the same parent, can see the cookie, knows the secret, so can recompute the signature and verify that it is correct. It can then connect to Drupal's services API to get the user's full profile if needed.

Would you consider this for inclusion in the module? I believe the changes so far are backwards compatible.

I would also like to update the UI, but haven't done so yet. I don't think the separation into 'login' and 'logout' groups is necessary, and instead on the admin page I would lay out the entries (which I'd call 'cookie actions') like this:

Cookie name Event Action Operations
logincookie Log in Set session cookie with value xxxxxxxxxx on domain .example.com/ Edit | Delete
logincookie Log out Delete cookie Edit | Delete
cacheclear Publish Set 30 second cookie with value '1' on domain .example.com/ Edit | Delete

This would tidy up the admin UI (eg. normally operations links are placed on the right but this module currently puts them in the second column), but would also make it more extensible - in my example above, I've included a cookie that is set when the user publishes content, to force subsequent requests made by that user to pass through edge caches and always hit a backend server, which ensures that having written new content, the user immediately sees that new content on the site (rather than having to wait for database replication / cache expiry).

Finally, this system is still susceptible to replay attacks. I'd like to also introduce a token for the user's current Drupal session ID, and a method for verifying that the session is current via Services, which would enable the non-Drupal app to ensure that the cookie came from a current Drupal session.

What do you think?