You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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: