Problem/Motivation

Url::access() doesn't bubble cacheability metadata, and consequently could lead to security vulnerabilities in case developers fail to take this into account.

See #2661200-52: Make admin/help page more flexible, and list tours on it's interdiff-url-changes.txt for an initial patch.

Proposed resolution

Make it bubble cacheability metadata.

Remaining tasks

TBD

User interface changes

None.

API changes

TBD

Data model changes

None.

Issue fork drupal-2677902

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

Wim Leers created an issue. See original summary.

xjm’s picture

So what are the implications of this? Can we update the summary from whatever information is relevant on the other (lengthy) issue?

Also, just to confirm, this was not actually committed as part of #2661200: Make admin/help page more flexible, and list tours on it?

catch’s picture

wim leers’s picture

The implications are now in the IS.

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.

willzyx’s picture

Status: Active » Needs review
StatusFileSize
new6.36 KB

let's try with the patch provided in #2661200-52: Make admin/help page more flexible, and list tours on it interdiff-url-changes.txt

dawehner’s picture

  1. +++ b/core/lib/Drupal/Core/Url.php
    @@ -8,6 +8,7 @@
     use Drupal\Core\Routing\RouteMatchInterface;
     use Drupal\Core\Routing\UrlGeneratorInterface;
    @@ -801,15 +802,21 @@ public function getInternalPath() {
    
    @@ -801,15 +802,21 @@ public function getInternalPath() {
        * @param \Drupal\Core\Session\AccountInterface $account
        *   (optional) Run access checks for this account. Defaults to the current
        *   user.
    +   * @param bool $return_as_object
    +   *   (optional) Defaults to FALSE.
        *
    -   * @return bool
    -   *   Returns TRUE if the user has access to the url, otherwise FALSE.
    +   * @return bool|\Drupal\Core\Access\AccessResultInterface
    +   *   The access result. Returns a boolean if $return_as_object is FALSE (this
    +   *   is the default) and otherwise an AccessResultInterface object.
    +   *   When a boolean is returned, the result of AccessInterface::isAllowed() is
    +   *   returned, i.e. TRUE means access is explicitly allowed, FALSE means
    +   *   access is either explicitly forbidden or "no opinion".
        */
    -  public function access(AccountInterface $account = NULL) {
    +  public function access(AccountInterface $account = NULL, $return_as_object = FALSE) {
         if ($this->isRouted()) {
    -      return $this->accessManager()->checkNamedRoute($this->getRouteName(), $this->getRouteParameters(), $account);
    +      return $this->accessManager()->checkNamedRoute($this->getRouteName(), $this->getRouteParameters(), $account, $return_as_object);
         }
    -    return TRUE;
    +    return $return_as_object ? AccessResult::allowed() : TRUE;
       }
    

    I'm wondering whether a dedicated method like ->accessResult() would be actually a better approach. We then could mark access() as deprecated, and let people always explicitly thing about what they want to do.

  2. +++ b/core/lib/Drupal/Core/Url.php
    @@ -818,11 +825,11 @@ public function access(AccountInterface $account = NULL) {
        * @param array $element
        *   A render element as returned from \Drupal\Core\Url::toRenderArray().
        *
    -   * @return bool
    -   *   Returns TRUE if the current user has access to the url, otherwise FALSE.
    +   * @return \Drupal\Core\Access\AccessResultInterface
    +   *   The access result.
        */
       public static function renderAccess(array $element) {
    -    return $element['#url']->access();
    +    return $element['#url']->access(NULL, TRUE);
       }
     
    

    Isn't that a BC break?

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.

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

Drupal 8.6.x will not receive any further development aside from security fixes. 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.

mxr576’s picture

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

bump

I'm wondering whether a dedicated method like ->accessResult() would be actually a better approach. We then could mark access() as deprecated, and let people always explicitly thing about what they want to do.

Totally agree, developers must be aware that they are working with an object that provides cacheability information which must be bubbled up if they rendering an URL on the web UI.

dawehner’s picture

I do agree a separate method would be great, but I wonder whether introducing this just on the URL object is the right approach. There are tons of places with a parameter to decide whether an object or a boolean should be returned.

Maybe it would be possible for Drupal 10 to just remove the $return_as_object in case https://wiki.php.net/rfc/objects-can-be-falsifiable is available?

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new150 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

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

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

prudloff made their first commit to this issue’s fork.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.