-
Notifications
You must be signed in to change notification settings - Fork 551
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Too Many Redirects when logging in from Mobile Apps when Server is using subpath hosting #7160
Comments
I had the same problem. I added
to my nginx config and the login flow worked afterwards.
|
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 :-) |
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
|
Workaround the issue by creating this 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 |
We're experiencing the same thing, with Nginx as well. Can confirm that returning 405 to HEAD requests to our subpath "fixed" the issue. |
Ok, so the issue is that a @cwarnermm - Something to document in our nginx docs. If the customer is setting MM in a sub-path, then a block like this:
should be added. |
I have the same issue, since I am using caddy server as my reverse proxy the above nginx fix will not work for me. I tried the below, which didn't work developers.mysite.com {
@head {
method HEAD
}
respond @head 200
reverse_proxy localhost:8065
}
|
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
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:
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.
The text was updated successfully, but these errors were encountered: