Project

General

Profile

Actions

Bug #86264

open

Trusted hosts pattern mismatch with Nginx and HTTP_X_FORWARDED_PORT 443

Added by Peter Kraume over 5 years ago. Updated about 4 years ago.

Status:
Accepted
Priority:
Should have
Assignee:
-
Category:
Backend API
Start date:
2018-09-15
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When the frontend is called via https, there is this error message in the log:

PHP Fatal error:  Uncaught UnexpectedValueException: The current host header value does not match the configured trusted hosts pattern! Check the pattern defined in $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] and adapt it, if you want to allow the current host header 'ddev105.ddev.local' for your installation. in /var/www/html/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php:2803" 

Install Tools says:

The trusted hosts pattern will be configured to allow all header values. This is because your $SERVER_NAME:[defaultPort] is "ddev105.ddev.local:443" while your HTTP_HOST:SERVER_PORT is "ddev105.ddev.local:80". Check the pattern defined in Admin Tools -> Settings -> Configure Installation-Wide Options -> System -> trustedHostsPattern and adapt it to expected host value(s).

The problem seems to be that the DDEV configuration has no extra SSL configuration and thus there is a mismatch between SERVER_PORT and HTTP_X_FORWARDED_PORT which needs an additional check.

Test environment:
  • DDEV 1.2.0
  • TYPO3 9.4 composer based

Files

HTTP_X_FORWARDED_PORT.png (102 KB) HTTP_X_FORWARDED_PORT.png Peter Kraume, 2018-09-15 16:03

Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #86265: No redirect to install tool on fresh installation with FIRST_INSTALL presentClosedBenni Mack2018-09-15

Actions
Related to TYPO3 Core - Bug #32341: $_SERVER['HTTPS'] vs. $_SERVER['HTTP_HTTPS'] nginxClosedMichael Stucki2011-12-06

Actions
Related to TYPO3 Core - Bug #29693: Respect HTTP_X_FORWARDED_PROTO in SSL checkRejectedMichael Stucki2011-09-12

Actions
Actions #1

Updated by Peter Kraume over 5 years ago

  • Related to Bug #86265: No redirect to install tool on fresh installation with FIRST_INSTALL present added
Actions #2

Updated by Jigal van Hemert over 5 years ago

HTTP_X_FORWARDED_PORT is not defined in any RFC and there is some documentation of it in certain software projects.
With multiple proxies the X-Forwarded-* headers may contain lists of values, so it's only safe to assume that this will also be the case for the X_FORWARDED_PORT header.
In some cases the port is included in the X-Forwarded-Host header. How this is handled in case of a combination of X-Forwarded-Host and X-Forwarded-Port headers where one or more hosts have the port number included in the X-Forwarded-Host header is unclear to me.
The RFC-documented X-Forwarded-* headers are superseded by the Forwarded field. So, some proxies may also use a port section in the Forwarded header.

All-in-all we may end up with a combination of headers from which we have to extract the correct information. My understanding is the following list of priorities:

1. if multiple values are present in a header the first value is the original request
2. if a Forwarded header is present the use that value
3. if a port number is included in the X-Forwarded-Host header than use that value
4. if X-Forwarded-Port header is present use that value
5. use the default port for the protocol

Actions #3

Updated by Oliver Hader over 5 years ago

  • Status changed from New to Accepted

@Jigal van Hemert, sounds good to setup up a chain in order to resolve proper combinations of host & port values. Would you have time working on a potential patch/solution for this issue?

In general I can confirm that the issue exists, since I was sitting next to Peter (reporter) when this occurred in DDEV.

Actions #4

Updated by Susanne Moog over 5 years ago

  • Category set to Backend API
Actions #5

Updated by Susanne Moog over 5 years ago

  • Assignee deleted (Oliver Hader)
Actions #6

Updated by Susanne Moog over 5 years ago

  • Related to Bug #32341: $_SERVER['HTTPS'] vs. $_SERVER['HTTP_HTTPS'] nginx added
Actions #7

Updated by Susanne Moog over 5 years ago

  • Related to Bug #29693: Respect HTTP_X_FORWARDED_PROTO in SSL check added
Actions #8

Updated by Susanne Moog over 5 years ago

The old articles (see linked issues and https://review.typo3.org/#/c/4913/) mention that this could be a security issue if implemented in the core - I'm not sure if that will also be the case here because the header might be manipulated by the client.

Actions #9

Updated by Benni Mack over 5 years ago

  • Target version changed from 9 LTS to Candidate for patchlevel
Actions #10

Updated by Oliver Hader about 5 years ago

For new DDEV projects AdditionalConfiguration.php is defined with wildcard host pattern since
https://github.com/drud/ddev/commit/996b8c4d62a12fd4acc7f2828ea7a8b5f654aa39

Actions #11

Updated by Jonas Eberle over 4 years ago

This is IMHO solved for normal use. A warning on installation is still present but this seems to be a separate case: https://forge.typo3.org/issues/88846

Actions #12

Updated by Peter Kraume about 4 years ago

This issue seems to be solved in the meanwhile. I've just tested it with DDEV v1.12.0 and TYPO3 9.5.13 and everything works fine now.

Actions #13

Updated by Fabien Udriot about 4 years ago

Mmm... not for me. Same error with DDev v1.12.2 - latest TYPO3 v9 9.5.13

Actions #14

Updated by Jonas Eberle about 4 years ago

Fabien, could you check the value of [SYS][trustedHostsPattern] (in the backend, in module "Configuration" which is part of typo3/cms-lowlevel). If you did no further changes, ddev should have set it in AdditionalConfiguration.php.

Is your error exactly like the one mentioned in the original post here?

Actions

Also available in: Atom PDF