Problem/Motivation

Running update.php under SSL behind a reverse proxy doesn't work. Reverse proxy settings from settings.php don't appear to be respected. I'm running a Drupal 8 site on Acquia, and the request header overrides aren't working on update.php. This appears to be happening because middleware (including ReverseProxyMiddleWare) isn't running on the request.

Proposed resolution

Not sure... Either pull the logic from ReverseProxyMiddleWare into update.php, or run selected middlewares on update.

Remaining tasks

Come up with an approach and implement it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rbayliss created an issue. See original summary.

dawehner’s picture

Status: Active » Needs review
FileSize
1 KB

I'm curious whether this fixes the problem for you ...

rbayliss’s picture

Issue tags: +Needs tests

Yup, that worked. I guess we need a test for this?

dawehner’s picture

Puh yeah why not, but it could be hard to actually test it.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mithenks’s picture

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Chris Burge’s picture

I can confirm patch #2 resolves this issue. I have a D8 site sitting behind a reverse proxy and was having the same issues with update.php.

jenlampton’s picture

Status: Needs review » Reviewed & tested by the community

I can also confirm this fixes the issue with running update.php with all the appropriate permissions, on a Drupal 8 site, on Acquia hosting, as documented here: https://www.drupal.org/project/drupal/issues/2955678

alexpott’s picture

This is an interesting problem. This suggests the ban middleware is also not firing. :(

I think we need to be able to mark certain middleware as update-safe and they should be fired. As this is a really issue that is breaking sites I think it is okay to do this in a follow-up but there is indicative of a wider problem with the shortcut that is the UpdateKernel.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: -Needs tests

Crediting @rbayliss for opening the issue.

Committed and pushed 46f02154f8 to 8.7.x and e839a9726a to 8.6.x. Thanks!

Backported to 8.6.x because not being able to run updates is a security issue.

Didn't ask for tests because this is difficult and there are unit tests of ReverseProxyMiddleware already.

  • alexpott committed 46f0215 on 8.7.x
    Issue #2618606 by dawehner, rbayliss: Update.php - Reverse proxy...

  • alexpott committed e839a97 on 8.6.x
    Issue #2618606 by dawehner, rbayliss: Update.php - Reverse proxy...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.