Skip to Content (Press Enter)
2023-04-12 14-26-51
David Bednarski
79Views
2Comments
[Session Timeout Alert] A few ideas to consider
Question
Reactive
Forge
end-session-message
Reactive icon
Session Timeout Alert (O11)
Forge asset by Breno Nico
Application Type
Reactive

Wow, I couldn't believe when I saw this posted because I literally just created an almost identical component!

My component used the Performance API to check for new XHR calls and track when the user's time would expire.  I like your approach of overriding XMLHttpRequest better since it is more intuitive and I imagine it might have better support across browsers.

There were a couple of things I was thinking might be good to add, at least things that I felt would be useful to account for in my version:

  • It could be possible that a user's page is making XHR calls to external sites, which wouldn't affect the user's idle time.  So you might want to filter to only count requests made to your application's domain.
  • I also took that one step further and filtered down only to requests made to the /screenservices/ path, since that would then cover aggregates, data actions, server/service actions -- which all would reset their idle time.  My thought was there could be some edge cases where their page might call directly an OutSystems exposed REST API that they created, which would be not affect their session.

Overall I think this is a great easy solution to a common problem that is otherwise tricky to solve!

1
0
30 May 2024
Copy Link
2020-09-16 00-41-02
Breno Nico

Hello David Bednarski ,

Thanks for your feedback. You are right! It's need to filter only XHR requests made to the /screenservices/ paths. This ensures that only requests for aggregations, server actions, and any other calls to the OutSystems server are covered. And assuming this is enough to keep the session active, by filtering this we exclude any other unnecessary XHR requests, for example GTM (Google Tag Manager), Google reCaptcha, APMs Agents and other plugins that do XHR events directly to their hosts.

As soon as possible I will fix it in the next version.

Thank you very much,

1
0
06 Jun 2024
Copy Link
2020-09-16 00-41-02
Breno Nico

Hi David,

Thank you for your kind words and for sharing your experience with a similar component! It’s great to hear that you found the approach of overriding XMLHttpRequest useful and more intuitive for handling session idle time.

As I promised a few weeks ago, I’ve now implemented the correction by including a filter that specifically focuses on requests made to the /screenservices/ path. This ensures that only relevant XHR calls (such as aggregates, data actions, and server/service actions) trigger the session reset. External API calls won’t affect the session timer anymore, which should handle the scenario you mentioned where REST APIs exposed by OutSystems might not need to reset the session.

Thank you again for the valuable feedback! Let me know if you have any further thoughts or suggestions.

Breno Nico

0
0
17 Sep 2024
Copy Link
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.