Session cookies? (Till the browser is closed.)

[michalrus]

According to Wikipedia:

https://en.wikipedia.org/wiki/HTTP_cookie#Setting_a_cookie

… session cookies are the ones that have no MaxAge= or Expires=. They are cleared after the user closes their browser.

Could we have that? 🙏 I mean, expiry time can (should!) still be encrypted in session data, but some people might want to have the cookie cleared completely, after their browser window is closed (e.g. for the popular “[Don’t] Remember me” functionality).

So this is most probably a question of adding another field to AuthCookieSettings that would control whether this line is included or not at all:

servant-auth-cookie/src/Servant/Server/Experimental/Auth/Cookie.hs

Line 687 in 5357861

("Max-Age", (BSC8.pack . show . n) acsMaxAge) :

[zohl]

Hello,

this is definitely a good idea and should be implemented. I'm working on it, so you might expect it to be done in 1-2 days.

Unfortunately, it's not that simple as you might expect: for each call of functions that use AuthCookieSettings you would have to choose manually whether it's a session cookie or not. That's pretty fine for addSession as it is called once for every cookie and is not ok for cookied wrapper. We can employ cookie's metadata here and let the wrapper do the job :)

[michalrus]

Awesome! 🎉 Thank you very much, and sorry for the naïve idea. 😅

[zohl]

Things are getting complicated... It will take more time, than I expected. Hope, you will not get angry :)

To explain the situation, here is what's going on:
We have Max-Age and Expires attributes to take in account.

Expires attribute uses absolute time (in GMT format) and is deprecated.
Max-Age uses relative time (in seconds), is told to be replacement for Expires. However, older versions of IE do not support it, so Expires is still used, especially when the one needs cross-browser interoperability.
This means, we have three types of expiration -- Max-Age, Expires and session cookies.

The first attempt was to get advantage of cookies' fields that browser attaches to it's requests. It worked for Max-Age, but failed for Expires. For some (probably historical) reasons, firefox omits Expires attribute in requests.
Thus, this method is useless and we have to store a flag right into the cookie, so the core algorithm will be altered a little bit.

Cookies' internals haven't changed since the very beginning, so I think it's a good opportunity to revise it and make it easier to extend for such and similar cases.

As for API changes, there will be one additional argument to addSession family functions (of enum type).

[michalrus]

Absolutely, take your time. =) For now, we can just use 30 min w/o “Remember me” and 2 weeks or so with it, but having real session cookies will be very nice.

That API change seems ideal.

Thank you for the wonderful support!

[zohl]

Done,

you need to import SessionSettings(..), ExpirationType(..) and def (the last one from Data.Default).

Instead of addSession acs rs sk session you should write
addSession acs rs sk def {ssExpirationType = ...} session.
By default, there will be session cookies.
There were some internal changes and renamings, that might affect custom handlers. In most cases it's just replacing wmData to pwSession.

[michalrus]

@zohl, excuse the pause in communication, but we had a somewhat hectic period.

Now I got some time to integrate this and… I just want to say that your support is amazing. ❤️

Everything works as expected! 😻

THANK YOU!!!