Mattermost generates wrong redirect uri for SSO authentication

[jdoubleu]

Maybe it's a bit late but the bug still exists.

There was a long issue about a bug where singing-in into Mattermost through GitLab doesn't work if Mattermost is behind a reverse proxy and this proxy communicates with HTTP with Mattermost while the user is facing the page with HTTPS (because the proxy support SSL). You can read it here.

First of all:

Summary

Singin-in/Authenticating via SSO with GitLab won't work because the generated URI contains the wrong protocol if Mattermost ist behind a proxy, communicating with HTTP, and the page URL isn't set in Mattermost's settings.

Steps to reproduce

• Run Mattermost behind a reverse proxy,
• let the proxy communicate with Mattermost via HTTP,
• configure the proxy to support HTTPS for the user,
• enable SSO with GitLab,
• finally: try to log-in

Expected behavior

After clicking the SSO button on Mattermost, it will redirect me to GitLab where I have to login-in and authorize the Application to use my account data. After authorizing GitLab should redirect me to Mattermost where I'm logged in now.

Observed behavior

After clicking the SSO button GitLab will fail (with the error message: The redirect URI included is not valid.) due to the fact, that the redirect_uri query param doesn't match the provided client_id.

Possible fixes

One simple fix might be to set the page url of Mattermost in its settings.

I've inspected the code and I wanted to share my results here.

Clicking the GitLab button on the log-in page of Mattermost will redirect me to /api/v3/oauth/gitlab/login, this API call with initiate a 302 redirect to GitLab https://gitlab.example.com/oauth/authorize?response_type=code&client_id=_64_length_string&redirect_uri=http%3A%2F%2Fmattermost.example.com%2Fsignup%2Fgitlab%2Fcomplete&state=_another_long_string.

This redirect is managed inside the api/oauth.go file, where on line 727 the link is generated.

The function GetSiteUrl in api/context.go, line 462 gets called which only returns the actual site url.

The current site url is set in the ServeHTTP function in the context.go file, on line 145 this will set the url set by the user, if it exists, or, if not, generate it with the protocol and host.

To get the protocol, this function calls the GetProtocol function in context.go on line 267.

Although this function tries to get the X-Forwarded-Proto (client header call on line 268, using the HEADER_FORWARDED_PROTO constant) it get's the wrong protocol.

My proxy serves the X-Forwarded-Proto header correctly to Mattermost.
I didn't test what went wrong in the GetProtocol function.

Also one thing I want to point out is that there is a newer standardized form of the Forwared headers (see RFC 7239) which should be recognized.

EDIT
Fixed links pointing to v3.3.0 tag now instead of matser branch where some code changes appeared.

[lfbrock]

Hi @jdoubleu - thanks for filing something on this, I've created a Jira ticket for someone to go look at it.

If it's something you're interested in submitting a fix for, feel free to sign up for our daily builds server and join the Developer channel to discuss it.

[lfbrock]

Closing this issue + will track in Jira

[monty241]

Similar to issue we are seeing in combo gitlab and mattermost last released version. In our case it is behind nginx but the weird part is not an invalid redirect urine (which we also see with often products often as configuration issue) but that the client browser performs a request back to the Web server and the Web server never delivers and times out after 2 minutes. The redirect is not returning to something correctly. I will try disabling sso as a work around.

[monty241]

Great analysis by the way

[rdslw]

BTW, this possible solution did not work for me "One simple fix might be to set the page url of Mattermost in its settings."

Meaning (if @jdoubleu analysis is correct) that there is some more problems inside context.go as siteurl defined in cfg is not being used here.

[stanhu]

I've tried to replicate this problem and haven't been able to do so yet. I have one question about this remark:

After clicking the SSO button GitLab will fail (with the error message: The redirect URI included is not valid.) due to the fact, that the redirect_uri query param doesn't match the provided client_id.

If client_id is invalid, GitLab will report a different message:

Client authentication failed due to unknown client, no client authentication included, or unsupported authentication method.

If GitLab says, "The redirect URI included is not valid", that usually means the redirect_uri generated by Mattermost doesn't match the allowed redirect endpoints specified in GitLab. Even an extra slash can cause this. A mismatch in the protocol (http:// vs https://) would also cause this.

Are you sure the Mattermost OAuth2 client ID and secret match the values provided by GitLab?

[monty241]

@stanhu To whom is the question "Are you sure the mattermost...GitLab" directed?

[jdoubleu]

Okay I rechecked all my settings and the problem still exists.

Here's my setup:

I'm currently using GitLab 8.12.6 Omnibus which runs under https://git.example.com.
I couldn't determine the exact version of Mattermost but I'm using the latest docker image (image ID 35281f9a2aa2 created 6 days ago).
Mattermost is accessible under https://mattermost.example.com.

Both GitLab and Mattermost are running behind a reverse proxy which communicates via HTTP with them but over HTTPS with be client.
The reverse proxy passes the following proxy headers:

proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;

(Note the X-Forwarded-Proto header)

I've left the Site URL option of Mattermost in Settings > General > Configuration blank.
In GitLab I created a global Application in the admin Settings giving the callback URL's:

https://mattermost.example.com/login/gitlab/complete
https://mattermost.example.com/signup/gitlab/complete

On the side of Mattermost I setup the following options under Settings > Authentication > GitLab:

1. Application ID and Application Secret Key give from the step before,
2. User API Endpoint to https://git.example.com/api/v3/user,
3. Auth Endpoint to https://git.example.com/oauth/authorize and
4. Token Endpoint to https://git.example.com/oauth/token

Behaviour
Trying to login into Mattermost and clicking the GitLab sign-in button redirects me to

https://git.example.com/oauth/authorize?response_type=code&client_id=_SOME_64_CHARS_LONG_STRING_&redirect_uri=http%3A%2F%2Fmattermost.example.com%2Fsignup%2Fgitlab%2Fcomplete&state=_ANOTHER_124_CHARS_LONG_STRING_

which results in GitLab throwing

The redirect URI included is not valid.

I guess this happens because the redirect_uri query parameter in the GitLab SSO request points to HTTP while the provided application ID points to HTTPS.

I came to the result, as described in the issue, that the Mattermost API which inits a redirect to GitLab doesn't build the correct uri - more specific the protocol is wrong.

Providing the correct URL to Mattermost (using HTTPS) in Settings > General > Configuration will result in a correct URI.

---

To answer @stanhu 's question:

The client_id seems to be correct but the request_uri doesn't.

If GitLab says, "The redirect URI included is not valid", that usually means the redirect_uri generated by Mattermost doesn't match the allowed redirect endpoints specified in GitLab. Even an extra slash can cause this. A mismatch in the protocol (http:// vs https://) would also cause this.

Totally correct!

[jdoubleu]

Okay I found the problem!

I've setup Mattermost inside docker containers. Therefore I used the docker-compose.yml file from mattermost-docker.

Mattermost is working correct and the functions mentioned in the issue are doing a good job but the docker containers doesn't.

I'm creating an issue over there but here's a short explanation:
I mentioned that the setup provided in the repository uses an own proxy. However this proxy is accessed through my reverse proxy by http and so this proxy passes http as X-Forwared-Proto header.

I just dropped this little proxy but I'll also create a PR for a workaround.

[stanhu]

@jdoubleu Thanks for figuring this out! I had a feeling it had to do with confusion over the X-Forwarded-Proto header.

I wonder if GitLab omnibus should write out SiteURL to avoid any ambiguity since mattermost_external_url specifies this.