brian warner email.txt

Hi folks.. I'm pretty sure everyone involved in Persona ops already
knows about this, but I figured I'd send it to services-ops just to be
completely sure.

My "expire-session" changes[1] finally landed on the master "dev" branch
last friday (10-Aug-2012)[2], and are scheduled to be included in the
branch we'll cut next friday (train-2012.08.17, I think), which should
turn into our Beta1 offering.

This feature includes a schema change, which adds a `lastPasswordReset`
field to the `user` table:

 "CREATE TABLE IF NOT EXISTS user (" +
   "id BIGINT AUTO_INCREMENT PRIMARY KEY," +
   "passwd CHAR(64)," +
   "lastPasswordReset TIMESTAMP DEFAULT 0 NOT NULL" +
   ") ENGINE=InnoDB;",

The expire-session feature records this timestamp in the encrypted
session cookie, and expires all sessions when the user changes their
password (causing the cookie's copy to not match the DB).

The code that references this field is designed to skip the comparison
when the DB contains a 0, so pre-existing sessions are not gratuitiously
expired the moment the new code gets deployed. Therefore the "DEFAULT 0"
clause should make it unnecessary to modify all rows when the schema is
updated: simply adding the new column should be sufficient.

The new schema and the code which references it (in lib/db/mysql.js) has
been reviewed favorably by atoll.. many thanks!

I don't know exactly when this code will be deployed to staging/prod
environments, but when it does, their databases will need to be
upgraded. We checked and found no occurrences of "SELECT *" or anything
else which would be broken by adding columns, so I believe it should be
safe to add the columns before the code is upgraded.

Please let me know if there's anything I can do to help out!

cheers,
-Brian


[1]: PR-2026: https://github.com/mozilla/browserid/pull/2026
[2]: in revision c7fb7ee5ea92901eff8b2e20d6a0bf36bf272689