mozilla/browserid — pull request #2026 by warner (2012-07-13 08:42:37+00:00)
Title: expire sessions when the password is changed

This series of patches causes client sessions to cease being valid when the user changes their password. Any outstanding sessions must re-authenticate.

Some notes to reviewers:

* There are several cleanup/refactoring patches before the actual functional change. These were needed to make the real change easy to read.
* The term "superSessionToken" derives from the idea that each client session (expressed as a cookie, with a session duration and authentication level) is actually part of a "super session", containing multiple normal sessions. The super session lasts from one password reset to the next (or until an explicit "log me out everywhere" action, which looks very similar). Normal sessions are not allowed to extend beyond the end of their super session.
* This adds a DB fetch at the start of each wsapi call, which is regrettably unavoidable if this feature is to work correctly. It also adds a DB fetch in any path which updates the session cookie. In the long run (i.e. after 1.0), I think the DB code should be changed to make exactly one fetch at the start of the wsapi operation (retrieving the whole user row, even if some pieces are unused), and then maybe do one write at the end of the operation. This would at least avoid doing multiple reads for a single function.
* stalled-mysql-test.js was modified to match the new reality (all wsapi operations require a DB, so some previous successes are now expected failures). I had to modify wsapi_client.js to pass the 503 from /wsapi/session_context back to the caller, instead of throwing a (sync) error that killed the test. I'd appreciate careful study here, to make sure I didn't screw anything up.
* I also changed test/lib/wsapi.js to make it possible to pass in an alternate context, so the test for this feature could simulate multiple parallel sessions (changing the password in one should cause the other to stop working).
* If a session stops working because the password was changed elsewhere, we want the client to go back to the login screen and ask for the new password. My test merely checks that the expired session gets a 403, and I don't know if that's enough to test the desired behavior, or if clients might get an ugly error and *not* be redirected back to the login screen. (since this is a wsapi call, and not a normal page fetch, I'm optimistic).