Page MenuHomePhabricator

Consider alternative cookie schemes for keeping users logged in
Open, Needs TriagePublic

Description

Consider different ways of keeping users logged in without long-lived cookies.

A couple suggestions from T68699: Increase "remember me" login cookie expiry from 30 days to 1 year on Wikimedia wikis:

[...]
Wouldn't it have been better to use a scheme that periodically (say, once a day) refreshed the SetCookie for active logged-users (for up to X (a year?) from the last real login), and leave the idle expiry at 30d (or perhaps even shorter, 2w or so)? That would get past the "editor gets logged out mid-activity once a month" sort of problem, increase convenience for the truly-active, and also increase security for the idle login sessions re: device takeover by another human if the raw cookie time gets dropped to 2w. Would require tracking on our end the last real login date and last cookie refresh date per-user, but that doesn't sound awful. Probably actually an improvement in terms of stats on logged-in users' inactive-ness.

[...]
Sending the session cookies back to the browser on every request is not that expensive, but I can imagine that not being very attractive. Ideally we'd programmatically find out when the login session expires, and refresh it one a day or so. Unfortunately, the expiration property of a cookie can only be set, not read.
The solution I used to use for my Toolserver is to store the expiration date given to the browser for the session id on on the server in the actual session data. Then whenever a request comes in and the cookie is more than e.g. 24h old, refresh it once.
This covers the use case proposed in this bug:
New users will not have to log in again after 30 days
(especially if they forgot their password and didn't
provide an e-mail address)
Whilst having two additional advantages:

  • We don't accept dormant sessions over a year old to be used to authenticate the user.
  • We do distinguish between used and unused sessions.
  • We provide even more convenience to users (never[1] have to log in again, not even once a year).

[1] never, that is, as much as we can help it. We may invalidate sessions for security reasons or when performing data centre maintenance. And browsers may garbage collect cookies at some point.

These do not have the same user experience as the T143015: Consider different "keep me logged in" login lengths for different user groups solution (inactive users will still get logged out), so this requires both product and technical input.

See also:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 15 2016, 6:06 PM
Tgr added a subscriber: Tgr.Aug 15 2016, 7:33 PM

Server-side session data has a short expiration time and might even be evicted on an LRU basis, depending on the type of session storage. Some sort of multi-cookie scheme is probably a better approach.

UX-wise, logging out users who are not around seems like an improvement to me. OTOH logging out users on rarely used secondary devices would be annoying.