Desktop app on macOS logs out every few weeks

[mmalina]

I confirm (by marking "x" in the [ ] below: [x]):

• [x] This is not a troubleshooting question. Troubleshooting questions go here: http://www.mattermost.org/troubleshoot/.
• [x] This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
• [ ] I have read contributing guidelines.

---

Summary Desktop app on macOS logs out every few weeks

Steps to reproduce

Log in with your desktop app on macOS. Keep logged in. Eventually the app will log you out.

Expected behavior

Once I log in in the desktop app, I stay logged in indefinitely.

Observed behavior

Every once in a while the desktop app logs me out. This is especially annoying since I cannot have keychain will in the password for me - that doesn't work in apps. Every time the app logs me out, I have to go to keychain to search for my password. No other desktop app does this that I'm aware of. Skype doesn't do it, Adium doesn't do it..

Possible fixes

Perhaps integrate support for keychain in the app.

Environment

macOS 10.13.4 High Sierra Mattermost desktop client Version 3.7.0 (3.7.0.3.7.0) Mattermost Version: 4.9.0 Database Schema Version: 4.9.0 Database: postgres

Originally report here: https://github.com/mattermost/mattermost-server/issues/8831

[jasonblais]

Thanks @mmalina!

Your System Administrator configures how long your session is active before it automatically expires. Would you be able to ask what those settings are currently set to? https://docs.mattermost.com/administration/config-settings.html#sessions

[mmalina]

Thanks for the response, @jasonblais , I forwarded the request to our admins. In the meantime, which of the properties would be responsible for the desktop app? SessionLengthWebInDays or SessionLengthMobileInDays ? And how would one achieve for the session to never expire? And also, even if we can achieve that, is that the right thing to do? My idea is that the desktop client should be able to store the credentials in some form locally so it can authenticate against the server if needed.

[jasonblais]

@mmalina We should probably update the documentation to clarify this. I agree it's not obvious which one would affect the Desktop App.

SessionLengthWebInDays would be relevant here, unless you use a single-sign on service such as GitLab or SAML in which case it would be SessionLengthSSOInDays.

To never have the session expire, you could set it to a large number such as 9999. That being said, we usually recommend setting a reasonable session length as it acts as an additional safeguard and required by many companies - had someone got access to your session/account, that would automatically expire after a given amount of time. It is similar to your session on your bank account expiring after a fixed period of time (of course with a much shorter session limit than in Mattermost).

[daydr3am3r]

Hi,

Mattermost user and admin here. I have similar behavior in two separate mattermost installations (5.0.1 and 4.9): The desktop client (at least in MacOS, version 4.1.2) keeps logging out the user or putting it differently, it seems to be creating new sessions instead of reusing existing ones: .

Sessions have all been set to 365 days on the server side. Before that, they were set to 180 days. If I use my browser to log in, session is being reused.

Practically this means that anytime our users open the mattermost client, they need to log in again. Please advise!

[jasonblais]

@daydr3am3r What is the first activity date on the above three sessions?

[daydr3am3r]

@jasonblais it's the same day as the session creation date. To reproduce I:

1. Logged out from all sessions, and cleared all active session information
2. Logged in via the desktop client, and a web browser
3. Exited the desktop client and closed the web browser window

Result:

• Desktop client asks for re-authentication (for both mattermost servers, v5.0.1 and 4.9)
• Browser window remains logged in

[jasonblais]

Thank you! Very helpful. @yuya-oc any thoughts on the above?

[mmalina]

I still think that the right solution would be to add support for password storage in the desktop app. That way the app would be able to log you back in any time the session expires.

[josh-torrey]

Hello,

I am also a MM user/admin (Version 4.9.1), and am experiencing "random" logouts from the desktop AND mobile apps with a session duration set to 365 days. My users are reporting similar behavior, which has been causing a lot of issues with regards to missed messages/notifications (most of our users have disabled email notifications) when they assume that their session is active on the apps.

I have taken the steps provided by @daydr3am3r to reproduce the issue and can confirm the resulting behavior above for Mac, Windows, and iOS clients.

Also, I reviewed my Access history and found that around the time of the random logout (I think) that there are multiple "Logout" events all with the same IP and session ID:

Really hoping that there is a solution here; these random logouts are a BIG pain point for our users. Happy to provide more info on our setup if that is useful in troubleshooting the issue. I have created a thread on the Peer-to-Peer Forum as well: https://forum.mattermost.org/t/users-logged-out-of-mattermost-clients/5305

Thanks.

[amyblais]

Hey all, I created a ticket here for our QA's to investigate: https://mattermost.atlassian.net/browse/MM-11319.

[mlncn]

Confirming this same degraded experience (frequent logouts) on the desktop app for Linux (Debian and Ubuntu). I would expect apps to stay logged in much longer than web sessions, or at least have that as an option.

Having the app connect with a revokable API key rather than username/password (and so session) is a common pattern that could solve this.

[t-oster]

Hi, I am also experiencing this problem. Having the app saving username/password would be ok for me. If you don't want to save the password in cleartext in the config, providing a command-line-paramter to login would maybe be an option. Revokable API-Keys seems reasonable, but may be more work to implement.

[devinbinnie]

Closing as inactive/cannot reproduce.