-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Infinte Redirect Loop For SSO Login When Behind A Reverse Proxy #10492
Comments
@warricksothr Have you seen the docs on ensuring that |
@clokep I have my server defined with the Here is the relevant nginx location block with the workaround I mentioned above. I tested this previously with the proxy_pass pointed to the
Unfortunately the code that is responsible for this check just looks at just the request to see if it is secure and doesn't check any additional headers. def get_request_uri(request: IRequest) -> bytes:
"""Return the full URI that was requested by the client"""
return b"%s://%s%s" % (
b"https" if request.isSecure() else b"http",
_get_requested_host(request),
# despite its name, "request.uri" is only the path and query-string.
request.uri,
) and then does an assertion that the request and the ...
requested_uri = get_request_uri(request)
baseurl_bytes = self._public_baseurl.encode("utf-8")
if not requested_uri.startswith(baseurl_bytes):
... This does bring up a potentially cleaner fix than the one I have proposed in #10494 however it might also be a bit more opaque and error prone when that header is missing. |
I believe the Lines 448 to 476 in 95e47b2
|
Hmm... I'll have to do a bit more digging then. Thanks for the information! |
I agree, this code definitely is supposed to take that into account. My configuration is setup with the appropriate header on the proxied request, but I still received the following log entries.
🤔 |
I just upgrade from Synapse v1.28.0 to v.1.39.0 and hit this issue. Using the Apache setting |
I'm pretty sure this is a configuration error in the reverse-proxy. If there's any doubt, I suggest taking a In the meantime, I'm going to close this. |
Apologies for the delay, I did switch back to the http port to do some debugging, and here's part of a TCP dump of the traffic across the poxy during an OIDC redirect.
To me this looks correct, both |
@richvdh is there anything else you'd want to see from a TCP dump, I didn't see a whole lot but am not necessarily sure what I'd be looking for. I have a snapshot of 30 seconds of traffic during which the OIDC redirect is triggered that I'd be willing to share. However it is full of ipv4 addresses so I'm not willing to share such a log publicly without redacting all of those addresses. |
Here's the full reverse proxy configuration for reference
|
silly question maybe, but have you set |
Not a silly question at all. I don't know how I missed this configuration parameter for the http port. With This syanpse configuration file is a few years old, I'll need to go through it again to make sure I haven't missed other settings as I've upgraded and enabled additional functionality. |
great, glad you got it sorted. I think it's a shame that https://matrix-org.github.io/synapse/latest/reverse_proxy.html#homeserver-configuration is easy to overlook. It might be better to move that section above the "Reverse-proxy configuration examples". If you'd like to make a PR to do so, that would be great! |
Sure, I'll open a PR later today for the documentation change to move that section toward the top of the Reverse Proxy documentation. |
Had the same problem, despite the proper config had infinite loop. Was able to resolve by updating nginx to the last stable version |
Description
When SSO is enabled, the public_baseurl is set to an
https
scheme endpoint, and the site is runningbehind a reverse proxy that terminates ssl and forwards all traffic as
http
the SSO login redirect willinfinitely loop because the request is for an
http
endpoint but thepublic_baseurl
is pointed at anhttps
endpoint. The root of the issue is the simplestartswith
bytes check inside the SSO redirectthat is meant to make sure that cookies are set on the right domain (#9436).
The
public_baseurl
mentions that it should be set to the same scheme as what is behind the reverse proxyhowever that results in clients like element web being unable to resolve resources behind the reverse proxy
as they aren't always obeying
301
and302
redirects for resources and exposing thehttp
endpoint externally isundesirable.
Workaround
The current work around used on my homeserver (matrix.nulloctet.com) is to point the reverse proxy at the
https
backend for synapse and leave the
public_baseurl
ashttps://matrix.nulloctet.com/
. This results in no loop becausethe web request is on the same scheme as the
public_baseurl
. However I am not a fan of terminating anTLS
connection only to remote proxy anotherTLS
connection behind the scene. I also do not want to run synapsecompletely public as that would be a regression in functionality and would be a special snowflake among the other
services I run.
Proposed Solution
The check of the request and the
public_baseurl
should completely ignore the scheme, as only the dns nameis required to match for cookies to be correctly set.
Steps to reproduce
https
schemeVersion information
If not matrix.org:
Versions Tested:
Version: 1.38.1
Version: 1.37.1
Version: 1.35.0
Install method: Docker-Compose
The text was updated successfully, but these errors were encountered: