I’ve seen it happening with myself and some of my users. We suddenly get a notification from iOS telling the login token has expired and we need to login again.
Opening mattermost client displays the login page.
This is a big burden since we stop getting messages until we relog.
Most users login once and they expect the app to just work. besides they always forget their passwords. : P
I’m not sure why this happens but I don’t think it should.
Is this a security feature? Is it possible to turn it off?
It’s dificult to say. My guess is it expires 30 from last time the user actually loged in (type user and password). It could be the case based on the console session settings.
I dont think I fully understand the console sessions settings but from my point of view the users should never be prompted to relog. it is impractical. Only time it’s necessary is when the account password is modified.
That is indeed the intended behaviour as defined by those system console settings. By default, we want mobile sessions to expire in case the user loses their phone and someone else picks it up so that the amount of access that the other person has is limited.
You can increase the length of a mobile session if you’d like, and it’ll take effect after the next time that the users are made to log in again. I don’t think it’s possible to disable it entirely, but you could set it to a long time like a year.
This is a very bad decision. Imagine if skype forced all the users to relog every month.
I suggest to implement a feature to disable session expiration and make it as default settings.
I agree that it’s somewhat less convenient for end users when they get logged out monthly, but we chose to sacrifice some usability for a more security-concious solution here. As mentioned before though, you can set the session length to make it incredibly long so that session expiration virtually never happens.
@hmhealey It doesn’t just make them re-login, it’ll often ask for the server URL and the username again. I understand re-entering a password, but zero of our regular users remember the URL. What’s worse is the app (on both iOS and Android) silently loses the connection: the login expires, people stop receiving notifications on their phones, and the app doesn’t notify the user to log in again. You can’t even plan to work around the issue as using the app is not enough to keep the session alive, it will always drop the login. Setting the the timeout to a year is only half the solution, people will still suddenly be logged out without being told, and will be even less likely to remember their passwords after so long.
Also, from a security perspective, session expiry is to invalidate existing sessions that may have been compromised. These are absolute timeouts, not renewal timeouts. Increasing them is a balance between security and usability.
Regarding the session expiry, we’ve been looking at improving that recently. We’re mostly talking about increasing the default session length (while adding some additional measures to mitigate against compromised sessions), but there has been some discussion about if and how we could safely eliminate the max length of mobile sessions entirely. Nothing to report on that front yet, but we’re aware that it’s not a great experience
@amy.blais I think they’re just regular timeouts. The main issue is one doesn’t know when they’re no longer logged in. Can’t the app ping the server periodically to see if it’s been disconnected?
To have the session expire feature, you really need the app to tell the user, probably by notification, that the app login expired, requesting the user to open the app and relog.
@Roy-Orbison We fixed an issue in v1.13 on session expiry notifications not being sent on mobile devices: https://mattermost.atlassian.net/browse/MM-12236. We also added support in server v5.4 for notifying users when desktop/browser sessions expire. However, as hmhealey said above, we do have other tickets we’re working on to improve the session expiry behaviour.