- Issue created by @nicxvan
- π§πͺBelgium kristiaanvandeneynde Antwerp, Belgium
UserRolesCacheContext should be fixed in π UserRolesCacheContext can lead to poisoned cache returns for user 1 Active
The super user policy for User 1 is being removed but there are still direct comparisons for user 1.
core/lib/Drupal/Core/Cache/Context/UserRolesCacheContext.php
is-super-user seems to be part of the replacement strategy, but also has a comment to remove it in drupal 9.0.0.
if ($this->user->id() == 1) {
return 'is-super-user';
}
core/lib/Drupal/Core/File/file.api.php
// User 1 will always see the local file in this example.
if ($user->id() == 1) {
return;
}
core/modules/system/system.module
if (\Drupal::currentUser()->id() == 1) {
return '<p>' . t('Use maintenance mode when making major updates, particularly if the updates could disrupt visitors or the update process. Examples include upgrading, importing or exporting content, modifying a theme, modifying content types, and making backups.') . '</p>';
}
core/modules/migrate_drupal_ui/src/MigrateAccessCheck.php
// The access result is uncacheable because it is just limiting access to
// the migrate UI which is not worth caching.
return AccessResultAllowed::allowedIf((int) $account->id() === 1)->mergeCacheMaxAge(0);
core/lib/Drupal/Core/Command/ServerCommand.php
/**
* Gets a one time login URL for user 1.
*
* @return string
* The one time login URL for user 1.
*/
protected function getOneTimeLoginUrl() {
$user = User::load(1);
\Drupal::moduleHandler()->load('user');
return user_pass_reset_url($user);
}
core/modules/node/node.module
* In determining access rights for an existing node,
* \Drupal\node\NodeAccessControlHandler first checks whether the user has the
* "bypass node access" permission. Such users have unrestricted access to all
* nodes. user 1 will always pass this check.
core/modules/user/src/Form/UserMultipleCancelConfirm.php
// Prevent user 1 from being canceled.
if ($uid <= 1) {
$root = intval($uid) === 1 ? $account : $root;
continue;
}
// Output a notice that user 1 cannot be canceled.
// If only user 1 was selected, redirect to the overview.
// Prevent programmatic form submissions from cancelling user 1.
if ($uid <= 1) {
continue;
}
The following are intentional install and recipe related updates and should likely stay.
core/lib/Drupal/Core/Installer/InstallerAccessPolicy.php
core/lib/Drupal/Core/Installer/NormalInstallerServiceProvider.php
core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
core/lib/Drupal/Core/Session/SuperUserAccessPolicy.php
sites/default/default.services.yml
I did not check tests since there are other followups
Search codebase for id() == 1 and id() === 1 and user 1
Update logic to check a permission or role instead of user id.
Determine best approach for each case.
UserRolesCacheContext
π
UserRolesCacheContext can lead to poisoned cache returns for user 1
Active
N/A
N/A
N/A
Active
11.0 π₯
Last updated
UserRolesCacheContext should be fixed in π UserRolesCacheContext can lead to poisoned cache returns for user 1 Active