We've been dealing with a few different issues recently in the realm of users getting signed out of applications. While looking into it, it gets confusing depending on how the environment is setup. I found several places where timeouts take place within the LF applications: Mobile, Forms, Repository, and STS. If all of the products (including STS) has timeouts configured, how do those affect each other? The two recent issues we have come across are with Mobile.
Question
Question
So Many Timeouts, What is the Order of Precedence?
Answer
Hi Blake - please allow me to comment on the Mobile App since that were your two recent cases. Mobile app timeout is determined by the timeout parameter configured on the Mobile Service Configuration page, measuring the length of inactivity that happens on the end-user side. Even if the system, e.g. Repository etc., issues a timeout, the mobile app has the mechanism to reconnect at the backend as long as mobile timeout is yet to hit. If this is not what you are observing and able to produce a different behavior consistently, please open a support case so that we can investigate further. Thank you!
Hui
Thank you Hui. How does that work with LFDS with an STS is in play? Does that STS timeout setting have any effect?
Hi Blake, in the case of mobile app, LFDS STS is called upon only for building the initial connection. After that, the mobile app becomes independent from the STS (LFDS) logic.
Thanks,
Hui
Hello Hui,
Thank You for the response. To be clear, in the scenario where a client has mobile with the STS and they go to another APP on the phone, then they go back to the mobile app it will require them to authenticate. There is not anything that LF can do to control that?
Regards,
Hi Drew - the intended behavior is that if the user goes off and then back on the LF App, the App should be able to automatically sign the user back in without asking for authentication again, UNLESS the "Remember Me" function is turned off via the Mobile Server Configuration > Connection page. If that's not what you are experiencing, please open a support case so that we can dig deeper for you.
Thank you,
Hui
Thanks, I will open a case!
Hello Hui,
If the "Remember Me" function is not turned off is there anything else that needs to be done for this to work properly. We do not see any option when logging in to select "remember me".
Regards,
Hi Drew, can you please clarify what you refer to by "this" (in "for this to work properly"), because there have been two topics being touched upon in this thread, one is the session timeout, and the other is "remember me". "Remember me" functions within the "timeout" framework. thanks,
Hui,
I'll add to the thread since we are the client for Drew, 'This' is the 'Remember me' function. In Mobile Server Configuration under Authentication we have "Disable 'Remember Me'" unchecked which would imply that 'Remember Me' would be active. The odd thing is that when we are logging in to Mobile via the app there is no 'Remember Me' function that we can see.
Ultimately what we are trying to resolve is our users having to reauthenticate over and over in the Mobile app every time they fire it up.
Thanks for your input.
Hi Collins,
You spot on, currently the "Remember Me" activation control is through the server configuration page for all your users. It's a centralized control, and you users won't be able to change it for themselves.
As mentioned in my previous comment, "Remember Me" takes effect within the Timeout settings. For example, if the timeout is set at 5 minutes, your users can go off and come back to the app within these 5 minutes without repeated sign-ins. But if the user comes back after 6 minutes, the login credential will expire and he/she will be required to enter user name and password again as a security measure. You may want to check your timeout setting on the mobile server configuration page.
One way to bypass it is to use biometrics, which has been enabled for non-LFDS sign-ins. We continue working with LFDS on enabling biometrics on their framework. No ETA yet, but we are on it.
Thank you!
Hello Hui,
Is there a maximum timeout that Mobile supports? For instance, would 240 minutes be something Mobile would support with this feature?
Regards,
To try and gather a little more detail on this today I tried an experiment.
At about 10:15 I logged in and then locked my phone. then i set a timer for 40 minutes to see how long it would be before i would have to authenticate again. After 40 minutes I reopened the phone, opened Laserfiche, and was able to go right back into the repository. At this time I relocked my phone and set another timer for 40 minutes. That timer completed, I opened the phone and selected the Laserfiche icon, the app tried to load and then crashed. I tried to open it again and it kicked me back to the login screen. Our system is set to 240 minutes for its timeout window.
Any thoughts on how to correct this?
Hi Drew,
Currently all customer accounts on Laserfiche Cloud are applied with the default 20 minute timeout setting for the mobile App usage. For on-premise (or self-hosted) Laserfiche systems, the mobile App timeout can be customized through the Mobile Server configuration page. We would like to hear from you if there are use cases you know of that will make the capability of customizing timeout in Cloud a higher priority item among other requests to the App.
Much appreciated!
Hui
Hi Collins,
Is your system on Laserfiche cloud or on-premise (self-hosted)? If self-hosted, the timeout limit can be configured through the Mobile Configuration page: https://www.laserfiche.com/support/webhelp/laserfichemobile/10/en-us/lfmobile/lfmobileadmin.htm#Installation_and_Configuration/Configuration_Page_Security.htm%3FTocPath%3DConfiguration%2520Page%7C_____2
thanks,
Hui
We are an on premises installation and we are set for 240 minutes timeout limit which is not what we are experiencing.
Hi Collins,
I'm not sure if i fully understand the context. If you are experiencing unexpected timeout, can you please open a Support ticket? There are more impacting factors involved on timeout for On-Prem installations, e.g. the server version, etc. a Support ticket will help investigate further.
thank you!
Hui
Replies
Seeing if someone from Laserfiche could chime in on this one?
On a related note, I know that for Laserfiche Cloud there is no timeout on the iPhone mobile app. After signing in once, users stay signed in indefinitely. Currently, there is no way of enabling a timeout. We have confirmed with support that this is the expected behavior and there is a feature request (209888) for the ability to configure timeout/mobile app sign-in settings for Cloud customers.
Hi Henry - we are looking into this and will update soon.
Hi Henry, the feature request is to support bespoke timeout settings for each customer account, which we are yet to have an ETA. In the mean time, we are actively working on making sure the default timeout functions as expected for all Cloud customers. this is currently being tested and investigated. Thank you!
@████████Thanks Hui! What does the default timeout functioning as expected look like for the mobile app? I assume it is not no timeout (how the app currently functions), but is it 30 minutes, one hour, four hours, etc?
Happy Holidays!
Hi Henry, that's exactly correct. We expect a timeout being enforced across the board for all Cloud customers, e.g. 20 minutes or similar. Once we are done with investigation, will confirm back the detail together with an ETA. Thank you!
A quick update, the default Mobile App timeout (20min) should be enforced for all cloud accounts by Jan 24. Thanks for your feedback!
@████████Thanks Hui!
@████████Just to update you, the timeout is still not being enforced for cloud accounts on the iPhone app.
Hi Henry, could you please double confirm the app version you use, just in case that app auto-update is not turned off? Thank you!
Hui
@████████Version 2020.1.17.234541
@████████Looks like I spoke too soon. I manually signed out and signed back into the app. The timeout seems to now be enforced in the app. This is great, thank you. One interesting note is that quitting/restarting the app does not force the user to re-sign in, it remembers the session from last time as long as the prior session is still active.
Awesome, thanks for the update!
Just wanted to provide an update to everyone here. The fix back in January only enforced the timeout from about 20 minutes after the user stops using the app to about one hour after the user stops using the app. We alerted dev to this shortly after the update in January, however the security bug has now been sitting with dev for 10 months without a fix. If a user opens the Laserfiche app attached to a cloud account at any time more than an hour after the app was last used, the user is able to access all the documents in our repository without the need to authenticate.
Can we also get information about the behavior of the other Laserfiche applications and how they work with regards to using and not using an STS and timeouts?
Your STS timeout doesn't really affect web client at all. You need to have an active LFDS session when you authenticate via SSO, and that's it. It doesn't matter if your STS token expires while you are using web client, it was just used to authenticate you at the beginning.
So what does the timeout setting do when set on an STS?
It's how long your session is good for in the STS. If an application redirects you to the STS for authentication, if you have an active session it can use that, otherwise it will prompt you for credentials.
That makes so much more sense now. Thank you.
Something worth noting is a final client side maximum timeout that can not be overridden by the server. You can not go beyond about 6 hours. If you try setting 100,000 minutes or 0 minutes, you will get about 6 hours before the app itself times you out.
Any new features to extend the timeout? Everyone wants to extend the timeout at least until biometrics is available, which would prevent users from entering their passwords on a mobile device and prevent the error messages they are getting when they have not opened the app for awhile.