Too Many Redirects when logging in from Mobile Apps when Server is using subpath hosting

[wech71]

Summary

Too Many Redirects when logging in from Mobile Apps when Server is using subpath hosting. Tested in 9.7.1 and with 9.7.2

Steps to reproduce

• Configure Mattermost Server to use subpath hosting (like https://mattermostserver/chat)
• Ensure Android App or iOS App is logged out
• Try to Connect to the server (I used gitlab authentication, but never got threre)

Expected behavior

Connection Form should disappear and Login form should be displayed

Observed behavior (that appears unintentional)

An error is being displayed "Too many redirects (21)"

According the nginx logs a HEAD request proxied to http://mattermost/chat, which gets redirected to http://mattermost/chat/chat then to http://mattermost/chat/chat then to http://mattermost/chat/chat/

The same can be reproduced using curl:

curl -L -I http://mattermost-server:8065/chat/
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /chat/chat
Vary: Origin
X-Ratelimit-Limit: 101
X-Ratelimit-Remaining: 100
X-Ratelimit-Reset: 1
Date: Fri, 26 Apr 2024 10:31:03 GMT

HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /chat/chat/chat
Vary: Origin
X-Ratelimit-Limit: 101
X-Ratelimit-Remaining: 99
X-Ratelimit-Reset: 1
Date: Fri, 26 Apr 2024 10:31:03 GMT

HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /chat/chat/chat/chat
Vary: Origin
X-Ratelimit-Limit: 101
X-Ratelimit-Remaining: 98
X-Ratelimit-Reset: 1
Date: Fri, 26 Apr 2024 10:31:03 GMT

HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /chat/chat/chat/chat/chat
Vary: Origin
X-Ratelimit-Limit: 101
X-Ratelimit-Remaining: 97
X-Ratelimit-Reset: 1
Date: Fri, 26 Apr 2024 10:31:03 GMT
...

HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat
Vary: Origin
X-Ratelimit-Limit: 101
X-Ratelimit-Remaining: 50
X-Ratelimit-Reset: 6
Date: Fri, 26 Apr 2024 10:31:03 GMT

curl: (47) Maximum (50) redirects followed

The problem also occurs when starting with http://mattermost/chat/

The problem does not occur when using a GET Request like curl http://mattermost/chat. In this case the main html is correctly being retured.

Possible fixes

Ensure the HEAD request does no endless redirects to the subpath even when already on the subpath.

[tgivslife]

I had the same problem. I added

 if ($request_method = HEAD) {
        return 200;
    }

to my nginx config and the login flow worked afterwards.

  location ~* ^/mattermost/api/v[0-9]+/(users/)?websocket$ {
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    client_max_body_size 250M;
    proxy_set_header        Host                $http_host;
    proxy_set_header        X-Real-IP           $remote_addr;
    proxy_set_header        X-Forwarded-For     $proxy_add_x_forwarded_for;
    proxy_set_header        X-Frame-Options     SAMEORIGIN;

    proxy_buffers 256 16k;
    proxy_buffer_size 16k;
    client_body_timeout 300;
    lingering_timeout 5;
    proxy_connect_timeout 90;
    proxy_send_timeout 300;
    proxy_read_timeout 90s;
    proxy_http_version 1.1;

    proxy_pass http://127.0.0.1:8065;
  }

  location ~* ^/mattermost {
    client_max_body_size 250M;
    proxy_set_header Connection "";

    if ($request_method = HEAD) {
        return 200;
    }

    proxy_set_header        Host                $http_host;
    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   https;
    proxy_set_header        X-Frame-Options     SAMEORIGIN;

    proxy_buffers 256 16k;
    proxy_buffer_size 16k;
    proxy_read_timeout 600s;
    proxy_http_version 1.1;

    proxy_pass http://127.0.0.1:8065;
  }

[wech71]

I had the same problem. I added

 if ($request_method = HEAD) {
        return 200;
    }

Nice. My workaround ist very similar, I only returning 405 (Method not allowed) instead of 200 (OK)

But thanks for adding - I forgot to mention the workaround :-)

[amyblais]

Opened https://mattermost.atlassian.net/browse/MM-58042

[tchellomello]

Hitting the same issue with Istio + Envoy

$ curl -v -XHEAD https://mattermost.example.com/chat/ -L
> HEAD /chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat HTTP/2
> Host: mattermost.example.com
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 302 
< content-type: text/html; charset=utf-8
< location: /chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat
< date: Mon, 06 May 2024 06:02:56 GMT
< x-envoy-upstream-service-time: 0
< server: mattermost.example.com
< vary: Accept-Encoding
< 
* Ignoring the response-body
* Connection #0 to host mattermost.example.com left intact
* Maximum (50) redirects followed
curl: (47) Maximum (50) redirects followed

However the problem does not happen whenever using a browser with a regular GET

Here is the log from the ingress controller itself whenever the APP hit it.

public-gateway-6d84b47656-58wkj istio-proxy [2024-05-06T06:07:29.243Z] 
"HEAD /chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat/chat HTTP/2" 
302 - via_upstream - "-" 0 0 2 1 "192.168.xxx.xxx" 
"okhttp/4.12.0" "51eb943f-95fb-4b44-9630-0c94cc0e8ae2" 
"mattermost.example.com" "10.223.28.130:8065" 
outbound|8065||mmtatu.mattermost.svc.cluster.local 
10.223.28.158:55082 10.223.28.158:443 192.168.xxx.xxx:57200 
mattermost.example.com mattermost.mmtatu-mattermost-public.0

[tchellomello]

Workaround the issue by creating this EnvoyFilter

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: workaround-issue-26894
spec:
  workloadSelector:
    labels:
      istio.io/gateway-name: public-gateway
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: GATEWAY
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.lua
          typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                if request_handle:headers():get(":method") == "HEAD" then
                  local path = request_handle:headers():get(":path")
                  if path and string.sub(path, 1, 5) == "/chat" then
                    request_handle:respond({[":status"] = "405"})
                    return
                  end
                end
              end

[duncan-bayne]

We're experiencing the same thing, with Nginx as well. Can confirm that returning 405 to HEAD requests to our subpath "fixed" the issue.

[agnivade]

Ok, so the issue is that a HEAD request on the sub-path used to return a 302 with the sub-path added again which led to an infinite loop. I think then returning a 200 OK would be a better response to fix this.

@cwarnermm - Something to document in our nginx docs. If the customer is setting MM in a sub-path, then a block like this:

 location ~* ^/sub-path {
    client_max_body_size 250M;
    proxy_set_header Connection "";

    if ($request_method = HEAD) {
        return 200;
    }
}

should be added.