Auto-Logout if session has expired #470

Closed
opened 2026-02-04 19:46:56 +03:00 by OVERLORD · 3 comments
Owner

Originally created by @christophenne on GitHub (Apr 8, 2024).

I noticed that when the session/token expires during the UI is open in the browser, the user is not logged out immediately and the websocket authentication doesn't seem to be affected by the expiry. I did not use SSO/Keycloak in this scenario, this is the default installation with a 7 day long session.

As a consequence, as long as the tab with planka stays open, the user can still write and read data even if they are not authenticated anymore and need to login again. Only after the next full page refresh they are logged out.

I think the websocket needs to be closed and the UI should redirect to the login. Alternatively and probably easier to implement, at least at the next read/write request the user could be redirect (as quite a lot web application handle it that way too), but the currently opened page would still be exposed.

Originally created by @christophenne on GitHub (Apr 8, 2024). I noticed that when the session/token expires during the UI is open in the browser, the user is not logged out immediately and the websocket authentication doesn't seem to be affected by the expiry. I did not use SSO/Keycloak in this scenario, this is the default installation with a 7 day long session. As a consequence, as long as the tab with planka stays open, the user can still write and read data even if they are not authenticated anymore and need to login again. Only after the next full page refresh they are logged out. I think the websocket needs to be closed and the UI should redirect to the login. Alternatively and probably easier to implement, at least at the next read/write request the user could be redirect (as quite a lot web application handle it that way too), but the currently opened page would still be exposed.
OVERLORD added the bug label 2026-02-04 19:46:56 +03:00
Author
Owner

@meltyshev commented on GitHub (Apr 8, 2024):

Hi! Thanks for noticing that.

We do a redirect to Login when any request is made to the server and it realizes that the token is no longer valid. But since we cache all data to make the interface fast, it's very hard to make a request to the server with an already loaded board (unless you change something on it). But I totally agree that this should be fixed somehow.

Also in that case it's likely that a user is still getting socket updates as well, which is too bad. Then it should probably be done by a service that constantly checks the user tokens of currently connected sockets and sends a disconnect event if they have expired.

@meltyshev commented on GitHub (Apr 8, 2024): Hi! Thanks for noticing that. We do a redirect to Login when any request is made to the server and it realizes that the token is no longer valid. But since we cache all data to make the interface fast, it's very hard to make a request to the server with an already loaded board (unless you change something on it). But I totally agree that this should be fixed somehow. Also in that case it's likely that a user is still getting socket updates as well, which is too bad. Then it should probably be done by a service that constantly checks the user tokens of currently connected sockets and sends a disconnect event if they have expired.
Author
Owner

@christophenne commented on GitHub (Apr 8, 2024):

I'm not familiar with the auth module in this project, but shouldn't it be possible to read the auth token (which I guess is a JWT?) and its expiry timestamp? So the destroyal of the cache, socket and the redirect could be done exclusively by the client. I have seen this kind of auto logout in other projects before, but it's just a wild guess.

@christophenne commented on GitHub (Apr 8, 2024): I'm not familiar with the auth module in this project, but shouldn't it be possible to read the auth token (which I guess is a JWT?) and its expiry timestamp? So the destroyal of the cache, socket and the redirect could be done exclusively by the client. I have seen this kind of auto logout in other projects before, but it's just a wild guess.
Author
Owner

@meltyshev commented on GitHub (Apr 8, 2024):

I'm not familiar with the auth module in this project, but shouldn't it be possible to read the auth token (which I guess is a JWT?) and its expiry timestamp? So the destroyal of the cache, socket and the redirect could be done exclusively by the client. I have seen this kind of auto logout in other projects before, but it's just a wild guess.

Yes, it can be done on the client and it's even easier, but it won't fix the fact that a user can modify the client and always listen for new updates even if his/her session has ended (seems not very secure). I think I even have an idea how this could be implemented on the server, just need to try it.

@meltyshev commented on GitHub (Apr 8, 2024): > I'm not familiar with the auth module in this project, but shouldn't it be possible to read the auth token (which I guess is a JWT?) and its expiry timestamp? So the destroyal of the cache, socket and the redirect could be done exclusively by the client. I have seen this kind of auto logout in other projects before, but it's just a wild guess. Yes, it can be done on the client and it's even easier, but it won't fix the fact that a user can modify the client and always listen for new updates even if his/her session has ended (seems not very secure). I think I even have an idea how this could be implemented on the server, just need to try it.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/planka#470