Non-Transient Sessions in Play

[jducoeur]

A brief Nota Bene for users of Play Framework, mostly in case anyone else hits this silly problem and winds up in the same boat I've been in.

Querki has, until now, been entirely based on transient session cookies -- your session expires when you close the browser. That works okay on the desktop, since many of us *never* close our browsers, but turns out to suck on mobile: both Mobile Chrome and Mobile Safari seem to lose their transient cookies kind of at whim. (There's probably a definition of when somewhere, but I haven't found it yet.) Problem is, the Play Framework that Querki is built on has no documented way to set up a *non*-transient session. This has had me tearing my hair out for a year now.

Turns out that the answer, as usual, is to look at the source code. (Yay for open source.) It turns out that there is an as-far-as-I-can-tell-undocumented "session.maxAge" configuration variable, which sets the max-age setting on the session cookies, which is exactly what you want in the real world. There are also config variables for the other major aspects of the session cookie.

So as far as I can tell, to manage your session cookies, you want to use this config structure:

session {
  maxAge : nnnn  # Number of milliseconds for a session to live; if not specified, session is transient
  secure : true/false  # Whether to require HTTPS for a valid session cookie, default false
  httpOnly : true  # Whether to prevent JavaScript from accessing the session cookie, default true
  domain : xxxx  # The domain to use for the session cookie?  Not sure
}

I'll be trying this out on Querki later today; hopefully it'll fix the problem.

Comments

[goldsquare.livejournal.com]

Interesting.

Android programs tend to have Activities - not quite the same as a thread, but if you haven't studied Android, think "thread with stuff" and you can figure it out.

Android starts and restarts activities through a very complex lifecycle - with the Activity having many states, and many locally implemented calls for each state transition.

This is the diagram, with appropriate calls:


Note the comment at the left hand edge, about processes that need memory... and also note that screen rotation also causes the Activity to restart.

Activities can preserve their data objects between restarts, but it takes coding and effort. I wonder (I do not know) if these browsers are not saving transient cookies during the restart process. I'm sure they are doing so during the Pause flow, but I haven't checked.

But it is ALSO the case that, should memory start to run low, Android will call methods that prune memory in the application. It might be the case that the applications are throwing away transient cookies at that time. (The cost of not lowering your memory usage when you receive that method call, can be literally "fatal", so apps tend to take it seriously.)

Android is weird.

[jducoeur]

Yeah, I suspected something of the sort. What surprised me, though, is that Chrome on the desktop specifically preserves cookies across process boundaries: if Chrome crashes or gets restarted, my cookies restart in the same state they were in before, which is immensely convenient. (If a tad dangerous: exiting Chrome does *not* cause transient cookies to go away.) By contrast, the cookies in Mobile Chrome are much more fragile, and probably do go away along process boundaries the way you indicate above.

No idea why the difference. I personally think of Mobile Chrome as more secure than desktop, which makes it seem an odd decision, but I may be unusual in making sure that all of my mobile devices are properly locked...

[goldsquare.livejournal.com]

I'm sufficiently paranoid that I run Desktop Chrome in incognito mode much of the time - which makes permanent cookies into transient cookies. :-)

(And when truly paranoid, I run in Firefox with all cookie-setting off, and allow cookies on an individual basis.)

I think you would benefit from reading section 4 of RFC 6265, which describes how session cookies are defined.

Back when I was doing more web-programming than I am now, I always deliberately set cookie expiration dates, rather than trust the 10 billion browsers out there as to their default policies.

I also coded to defend against cookies being rejected - I hate how web sites redirect to a new page when cookies can't be set. If I reconfigure my cookie policy to permit that site to set cookies, I also had to go back and forth for each cookie, many times.

You should also bear in mind that your cookies' expiration dates might be overridden anyway. I often force "permanent cookies" to expire at the end of each session, or tab, depending. If the user agent maintains the data, the server-programmer has to defend against intransigent (or crappy) user agents.

This is your quality engineering friend, speaking. :-) Boy, have I effed over some web sites by hacking on their cookies... :-)

[jducoeur]

I'm sufficiently paranoid that I run Desktop Chrome in incognito mode much of the time - which makes permanent cookies into transient cookies. :-)

(And when truly paranoid, I run in Firefox with all cookie-setting off, and allow cookies on an individual basis.)

Fair enough, although I think you'll agree that you're not exactly a typical user. Querki does require an authentication cookie, but only for the duration of the session. (Plus one or two other short-term cookies for complex workflows such as joining a Space. Those *may* go away if I expand the remit of the smart Client.)

I think you would benefit from reading section 4 of RFC 6265, which describes how session cookies are defined.

(Quick skim.) Okay, I knew pretty much all of that. And by now it's a tad misleading in places -- for example, while it's technically true that max-age isn't universally supported, AFAIK in practice all modern browsers have it. (And since Querki requires HTML5 for now, that's fairly demanding in its definition of "modern".) Had forgotten the exact meaning of "domain", though.

You should also bear in mind that your cookies' expiration dates might be overridden anyway. I often force "permanent cookies" to expire at the end of each session, or tab, depending. If the user agent maintains the data, the server-programmer has to defend against intransigent (or crappy) user agents.

Oh, sure. And I have no problem with that -- it just means that you need to log in again after you scrag the cookie, which is pretty easy on a desktop, especially if you're using, eg, LastPass. We don't currently keep anything in the session cookie aside from the signed authentication token itself.

But when using Querki through the phone (which I do frequently, and it's an important usage model) entering a decent password over and over on the little onscreen keyboard kind of sucks, so I want to make sure users *can* remain logged in. I would bet that that's what 99% of users would prefer.

This is your quality engineering friend, speaking. :-) Boy, have I effed over some web sites by hacking on their cookies... :-)

And that's totally appreciated. The more problems I find out about now, the better...

[laurion]

To save memory and power, mobile browsers 'expire' old pages and then reload them when you go back to the browser tab. And then try to pretend that the page was loaded the whole time. A necessary evil of the hardware limitations. Very likely that each OS and/or browser has its own parameters for when to do this, but yeah, totally hoses the transient cookies.

[jducoeur]

The thing that surprised me about this is that Desktop Chrome *doesn't* lose transient cookies when it shuts down: it clearly saves them, even if you say "Exit" on the browser. I don't know why they don't follow the same reasoning on Mobile -- I'm pretty sure it would be easy to do so.

(Actually -- hmm, I wonder if this is a consequence of the "Continue where I left off" setting on Desktop Chrome...)