In our Perspective application we are experiencing some issues with loss of recently input data to custom session properties.
The user inputs some data to different input fields in the app, which is stored in custom session properties until the user saves the data to a database (after saving to database, the custom session properties are cleared).
If the user inputs some data and use his/her mobile phone for something else for a couple of minutes, the custom session properties are still maintained when reopening the application.
But if the amount of time not using the application (before reopening the app) exceeds around 30 minutes, it seems that all the recently input data is cleared out.
The “Session Inactivity Timeout” on the identity provider is set to 1440 minutes, and “Session Timeout” for mobile and desktop in the project properties is set to 36000 seconds (max).
Does anyone have an idea why we keep losing our data after about 30 minutes?
Found a “webdefault.xml” file in the “webserver” folder with a 30 minutes session timeout configured, but according to support that should only be responsible for timeouts on the Gateways webserver (before automatically logging out of the gateway homepage).
Session inactivity is how long an open session can remain inactive before the Gateway terminates it. This does not apply to applications running in the background of mobile devices, because each operating system has different rules about how long applications can retain their state in the background.
So if your session is open on the device and is untouched, it will remain open until either you close it, one hour elapses, or the device itself goes into some sort of sleep mode, or the device loses power. If you open another application, I would be surprised if your session remained “alive” longer than 60 seconds, because I’m pretty sure the session ceases communication while in the background, and would therefore be at least temporarily orphaned and prone to a sort of pruning or clean-up run by the Gateway after 60 seconds of no communication. You could verify this by recording your session id and placing the app into the background mode, then waiting some time and checking against the session id in use after bringing the app back into action.
Did some testing with the session id as you mentioned.
Launched the application, entered some text into a couple of custom session properties, and took a screenshot of the session ID.
Went on using other apps on the mobile device (iOS, perspective app in background mode) and waited 5 minutes before I reopened the Perspective Application. Still had the same session ID, and still had the entered values in the custom session properties.
Performed the same “test” as above, only waiting for 20 minutes. Still had the same session ID, and still had the entered values in the custom session properties.
Performed the same “test” as above, only waiting for 35 minutes. Got a new session ID, and the custom session properties went back to their default value (empty).
Surprised?
The operators using the application is scanning some nfc tags, and the info from the nfc tags is written to different custom session properties before saving to the database. If they reopen the application after an hour, they need to fill in the different fields again. Guess it might have been better to fill in the different fields in the application from a “temp” database table based on the users last input instead of relying on custom session properties, or something like that…
Any suggestions on how to avoid the users needing to enter their recent input data again?
Anyways, there seems to be a limit of 30 minutes somewhere that causes the session to end. Just trying to figure out where that limit is configured.
I see that the netscaler they have set up for logging into the application might have a default session timeout of 30 minutes. I have asked them to increase this limit to see if this actually is the cause.
I hadn’t considered IdP timeout constraints. Are you using the default Identity Provider? If so, it terminates idle sessions after 30 minutes by default.
Yes, we are using the default Identity Provider (named default). But we have changed the “Session Inactivity Timeout” from the default setting of 30 minutes to 1440 minutes (24 hours, see the figure below). Should be okey?
Or is the setting for the IdP named “default” static at 30 minutes no matter what we adjust this setting to?
Maybe it would be better to create a new custom IdP (fresh start…) for use in our project, and not use the “default” one, even if we have changed the timeout setting. Worth a try at least
Ah, I forgot you covered that in the initial post. That setting looks correct to me. It might be time to contact Support because we’ve covered all of the usual suspects for something like this on our end.
I have an ongoing ticket with Support, but they have not answered my last reply in a week, so in the meantime I thought I could check with the O’mighty forum
Kinda weird there is nothing buildin to store things in the browsers localStorage.
I build a component for it and its like super simple xd
Idk if it would work for the app though, i guess if it doesnt it would make sense it doesnt exist.
Just a follow-up on this case, and if anyone else is struggling with the same issue:
The support team managed to replicate this issue, and said it is a bug. When they verify the bug, they would update this forum thread with a ticket number ( 1 month ago… still nothing has happened… ).
Anyways, even if support said this has nothing to do with this issue, I adjusted the session timeout setting found in the previously mentioned “webdefault.xml” file in the “webserver” folder from 30 minutes to a couple of hours, and the issue of losing our session custom properties seems to be solved
