Host header wrongly set when using firewall port redirection

[billyonthemountain]

I believe 6b1381a introduced a regression in the routing module; connecting from outside the local network now fails.

Here are the specifics of my configuration:

• firewall re-routes inbound requests on 443 to port 444 on the web server in my local network
• local web server has a virtual host listening for name-based requests (eg. "webtrees.myhost.com") on port 444 and 443 to redirect the browser to the proper service.

When I make a request using the base url only (https://webtrees.myhost.com), I get redirected to https://webtrees.myhost.com:444/index.php?route=login. Upon inspection the "host" variable in the request headers is set to "webtrees.myhost.name:444". If I connect by entering "https://webtrees.myhost/index.php?route=login" instead, the page loads normally and the host variable is set to webtrees.myhost.name.

[fisharebest]

webtrees must detect the site URL using the information available in the $_SERVER[] variable.

(You can examine these variables in the control panel, under "Server information").

For sites that are behind a reverse-proxy, or similar configuration, the information to create this URL is not always available.

There are two solutions to this problem.

1) The webserver can set headers (e.g. HTTP_X_REQUESTED_HOST), and the application can be configured to process these headers. 2) The URL can be hard-coded into the application.

webtrees beta.3 release supports (2) - and support for (1) will follow later.

You must add a line to the file data/config.ini.php which contains your site URL. e.g.

base_url="https://webtrees.myhost/"

[billyonthemountain]

Setting base_url does indeed bring me to the login page. However it seems that the url field in the login form is not picking the base_url properly:

<form action="https://webtrees.myhost.com/index.php?route=login" class="wt-page-options wt-page-options-login" method="post">
<input type="hidden" name="csrf" value="<SOME_VALUE>">
<input type="hidden" name="url" value="https://webtrees.myhost.com:444/">

Manually reloading the page from the browser would then send you to the user page.

[billyonthemountain]

note: So after POSTing the login form, the GET request is then sent to https://webtrees.myhost.com:444/index.php?route=tree-page&ged=my-tree instead of the standard 443 port.

[fisharebest]

Can you confirm you are using the beta.3 release (or latest dev code).

[billyonthemountain]

You mean master, not the develop branch right ? Yes indeed, I am on 2.0.0-beta.3 / 099a3d7.

[fisharebest]

<input type="hidden" name="url" value="https://webtrees.myhost.com:444/">

This is the URL of the page that referred you to the login page.

You were viewing this page before you clicked the login link?

[billyonthemountain]

Yes correct.

[fisharebest]

After login, you are redirected to the previous page. So this behaviour sounds correct.

I guess that you have two ways to access your site - using the internal (port 444) and external URLs.

You visited the internal site, clicked login (redirected to the external URL), and then were redirected back to the internal site.

If you want to be able to access your site from two different URLs, then you must wait for support for trusting the HTTP proxy headers. Until then, you can only use one URL.

[billyonthemountain]

You visited the internal site, clicked login (redirected to the external URL), and then were redirected back to the internal site.

Not really. The snippets I posted above are from requests I made from outside my local network. I set-up the local webserver to listen on both ports 443 and 444. Port 444 is only for requests forwarded from outside my local network by the firewall/NAT :

• Requests from the internet: webtrees.myhost.com:443 => Public DNS => :443 => NAT redirection => :444
• Requests from the intranet: webtrees.myhost.com:443 => Local DNS => :443.

This was done so that my users can always use the same domain name whether from inside or outside the local network while also working around some unrelated issues with my Synology NAS.

Bottom line: a user never accesses the site by typing in webtrees.myhost.com:444.

[billyonthemountain]

But this might be the expected behaviour due to the changes introduced by those PSR-7 requests. I am just confused due to my modest understanding of how things work under the hood and because it worked until 6b1381 got introduced.

[fisharebest]

Bottom line: a user never accesses the site by typing in webtrees.myhost.com:444.

Sorry, I assumed the opposite, from your "Yes, correct" comment.