Reverse proxy settings for multisite cannot work

Hi,

FYI your patch does not apply on a vanilla Drupal 8.6.x because it is started from core folder and not the docroot.

The following link could help you to create a patch for a Drupal core issue: https://www.drupal.org/contributor-tasks/create-patch.

Hi,

The patch proposed from this issue #2972310: Reverse proxy settings not used doesn't work with this problematic because the call of ReverseProxyMiddleware::setSettingsOnRequest($request, Settings::getInstance()); is made after the initializeSettings() call.

A very simple solution is to alter or extends DrupalKernel and call Request::setTrustedProxies() with good IP's values.

Ex :
DrupalKernel.php

  /**
   * {@inheritdoc}
   */
  public function handle(Request $request, $type = self::MASTER_REQUEST, $catch = TRUE) {
      ...
      // line 657
      $request::setTrustedProxies([$request->server->get('REMOTE_ADDR')]); // your proxy IP's array
      ...

  }

It's not a viable solution, but it's KISS...

Nicolas

Hi,

This patch is a simple solution and fix effectively the problem with trusted proxies.

Use case
I applied this patch on 2 projects which are behind Nginx Reverse Proxy + Varnish on AWS with a multisites configuration and everything works as expected.
The load balancer which we use is ALB.

About the patch

I'm not convinced that add a another configuration files is necessary.
sites/reverse_proxy_settings.php is unuseful because, the action to set Trusted Proxies must be apply in the Front Controller, not at the instanciation of DrupalKernel.

Proxy are environmental and their configuration must be apply apart from DrupalKernel.

Symfony 4 front controller apply configuration on proxy before the Kernel instanciation :

<?php
...

if ($trustedProxies = $_SERVER['TRUSTED_PROXIES'] ?? false) {
    Request::setTrustedProxies(explode(',', $trustedProxies), Request::HEADER_X_FORWARDED_ALL ^ Request::HEADER_X_FORWARDED_HOST);
}

if ($trustedHosts = $_SERVER['TRUSTED_HOSTS'] ?? false) {
    Request::setTrustedHosts(explode(',', $trustedHosts));
}

$kernel = new Kernel($env, $debug);
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);

Big thank's
Thank's @fancyweb for this patch and your pragmatic way to handle this problem.

Hi

Thanks for the patch :)
It has been tested on production with a multisite Drupal instance and it works.
I have some comments about the patch and the comment of @mamoot that I'll add later since my comment is about another issue that this patch fixes too.

This patch fixes another issue as well:
if your Drupal is behind a reverse proxy the trusted host mechanism does not works.
When it checks if the host is parts of the trusted hosts, the reverse proxy settings are not set up yet.
The host retrieved by $request->getHost(); inside DrupalKernel::setupTrustedHosts() is the reverse proxy one.
It means that the host is not trustworthy.

Before adding this issue as a proper issue and linked it to this one with a comment saying "The patch from #2998728 comment #8 fix this issue as well":
I'll wanted to ask your opinion about creating a specific issue that will list all the issues about the reverse proxy settings not set up properly at the correct moment.
Its aim could be to set up a roadmap and centralized the discussion about it.

What do you think?

I just fix a warning Warning: func_get_arg(): Argument 3 not passed to function on the patch provided in comment #8

Reroll for 8.6.x, 8.7.x, 8.8.x
No interdiff needed.

Added the Mr For the #13 for re-roll the patch .

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I ran into this as well for https://wimleers.com after upgrading from Drupal 7 to 10. It made me pull my hair out for hours. Although I'm on a very atypical setup: local server at home, via non-standard port (ISP blocks port HTTP(S) ports) as HTTP, served by a CDN as HTTPS. At first, I just thought I was doing something wrong in my exotic (but dead simple!) setup, but it turns out to have been this long-standing Drupal core bug 🙈

Even though it's a single site! Because many years ago, it was considered a best practice to not use sites/default/files, but sites/example.com/files. Because I don't use sites/default, the same code path is triggered as for a multisite.

I didn't really need trusted proxies; I only needed the reverse proxy (Fastly) to be trusted, to ensure that the TLS termination at the Fastly edge was respected.

While I first hacked core (🙈), I then settled on something simpler: running this early enough, aka before Drupal's index.php is executed:

// When any non-local IP acccesses this, serve this as if it's the live site.
// (It should be a Fastly IP address, and it is possible to validate against that, but this suffices.)
// @see https://www.fastly.com/documentation/reference/api/utils/public-ip-list/
if (filter_var($_SERVER['REMOTE_ADDR'], FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
  $_SERVER['HTTP_HOST'] = 'wimleers.com';
  // Fastly also does TLS termination for us, so make Drupal think it's accessed via https://.
  // @see https://docs.fastly.com/en/guides/tls-termination#when-using-wordpress
  $_SERVER['HTTPS'] = 'on';
}

(Because doing it in settings.php is too late.)