Automatically refresh page when backend session ends

@Snapey Yes but the system needs to have short session, was 5 minutes for example (so it's monetary related system that's why it needs to be very short).

Now if a user gets up from his PC for some break, like 20 minutes, then he comes back and the page looks the same - the user will just keep working on the page.

I prefer that it will refresh the page after a long break.

Regarding refresh tag - what if a user works on a few windows in parallel? The page will refresh when the refresh value reaches but I don't want that because the user might still be active on other pages

@Ligonsker so what you want is a longer session with a screen lock so that they have to enter their password to unlock?

@Snapey That could be a good idea. So basically instead of 5 minutes, let's say I extend the actual session lifetime to 20 minutes. Then a timer on the frontend will lock the screen after 5 minutes and will prompt a modal or some other popup to enter username and password right?

But how do I validate that in the backend if the user is still actually logged in? In case someone bypass the frontend lock

@Ligonsker create an endpoint that will tell you

@Snapey I was thinking about another issue - worst case scenario, unlikely but I just want to understand things better - A user gets up for more than 5 minutes, then a malicious user that happens to know some JS passes by that worker's PC and removes that frontend lock and then uses his PC

@martinbean I was thinking that, instead of having a longer session, then just have the session set for the time I want (5 minutes for example), then lock the screen after the session ends, then log the user - but is it possible? i.e. if I log the user after the original session ends, and now he has a new session - then if the user submits some form for example - will he get an error (like 419 or something), or it will work?

I just thought that, even if the session is over and you re-log the user with a new session without refreshing the page it can still work (but maybe the CSRF also changes? Or some other PHP related error that will happen when the session changes)

@Ligonsker You would need to save any form state and then after login (again) reload the page and restore state

@Snapey I need to reload because the CSRF changes? That's why?

@Ligonsker and the session cookie

Is it something I can update myself? I.e. to get the csrf and session cookies as a response from the ajax call and set their values so that I don't have to refresh the page?

Also regarding the other solution of creating a longer session with screen lock - how would you try to protect it against someone who bypass the screen lock? What I was thinking about was to save in the cache the last time the idle lock was triggered and the last time credentials were entered and compare if the time matches.

But is there a solution that doesn't require cache(or db?)

@Ligonsker most financial / medical organisations would lock the device not the browser session.

@Snapey I will have to rethink the entire thing then, thank you!

@SteveCove nice. And how do you sync between many opened windows/tabs? Because if for example a user opens a tab 5 minutes after the first one, then the session starts over, so the timer on the other window needs to sync. Do you use some value in a session storage and before you launch the modal you check against it?

@Ligonsker I believe we did encounter this issue, and solved it in a fairly basic manner with local storage - essentially setting a timestamp value on the the initial page load, and checking it on timeout. So if a new tab has been active (had a page load) since the current one, the local storage timestamp will be less than 9 minutes ago. At this point a new timeout can be started for 9 x 60 x 1000-(current timestamp - local storage time stamp).

This was some time ago, so I can't remember the exact details. If I was working on something similar now I would probably add a check for Document.visibilityState somewhere