GitLab Mattermost: Upcoming breaking change when using Mattermost with a reverse proxy

Mattermost is moving to new APIv4 endpoints, which will allow for more powerful integrations and server interaction.

As part of this move, we will be moving the WebSocket endpoint to APIv4 in Q3 of 2017 (tentatively scheduled for July 16, 2017 release). This will result in a breaking change for deployments using a reverse proxy.

For those configuring NGINX proxy, just a single one-line change is required, replacing the location /api/v3/users/websocket { line with location ~ /api/v[0-9]+/(users/)?websocket$ { in the /etc/nginx/sites-available/mattermost NGINX configuration file. We've noted this in our documentation.

I'm opening an issue so we can discuss if any changes are needed for GitLab Mattermost, as we weren't sure what kind of configuration is recommended on your end.

/cc @marin @briann @twk3

added For Scheduling label

changed milestone to %9.3

added Scheduled and removed For Scheduling labels

changed milestone to %9.4

@marin Just checking to see if you need any guidance on this issue for GitLab 9.4, or whether everything is on track for GitLab 9.4?

mentioned in merge request !1760 (merged)

@jasonblais Do we even support accessing Mattermost API using GitLab SSO? I couldn't find the reference to it anywhere in the docs as Authentication section specifies using login_id and password (and mfa, if needed) to get an auth token. This isn't applicable for Omnibus installations as there is no concept of password in this case. Please point me to the correct docs, in case I missed it.

Most probably because of this reason, omnibus isn't currently setting any location block for api in the nginx configuration.

TLDR; the single line to be changed, isn't provided in the nginx configuration shipped as part of omnibus installation. Hence, there is nothing actionable here.

PS: I was able to find out the auth token via a workaround specified at https://gitlab.com/gitlab-org/kubernetes-gitlab-demo/issues/14#note_22716446 by, for the lack of a better word, exploiting, an active session. However, since that is not officially supported or documented I am not bothering about that w.r.t to this issue.

@gitlab-build-team Can someone validate if that is indeed the reason we are not providing a location block for Mattermost API? Mattermost configuration was setup before I joined.

@balasankarc It could be that no action is needed from your end, we weren't sure.

Here is the documentation related to configuring NGINX as a reverse proxy for Mattermost https://docs.mattermost.com/install/install-ubuntu-1404.html#configuring-nginx-as-a-proxy-for-mattermost-server

But as you said, your NGINX config file is a little different with no location block.

Closing as no action was required from GitLab's side.

closed