Reactive web - Adding a custom session timeout/browser close event
Question
Application Type
Reactive

Our application is required to only allow one login per ID at any given time.   I have created a user extension table and am setting a flag upon login and clearing the flag on logout.   This is working as expected; but I am unsure how to handle situations where the user is idle and times out or when they simply close the browser without logging out of the app.

Has anyone worked with a scenario like this?  If so do you mind sharing your solution?

Hi Josh,

the requirement is not to have more then 1 login, but is it specified which of the logins gets precedence?  If not, you could turn it around and favor the last login.  Maybe set up something like this :

- at every login save a new unique GUID both as client variable and in your login tracking entity

- at every screen load or client action or server action or ???? check if the client variable is still the same as the value in the entity, if not, log your user out and give message that a later login session killed this earlier session

Above is a very basic variant without nuance, but you could make login logic/screen a bit more elaborate, telling user that there is still a lingering session and ask them if they are ok with killing that other session by going ahead with their current login.

Downside is that this approach only works with frequent checking if current session is still the valid one, so you'd have to find a good spot to do this (maybe just in every server call to avoid performance issues)

Dorine

I was actually working on this exact scenario last night.   I am going to present the solution to our product owner today and see if we can go this route.   I like it because this way I do not have to keep track of browser close/timeout/crash events.  I also think it is a better user experience.


yes agree,

as a developer, you don't have to worry about all the possible ways users could have ended their session.  As a user, even if at some point you ended a session in a wrong way, you can still always immediately log in and start working.

Dorine

Unfortunately these don't really provide a solution.  I am working with the onbeforeunload to capture browser close events, but it is also triggered if the user refreshes the current page and I would not want to clear the user logged in flag in that instance.

I also know that our sessions are set to to timeout after 30 minutes of inactivity but I do not see any system event that is triggered when that occurs, so again I am unable to clear the login flag.

Hi Josh, i hope you're well. 

I've never had this scenario, but I think that if, at each request in CS, the application calls a function to reset the counter, this will solve the idle user problem.

I think I've confused everyone.  I'm not necessarily worried about the idle users being timed out.   That is occurring properly.   I need a way to trigger a database event when that occurs so I can clear the user log-in flag so the next time the user logs in they do not get an error.

The same is true if the user closes their browser instead of selecting the log out option.

what error appears to the user?

Did you try to handle user screen error?

No error is displayed when the user session times out.   The next time they try to perform an action that requires a server call they are just routed to the login screen.  I assume this is default Outsystems timeout performance.

For users that close their browser; I haven't found a way to reliably capture that event.   I tried onbeforeunload but that also fires if the user refreshes the page, so I wouldn't want to clear the user's active session flag in that instance.

Hi Josh,

the requirement is not to have more then 1 login, but is it specified which of the logins gets precedence?  If not, you could turn it around and favor the last login.  Maybe set up something like this :

- at every login save a new unique GUID both as client variable and in your login tracking entity

- at every screen load or client action or server action or ???? check if the client variable is still the same as the value in the entity, if not, log your user out and give message that a later login session killed this earlier session

Above is a very basic variant without nuance, but you could make login logic/screen a bit more elaborate, telling user that there is still a lingering session and ask them if they are ok with killing that other session by going ahead with their current login.

Downside is that this approach only works with frequent checking if current session is still the valid one, so you'd have to find a good spot to do this (maybe just in every server call to avoid performance issues)

Dorine

I was actually working on this exact scenario last night.   I am going to present the solution to our product owner today and see if we can go this route.   I like it because this way I do not have to keep track of browser close/timeout/crash events.  I also think it is a better user experience.


yes agree,

as a developer, you don't have to worry about all the possible ways users could have ended their session.  As a user, even if at some point you ended a session in a wrong way, you can still always immediately log in and start working.

Dorine

Hi Josh,

Please check the solution I have attached here.

its working for me. check the javascript added in onReady event on LayoutTopMenu.

Please let me know if you face any challenges. I am considering the reactive web app for this example.

Hope it help.


Regards,

Shoeb


test.oml

This does work, and I was originally going down this path.  However I still had issues with when a user clicks refresh or the browser crashes.   I got permission from our team to accept the latest login vs the first so I will go that route.

Hi Josh,

we can't prevent beforeunload . A page refresh is like navigating away and unloading the DOM so the onbeforeunload event will always be called.


Regards,

Shoeb


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.