You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Install Mattermost-Desktop via the deb package from the release page
Update the mime-types using xdg-mime default mattermost-desktop.desktop x-scheme-handler/mattermost
SSO with Gitlab in Mattermost
Expected behavior
I can log in directly in Mattermost via the as it could be done with the client (< 5.6.0) and the server (< 9.0.0) or get the painful way through the browser working and being logged in afterwards.
Observed behavior
Two cases appear:
If firefox is already open, and I click on the SSO button in the app, a message from firefox appears, that it is already running and nothing more mattermost related happens.
So after closing firefox, I ran into the second scenario:
The mattermost desktop app opens the login page in firefox and after the login it asks to open the mattermost link in an external application. This results in an error on the command line :
which indicates that apparmor blocks the execution of mattermost-desktop from firefox for security reasons.
After disabling apparmor, at least the second scenario works.
Log Output
Error was shown in syslog as described in the observed behavior.
Additional Information
I would like to have the possibility to switch back to the old behavior, without going through the browser. We also have system wide installations via network shares, where we are not able to register the mime type on the systems and how to do this is out of scope for many of our users. So log in directly from the app is a must.
The text was updated successfully, but these errors were encountered:
@grisuthedragon Unfortunately this isn't something we can likely support going forward, as there are many security concerns that have been alleviated from moving away from external authentication in the app, and we plan to remove the functionality entirely for all server versions in the near future.
We do provide a script that should set up the mime type for most users under scripts/create_desktop_file.sh, which I would advise users to run if they're having trouble with the deep linking. Unfortunately if there is an application blocking deep linking altogether from the browser, then I'm afraid we can't support it otherwise.
It's a default firefox installation, nothing special hardened (in this case I could understand that there will be no support), so I would expect, that at least when installing it from the deb package it works. The security issue is something I do not really see, since after authenticating in the browser, that session token is passed as an argument via the process table, where it could be easily accessed by foreigners, thus keeping it in the application seems to be safer in my point of view.
As a first step, although I would not be fully happy with it, would be to ensure that the packages provided here, work with security techniques installed by default in Linux Desktops, like apparmor. At least place some easily visible information in the documentation.
Checks before filing an issue
Mattermost Desktop Version
5.6.0
Operating System
Ubuntu Linux 22.04 LTS x64
Mattermost Server Version
9.4.1
Steps to reproduce
xdg-mime default mattermost-desktop.desktop x-scheme-handler/mattermost
Expected behavior
I can log in directly in Mattermost via the as it could be done with the client (< 5.6.0) and the server (< 9.0.0) or get the painful way through the browser working and being logged in afterwards.
Observed behavior
Two cases appear:
So after closing firefox, I ran into the second scenario:
mattermost
link in an external application. This results in an error on the command line :and an error message in the syslog
which indicates that apparmor blocks the execution of mattermost-desktop from firefox for security reasons.
After disabling apparmor, at least the second scenario works.
Log Output
Additional Information
I would like to have the possibility to switch back to the old behavior, without going through the browser. We also have system wide installations via network shares, where we are not able to register the mime type on the systems and how to do this is out of scope for many of our users. So log in directly from the app is a must.
The text was updated successfully, but these errors were encountered: