[GH-ISSUE #439] Improvements to session management #273

New issue

Closed

opened 2026-02-25 23:33:50 +03:00 by kerem · 0 comments

kerem commented

2026-02-25 23:33:50 +03:00

Owner

Originally created by @fmartingr on GitHub (Jun 23, 2022).
Original GitHub issue: https://github.com/go-shiori/shiori/issues/439

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:

A /login endpoint that will check credentials and return the token, valid for a defined period of time (maybe 7d?)
A /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.

Originally created by @fmartingr on GitHub (Jun 23, 2022). Original GitHub issue: https://github.com/go-shiori/shiori/issues/439 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: - A `/login` endpoint that will check credentials and return the token, valid for a defined period of time (maybe 7d?) - A `/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.