Problem/Motivation

The documentation of authorize.php states that

[...] This script actually performs the selected operations without loading all of Drupal, to be able to more gracefully recover from errors.

Yet as of #2016629: Refactor bootstrap to better utilize the kernel this is not true anymore because DrupalKernel::prepareLegacyRequest() loads all modules.

Proposed resolution

Remaining tasks

User interface changes

API changes

CommentFileSizeAuthor
#8 2344017-authorize-should-run-minimal-set-of-modules-8.diff2.86 KBznerol
#8 interdiff.txt3.96 KBznerol
#3 2344017-authorize-should-run-minimal-set-of-modules.diff1.55 KBznerol

Comments

znerol’s picture

znerol commented
Issue summary: View changes
znerol’s picture

znerol commented
Related issues: +#538660: Move update manager upgrade process into new authorize.php file (and make it actually work)
znerol’s picture

znerol commented
StatusFileSize
new 2344017-authorize-should-run-minimal-set-of-modules.diff1.55 KB

This reverts the relevant bits introduced in #538660: Move update manager upgrade process into new authorize.php file (and make it actually work).

znerol’s picture

znerol commented
Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 3: 2344017-authorize-should-run-minimal-set-of-modules.diff, failed testing.

Crell’s picture

Crell commented
Issue tags: -WSCCI

This isn't WSCCI.

znerol’s picture

znerol commented

Well, it was introduced by a WSCCI-tagged issue...

znerol’s picture

znerol commented
StatusFileSize
new interdiff.txt3.96 KB
new 2344017-authorize-should-run-minimal-set-of-modules-8.diff2.86 KB

Trying a different approach, introduce a $load_modules parameter to preHandle() and prepareLegacyRequest().

catch’s picture

catch
he/him
Primary language English
commented
Component: base system » request processing system

#2353357: hook_stream_wrappers_alter() should be removed as it is broken since modules are not loaded on demand might fix the all modules being loaded issue, or this should probably be postponed on that to narrow things down.

Regressions caused by the kernel changes to bootstrap seems very much a request processing issue to me (it is directly in the critical path of request processing, after all), whether or not this issue is deserving of the WSCCI tag.

Crell’s picture

Crell commented
Issue tags: +Needs issue summary update

Can we get an testable patch here? And update the IS to make it clear what the bug to be fixed is, since clearly the code does work now...

znerol’s picture

znerol commented

As per the @file documentation comment, the authorize script is supposed to run in a stripped-down environment with only a minimum amount of code loaded. If this is not of importance anymore, then the authorize script should be removed entirely.

David_Rothstein’s picture

David_Rothstein commented

I just read through https://groups.drupal.org/node/24709 (fascinating read, by the way) and it looks like there were two reasons for it not to load all modules:

  1. The one mentioned in the @file comment ("recover from errors"). The idea being that if you update a module and it breaks your whole site, you should still be able to access authorize.php to recover from it. Only little problem with that is... authorize.php doesn't do anything to help you recover. It certainly doesn't provide any kind of rollback functionality, and heck, it doesn't even display any helpful links about rolling back.
  2. Security. Because you can enter FTP or SSH credentials on authorize.php, the idea is that if you had some Drupal module installed that had an XSS vulnerability, and the vulnerability is present on authorize.php also, the attacker could potentially steal your server credentials as you type them. This is legit, but if you have an XSS vulnerability you are in pretty big trouble anyway. I guess this is worse, but there's a limit to how much worse it really could be.

Overall doesn't seem like a major bug to me, but there are some potential reasons for it to be its own script so changing that would be better discussed in a separate issue.

I think for this issue it's best to just fix the problem. Here's what authorize.php does in Drupal 7:

  require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
  drupal_bootstrap(DRUPAL_BOOTSTRAP_SESSION);

Anyone know what the Drupal 8 equivalent of that would be?

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.

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.

mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented
Version: 8.6.x-dev » 8.7.x-dev

This issue might be fixed by #2869573: Remove usages of deprecated DrupalKernel::prepareLegacyRequest(), or else whenever we remove prepareLegacyRequest() in D9.

mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented
Related issues: +#2869573: Remove usages of deprecated DrupalKernel::prepareLegacyRequest()

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.9 was released on November 6 and is the final full bugfix release for the Drupal 8.7.x series. Drupal 8.7.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.8.0 on December 4, 2019. (Drupal 8.8.0-beta1 is available for testing.)

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

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

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

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented
Status: Needs work » Closed (outdated)
Issue tags: +Bug Smash Initiative

DrupalKernel::prepareLegacyRequest() was removed in Drupal 9.0 in #2869573: Remove usages of deprecated DrupalKernel::prepareLegacyRequest() and Drupal 8 is EOL, so the changes suggested here are no longer relevant.

Therefore, closing as outdated.

Thanks!