Browser refresh

[nhofkes]

This is a question about the consequences of a browser refresh - in most browsers this is done by pressing F5 and/or Ctrl-R, sometimes also referred to as 'Reload'.

I noticed from the log files (Tomcat log and testing log) that the browser refresh results in fully new login request. It seems that the only difference is that the user does not need to supply username and password, but otherwise the refresh results in a new session and the app going through any login process and displaying the start screen for the user. I wonder whether that is intended behaviour and/or unavoidable for some technical reason.

Consequently, the browser refresh is not a good method to refresh any information on the screen. I know that there shouldn't be any need to do a browser refresh because you can put a refresh button on just about any form or query, and in most cases they will even auto-refresh. But still, it would seem more customer friendly if a browser refresh would return the user to the same screen that he was in when doing the refresh. Has anyone taken the effort of recording each page that the user visits for the purpose of returning him to that same place after the refresh ? Or would that not be a good idea because of any side effects of the browser refresh, i.e. should this refresh be discouraged so that the user will use the app's refresh button instead?

[hpl123]

This is a question about the consequences of a browser refresh - in most browsers this is done by pressing F5 and/or Ctrl-R, sometimes also referred to as 'Reload'.

I noticed from the log files (Tomcat log and testing log) that the browser refresh results in fully new login request. It seems that the only difference is that the user does not need to supply username and password, but otherwise the refresh results in a new session and the app going through any login process and displaying the start screen for the user. I wonder whether that is intended behaviour and/or unavoidable for some technical reason.

Consequently, the browser refresh is not a good method to refresh any information on the screen. I know that there shouldn't be any need to do a browser refresh because you can put a refresh button on just about any form or query, and in most cases they will even auto-refresh. But still, it would seem more customer friendly if a browser refresh would return the user to the same screen that he was in when doing the refresh. Has anyone taken the effort of recording each page that the user visits for the purpose of returning him to that same place after the refresh ? Or would that not be a good idea because of any side effects of the browser refresh, i.e. should this refresh be discouraged so that the user will use the app's refresh button instead?

The reason for this as far as I know is because the user is already logged in and the current session is "alive" when the user refresh the browser i.e the users credentials are "stored" in some way in the browser or tomcat so when the browser refresh, it does something equivalent to what we can do when log in in via a URL with the user information etc. in the URL i e it kind of logs the user in again.

I have worked around this in a couple of different ways, I have done what you ask about i.e "record" the users last vp/layout and when the browser is refreshed, a initialization process takes them back to the same page. I actually used a temporary vp as the login vp to do this and that vp was empty and only had a single process to navigate the user to some other vp/layout (as otherwise, the app would first show the default start vp/layout and then redirect the user to the last vp/layout). Not the best solution but works. Other things you can do include using the localstorage of the browser instead and use that as a placeholder for information, scripts etc. related to last vp/layout. You also have different JS functions and workarounds you can use to manipulate things around browser refresh e.g "catch" browser refresh event and override it or do something else instead of browser refresh e.g show a popup with options for the user (go to homepage, go to last visited screen, cancel refresh etc. etc. etc.).

[gernotlg]

I know this is not what your post is addressing, however, I wonder.. if there is a security risk here (while we're on the subject of Browser Refresh). I have noticed that when I leave a session idle for a while, then go to use it, it tells you the session has timed out, and I get logged out, like it is supposed to.

But !!!.. I've learned that, if I suspect it's been too long, instead of being logged out, I will just press F5 to refresh the browser and it logs me back in without asking for a password.

I think there is a risk here, if users know this, and someone else's session is logged in, times out (but hasn't gone back to the log-in page), then the user in the know.. could re-log in as the currently/previously logged in user (in a shared office space for eg), and potentially do or see stuff that their own access level doesn't allow.

Of course, this is overcome with 2FA, but then it would have to be enforced which isn't necessarily ideal for all situations.

[nhofkes]

I would assume that if a session is timed out, then the user is actually logged out already at that time? So presumably the fact that you were logged in after pressing F5 suggests that the session had not yet timed out even though you suspected that it might have been too long.

In any event, it seems that the security risk is not so much with the refresh of the session, it is with the user who leaves the computer unattended and without logging out of the application.