A number of our users have been suffering from a nasty bug recently, which I’ve finally figured out the cause of:
Discourse uses two cookies for storing data about a user’s session: an authentication token cookie (which determines who is logged in) and a session store cookie (which holds encrypted data about a user’s session). I’ve been storing data about a user’s Mozilla IAM session within the session cookie.
Unfortunately, there’s an inconsistency with the expiry dates of the cookies: the session cookie is set to clear at the end of a browser session, whereas the token cookie is set to expire a month from the last rotation (which happens regularly while a user is logged in). So, if the browser’s session is cleared, the token cookie persists - so a user remains logged into discourse - but the session cookie is cleared - meaning the extra IAM data is also cleared, and so some users (NDA/staff) get logged out because their authentication method isn’t deemed sufficiently secure.
I feel a bit silly for misinterpreting the session store as being within the context of a Discourse session and not a browser session. But, with it storing data for that kind of session, there isn’t any simple method for storing arbitrary data about a user’s Discourse session for as long as they are logged in with that session.
At least I hope there isn’t (aside from some horrendous monkey patching of the UserAuthToken
class) I spent quite a while when developing this originally trying to find if there was such a method.
Could we add something like a JSON column to the UserAuthToken
class, and logic to persist it across refreshes? This also had the added benefit of making it super easy for plugins to extend the “Recently Used Devices” user preferences section with their own data (like, in my case, whether a user used 2FA to log in with that session).
What are people’s thoughts. Have I missed something obvious? I’m happy to submit a PR adding this functionality if not.