Improvements to session management #439
Labels
component:backend
component:frontend
The bug is in front-end
tag:meta
type:enhancement
New feature or request
Currently sessions exist only in memory, that means, once you restart the service all logged in sessions will require login in again. Also there's a lot of duplicated code laying around managing this, both in the front-end and the back-end.
Ideally, all session related management should be backend only. The frontend only need to submit the form and either let the backend set the cookie or retrieve a JWT token and work with it.
Since the frontend is currently an SPA, and to ease working with the browser extension and allow other developers to easily integrate with the API I'm inclining towards the JWT approach.
The flow would be simple:
/login
endpoint that will check credentials and return the token, valid for a defined period of time (maybe 7d?)/refresh
endpoint that will receive the JWT token and will refresh it's duration for another parametrized (with limits) period of time.This will delegate to the backend the session generation but will let the clients how to use and work with it, where to refresh or where to ask for a login prompt again.
The only missing piece for backwards compatibility would be session invalidation. Using JWTs that is not possible, but at the moment I don't think that's required for Shiori (since it's not even multi user), but if we wanted to implement it we could easily store an ID set in the JWT payload and we could check for it in the database, caching it in memory for an hour or so. That way even if we invalidated a session the most time that session would be alive will be for an hour in a worst-case scenario.
The text was updated successfully, but these errors were encountered: