In the generated authentication code by
phx_gen_auth, I learn the following:
A “session cookie” maintains the user logged in for the duration of the browser session (until the browser is completely closed generally). The cookie contains the user session token.
In addition to the session cookie, and in order to keep the user logged in after browser closes/re-opens, I can use a “remember me cookie”, with a long expiration date. With the generated auth code, the user can check a checkbox for the server to maintain his session for e.g. 60 days through the remember me cookie.
Renowned apps such as Facebook, StackOverflow, Gmail, (and most modern apps?) … do not provide the user with an option to keep longer session. The session are by default long so that the user stays logged in after browser closes. Correct me if I’m wrong, but this is mostly what we see today.
I was then wondering why didn’t we, by default, follow that approach of maintaining sessions, as it also allows for simpler code : working with one cookie vs two cookies (e.g. the current code is trying to fetch the logged in user from the session cookie, and if not found, try to find in the remember me cookie, and then if found, sets the session cookie, …).
Tokens in cookies are considered safe (as opposed as stored in browser), hence I don’t see the interest to have by default short-lived sessions that expire on closing the browser. Maybe in the case multiple users use the same computer?
However, what most app do though is prolonging the session automatically on logging in. With this mechanism, I didn’t have to enter my passwords in ages… This seems lacking in the generated authentication code, but again because another approach is used : have the remember me cookie expire after a precise amount of days.
So instead of a session cookie + remember me cookie expiring on a precise amount of days, on user’s consent, why not have a single session cookie expire after an amount of days, without user’s consent, and prolong that expiration date on login.