Mattermost with Gitlab SSO ignores https scheme when creating implicit token request

Troubleshooting
1

Hi there,

First of all thank you for creating this project and I’m even more stoked that it integrates with Gitlab making it much easier to get it adopted in the organisation that’s already using Gitlab.

Now my frontend servers use HSTS header so all things that run off them, run on https off a wildcard certificate. I’ve used your draft notes to configure mattermost (0.7.1 precompiled binary) with Gitlab SSO and it’s working a treat.

The only hitch that I noticed was that when mattermost calls the OAuth Authorize endpoint, it uses redirect url of http and not https. Since I didn’t expect that, I didn’t have it configured originally (but added the http counterpart just so it can get authorization). Is there a way to tell mattermost that it’s running in SSL mode (via SSL based frontend proxy server which is then doing http reverse proxy to mattermost) and it should only request https based urls?

PS: Thank you @alerque as I used your configuration snippets as a sample starting point and everything just fell into place once I put the right values in for my setup.

2

I’m glad you found that useful. Now I just wish I could get my own instance working! I think you are right that Mattermost needs to forward to the correct URL’s, but I’m not sure this needs to be a configuration item. I think it should probably detect this in the headers coming from the browser or just use protocol-less redirects to avoid having to know at all.

In the mean time you can probably correct for this error in your front end. Instead of hosting an HTTP version to catch that one page load, redirect that traffic to where it belongs. I use a catch-all HTTP vhost that then has a list of domains that should be HTTPS only and shunts any confused traffic off to where it belongs:

RewriteCond %{HTTP_HOST} ^(gitlab|mattermost).alerque.com$ [NC,OR]
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [NE,L,R=301]
1 Like
3

Thanks a lot for the quick reply and code snippet. I sorted it out by first adding the http:// based urls to token’s allowed redirect uris and then I let webserver (cherokee in my case) deal with it (which automatically redirects anything sent to 80 to 443 via 301.

I got the installation working but I figured I’ll point it out in case this isn’t obvious to other people trying to install this in a similar configuration. I’m sure with that code snippet of yours most of the people will be able to work around this.

4

Just a thought: Is it possible that you cancelled the first time Gitlab SSO asked you for authorization? It happened to me while I was configuring. I cancelled out the first request (i was testing if altering the redirect_uri to https mode will work), and then when i went back there… it kept giving me 502.

I deleted the application and then remade it back and it started working. This is my first time with Gitlab SSO, so I’m not sure where it stores the authorizations (other than db that I don’t feel like fiddling with) and if a user can revoke permissions or alter a revoked permission to a granted one.

5

As this is still broken in 1.0.0-RC1 I have opened an issue report for it.