-
-
Notifications
You must be signed in to change notification settings - Fork 92
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
Enhance Reproxy Support for X-Forwarded Headers #172
Comments
Appending X-Forwarded-Port and X-Forwarded-Proto is the right thing to do, regardless of the second point. Regarding custom headers - it is fine with me, too; we already have the Let me know if you want to deal with this and provide a PR with the change(s) |
This PR created a regression where |
Thanks for the report. I don't think appending additional values in the comma-separated list is appropriate in this case. I believe the right thing to do is to skip setting those headers if they are already present. |
fixed in v1.1.1, pls check it out |
Thanks for the prompt fix, switched to v1.1.1 and things are back to normal! |
In certain applications, it is crucial to be aware of the complete request URL, including the host, port, and scheme. These details are typically relayed via the headers X-Forwarded-Host, X-Forwarded-Port, and X-Forwarded-Proto. While Reproxy currently handles the X-Forwarded-Host header effectively, passing the original hostname, it does not accommodate for the port and scheme, which are essential in mixed protocol scenarios.
Use Case:
Our scenario involves deploying a Keycloak service with Reproxy. Internally, the Keycloak container exposes port 8080 and operates over HTTP. However, the public URL is configured as https://idp.example.com/, with Reproxy directing traffic to the Keycloak service. Keycloak is utilized for user authentication, with the frontend URL passing through Reproxy, while client authentication occurs directly via the container's hostname.
Observed Issue:
When attempting to access the Keycloak admin page, users are incorrectly redirected to https://idp.example.com:8080/. This behavior indicates a mismatch in the scheme and port handling between the internal service (Keycloak) and the external access method (Reproxy).
Posible Solutions:
Automatic Header Handling: Implement functionality in Reproxy to automatically append X-Forwarded-Port: 443 and X-Forwarded-Proto: https headers when SSL is in use. This would ensure that services behind Reproxy are aware of the original request's protocol and port, even when the internal service operates over a different protocol or port.
Custom Header Configuration: Introduce a new parameter in Reproxy's configuration to allow the addition of custom request headers. This would provide users with the flexibility to specify any necessary headers based on their unique deployment scenarios.
The text was updated successfully, but these errors were encountered: