Hi, we are working on an offline-first app that ma...

# ktor

[Jonathan Mew]

Hi, we are working on an offline-first app that may be run on shared computers and are trying to put together a sensible session management process.
We'd initially used the out-of-the-box cookie-based sessions setup and an HttpOnly cookie to mitigate the risk of session hijacking via XSS.
However this poses a problem because when the user's session expires while they are offline, it makes it impossible to clear down that cookie programatically.

To solve this, we'd like to set up sessions based on one HttpOnly cookie and one that is accessible to JavaScript as a kind of composite key, and we're trying to gauge how much of the ktor sessions code we will be able to reuse and how much we would need to implement. That will enable us to clear one of the cookies to kill the session even while the user is offline, but we still get the benefits of the HttpOnly cookie while they are online.

Our understanding is that the existing cookie() feature expects to deal with only a single cookie. Also Sessions.Configuration is not an open class so we cannot create our own implementation there, which means we probably can't use the existing feature at all, and would need to reimplement most of the cookie session handling code. Is that correct?
Perhaps you have a better approach for how to handle an offline logout - we'd certainly be interested!

[mp]

Perhaps as a workaround for the flexibility issue you describe you could look for the cookie state post-JS-manipulation in a separate pipeline phase, and clear the session there? IOW, only the HttpOnly cookie is the session, and some separate code checks for "js requests the server to clear the httponly cookie".

[Jonathan Mew]

Thanks for getting back to us, and also for the suggestion. It definitely feels like a workaround as the Session management is less neatly encapsulated, but you're right it should work fine and save a lot of work.

[mp]

I agree, it's not ideal, but a multi cookie scheme would be hard to build an abstraction around since the rules are likely to be pretty custom (as they are in your case) 😕