Skip to content
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

Wrong port number behind reverse proxy? #282

A-Joshi opened this issue Jul 8, 2017 · 2 comments

Wrong port number behind reverse proxy? #282

A-Joshi opened this issue Jul 8, 2017 · 2 comments


Copy link

@A-Joshi A-Joshi commented Jul 8, 2017

I am running the apache with the mod_auth_openidc on port 80. This is running in a docker container which maps the port to port 8080. It is behind an nginx reverse proxy that terminates the HTTPS so the internal url looks as and external url looks like

I had the proxy pass as:
proxy_pass /;
proxy_set_header Host $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;

This resulted in a target_link_url sent to the discovery page as (note the wrong calculated port). But I think that if no port came in the no port should have been added and certainly not an incorrect implied port 80.

I think the error is in the code in function "char oidc_get_current_url_port" in file mod_auth_openidc/src/util.c where it tries to get a port number.
if no port was set in the Host header we'll determine it locally */
const apr_port_t port = r->connection->local_addr->port;
apr_byte_t print_port = TRUE;
if ((apr_strnatcmp(scheme_str, "https") == 0) && port == 443)
print_port = FALSE;
else if ((apr_strnatcmp(scheme_str, "http") == 0) && port == 80)
print_port = FALSE;
If none is supplied via X-Forwared-Port header the it should check if the X-Forwarded-Proto is supplied for the scheme first rather than just looking at the local scheme or maybe just leave it unspecified in the URL (a port is optional).

Adding the following is the current workaround.
proxy_set_header X-Forwarded-Port 443;

@zandbelt zandbelt added the enhancement label Jul 8, 2017

This comment has been minimized.

Copy link

@zandbelt zandbelt commented Jul 8, 2017

That would be (slightly) better behavior but in any case I don't consider setting X-Forwarded-Port a workaround but the better, more resilient and more explicit solution (a workaround would be to run internally on port 443).

@zandbelt zandbelt closed this in 33647c9 Jul 9, 2017

This comment has been minimized.

Copy link

@carljmosca carljmosca commented Apr 25, 2018

If I am following the suggested better solution, it would require running a Docker container with some level of elevated privilege (root?). If so, I prefer the X-Forwarded-Port solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.