Unable to authenticate Desktop App through gitlab OAUTH2 Login since 9.1.x #2906
Comments
|
@wech71 Can you share which OS you are on? If it's Linux, can you share the distribution as well? |
|
Of course. It's a linux ubuntu 20.04.6 (focal) server. |
|
ah, sorry, did you ask for the desktop-os? Its Windows 11, but it also happens on several computers including a RDP Terminal Server Session on a windows server 2016. |
|
@wech71 Yes I meant the Desktop OS, all good :) So your users should see a prompt that has them open the Desktop App from their browser. Is that not happening? |
|
Yes, the protocol handler seems fine. When i click the mattermost:// link after logging in in the browser, the mattermost app reacts to the click, but I'm not logged in as expected and only see a white background (with a slight shadow of the mattermost-logo on it) and containing the gray text "subdomain.domain.tld/chat" ("chat" being the subpath). When I press Ctrl+R the mattermost login page (with the "gitlab" buttton) appears again.
|
Are you able to provide logs from the Dev Tools? You can go to View > Developer Tools for Current Server and something should show up there. Looks like something is happening when the navigation happens. |
=> login page is shown
Following the response text to first request |
|
@wech71 Okay so if you're seeing the "You are now logged in" piece that means that the deep link was successful. If possible can you check the result of the request to the You might need to turn on "Preserve log" to make it work. What we're looking for is if the cookies are being set via a |
|
@devinbinnie hm, I don't see any /login/desktop_token neither in mattermost desktop, nor the web browser where the gitlab authentication occurs. Did you mean /login/desktop with the client and server token request params? Both of them have "preserve log" and "disable cache" activated. After clicking "Authorize" in gitlab in the browser, I can see the following requests: @browser: https://subdomain.domain.com/chat/signup/gitlab/complete?code=15fxxxxxxxxxxxxxxxxxxxxxxxxxxxxx6d&state=eyJxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9 https://subdomain.domain.com/chat/login/desktop?client_token=a6cxxxxxxxxxxxxxxxxxxxxxxxxxxxxx07b54f&server_token=mgxxxxxxxxxxxxxxxxxxxxxxxxxxxxx15ih I set a breakpoint to forwardToDesktopApp and it sets window.location to This then triggers the desktop app where the following requests happen: @mattermost-desktop-app https://subdomain.domain.com/chat/api/v4/cloud/subscription/self-serve-status All three request use the following cookies in the requests: As far as I understand, the mattermost: protocol runs another instance of the mattermost.exe with the specified url, but as this would be a different instance of the mattermost.exe, so I was thinking that the cookies are being set in the wrong instance. So I tried to set window.location in the running mattermost desktop app developers console to the mattermost:-Link, but this also does not produce any requests at all in the network tab, but setting it to https://subdomain.domain.com/chat/ instead does, so it works. In fact setting it to anything 'https://subdomain.domain.com/chat/login[?/].*' does not trigger any reaction. All test where made with Mattermost Desktop App 5.4.0 on Windows Terminal Server 2016 |
|
Thanks for the detail :) So in the second instance case, we should be seeing something in the logs when it opens, see the function that does the second instance check here: This is what should be handling the deep linking. Weirdly though, it looks like something is opening that URL, but it's not your Desktop App. Have you tried using v5.5.1 Desktop App? |
|
How can I debug the second app (the one started through mattermost:-Protocol)? - it immediately exits after processing the mattermost:// link, and I have no time to open the developer tools an this second instance. And running mattermost.exe without parameter also just activates the first (already running) instance and exists immediately. I also just tried it wit the v5.5.1 app - unfortunately the problem persists. |
|
@wech71 So it seems like it's working as intended as the second instance is popping up and doing something. This is more than likely something on your server-side at this point, so I'm going to send this back over to the server repo to be investigated there. |
|
I am experiencing the same issue. I am running MM Enterprise 9.1.0. Desktop App version 5.5.1 on MacOS Sanoma 14.1 and Windows 10. This issue arose when I upgraded to MM 9.1.0 Edit: I should clarify that I am using OIDC Auth from a provider that is not GitLab. |
|
I noticed that when running MM Server version 9.1.0, I was directed to my computer's default browser for login, then the attempted redirect back to the Desktop App didn't work. When running MM Server version 9.0.0, the authentication workflow stays in the Desktop App - it loads up my auth provider's site within the Desktop App rather than opening a new tab in my web browser. |
|
@sei-jbooz: Just out of curiosity: Is your mattermost server instance also hostend on a subpath like mine or directly at the root level of the mattermost server? |
|
My Mattermost and OIDC Provider are both hosted in a subpath on the domain. |
|
Ah, so the subpath appears to be the culprit here. I can reproduce the issue on another subpath server. |
|
The official create_desktop_file.sh contained in the linux package creates a Mattermost.desktop file missing:
That should be fixed, no matter the root cause. |
|
Transferred back to desktop repo as it turns out there was an issue with the app misinterpreting deep links for subpaths. PR is up to fix :) |
|
I'm not sure if this is the same issue but I'm tagging onto it because I think it might be. I ran into a similar thing when trying to log in to a server via GitLab. Some specifics:
Logs: If this is a different issue, I can make a separate issue of it. Thanks! |
|
While we wait for an update, the workaround is to manually register the MIME type: Tested on Fedora Workstation 39 with Mattermost Desktop Version 5.5.1 (Flatpak). |
|
Just a short feedback: After upgrading to Mattermost Desktop 5.6.0.RC1 and Mattermost Server 9.2.3 everything seems to work fine now :-) |
|
I updated my installation from 8.1.x to 9.3.0 on the server side and using the 5.6.0 client on Linux ( Ubuntu 22.04 ) and we still ran into the same issue.
The desktop app redirects to the browser, where I can authenticate against Gitlab, but then I does not switch back to the app. So the fix in #2907 did not solve the problem properly. |
|
We have the same problem as grisuthedragon ... |
|
I'm having the same issue, authentication works but redirection does not work back to the client. MM 5.6.0 Tested chrome, firefox |
|
@devinbinnie looks like this issue is still present, we're facing the same problem when using Gitlab Oauth2 setup |
|
Please reopen this issue as clearly it still persists. We now have failures now across our entire estate and across all platforms including Windows, Kubuntu, Manjaro and Debian on both Firefox and Chrome. We're contemplating ditching Mattermost after many good years since we can no longer use the desktop application. MM 5.7.0 |
|
This issue still persists. @devinbinnie we still have this issue: Client: MM 5.7.0-832 (Ubuntu 22.04) |
|
For me it worked with Firefox, but not with Chrome/Brave (they always open another browser window instead of Mattermost) Client: Version 5.7.0 commit: e999e2c (NixOS unstable) Mime-Types:
|
Summary
Since upgrade to Server 9.1.0 (and 9.1.1) it does no longer work to log in trough gitlab authentication (oauth2) to the desktop app.
After downgrade to 9.0.0 it works again.
Steps to reproduce
Expected behavior
Mattermost desktop app should be logged in and display the chat-channel
Observed behavior (that appears unintentional)
The "Channels" tab is being shown with white background and a gray hyperlink to subdomain.domain.tld/subpath, after reload with Ctrl+R the mattermost login page with username/password and the "gitlab" button (same as in Step 4) is being displayed.
Possible fixes
Workaround: Downgraded Server to 9.0.0
I could not find any dubious requests in the Mattermost Developer Tools or nginx reverse-proxy except some 401 errors like the request for
https://subdomain.domain.tld/subpath/api/v4/cloud/subscription/self-serve-status
The text was updated successfully, but these errors were encountered: