Problem/Motivation

Follow-up from #3279840: Update mglaman/phpstan-drupal.

In there we found that the rule for access check-checking on entity queries (introduced in mglaman/phpstan-drupal version 1.1.15) isn't fully working yet.

Since we wanted all the "goodness" that a jump from the at the time version 1.1.9 to 1.1.16 would bring, we decided to update to 1.1.16, _but_ ignoring the rule for that.

An entry in core/phpstan.neon.dist was made for ignoring this rule:

    # This check was ignored on purpose until the issues with it, which started in version 1.1.15, are solved.
    # @see https://www.drupal.org/node/3280328
    - "#^Missing explicit access check on entity query.#"

Steps to reproduce

Proposed resolution

As soon as mglaman/phpstan-drupal cuts a release that solves all our issues with the above rule, remove the above lines from core/phpstan.neon.dist.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

Spokje created an issue. See original summary.

spokje’s picture

Issue summary: View changes
spokje’s picture

Title: Stop ignoring "Missing explicit access check on entity query." rule in core/phpstan-baseline.neon » [PP-1 Upstream] Stop ignoring "Missing explicit access check on entity query." rule in core/phpstan-baseline.neon
Status: Active » Postponed

Postponing on a release of mglaman/phpstan-drupal which solves all our issues with the access check-checking on entity queries.

spokje’s picture

Version: 10.0.x-dev » 10.1.x-dev
Status: Postponed » Needs review

Looks like with the release of https://github.com/mglaman/phpstan-drupal/releases/tag/1.1.24 the problems are gone.

spokje’s picture

Title: [PP-1 Upstream] Stop ignoring "Missing explicit access check on entity query." rule in core/phpstan-baseline.neon » Stop ignoring "Missing explicit access check on entity query." rule in core/phpstan-baseline.neon
StatusFileSize
new45.62 KB
spokje’s picture

StatusFileSize
new45.43 KB
new480 bytes
spokje’s picture

Assigned: Unassigned » spokje
Status: Needs review » Needs work
spokje’s picture

StatusFileSize
new4.32 KB
new47.97 KB
anchal_gupta’s picture

Status: Needs work » Needs review
StatusFileSize
new611 bytes
new48 KB

I have fixed CS error. Please review it

spokje’s picture

Status: Needs review » Needs work

@Anchal_gupta: Posting a patch on an issue that is assigned to somebody can be considered impolite by some people.

I am one of those people.

Please make sure the issue is either not assigned or of it is, make sure the issue has been stale for quite a while before posting a patch.

Also, the code changes don't make any sense.
More importantly: the patch doesn't pass. That in itself can happen, look at my own attempts in this issue.
However when I look at your recent posts, I see a lot of those CFF patches, which you never seem to follow-up with a fixed patch.
IMHO that's counterproductive to get an issue committed.
Please check if a patch passes, if not, don't walk away, but try to fix it in a follow-up patch.

spokje’s picture

StatusFileSize
new48.08 KB
new1.21 KB
spokje’s picture

Status: Needs work » Needs review
mondrake’s picture

Can we have a test-only patch, without the removal of the ignored pattern, to proof we do not have any lagger?

spokje’s picture

StatusFileSize
new47.5 KB
new495 bytes

Unsure what this will proof, but here you go

spokje’s picture

OK, now I see what can be proven... :)

mondrake’s picture

Status: Needs review » Reviewed & tested by the community

That proves that removing the ignore, there are no more errors like that reported. Thanks!

Patch in #10 is the one for commit.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/core/modules/migrate_drupal/src/Plugin/migrate/source/ContentEntity.php
    @@ -257,7 +257,7 @@ public function count($refresh = FALSE) {
    -    return $this->query()->count()->execute();
    +    return $this->query()->count()->accessCheck(TRUE)->execute();
    

    This is incorrect. This should be accessCheck(FALSE) - see \Drupal\migrate_drupal\Plugin\migrate\source\ContentEntity::query()

  2. +++ b/core/modules/node/node.module
    @@ -586,9 +586,9 @@ function node_cron() {
         $result = \Drupal::entityQueryAggregate('node')
    -      ->accessCheck(FALSE)
           ->aggregate('created', 'MIN', NULL, $min_alias)
           ->aggregate('created', 'MAX', NULL, $max_alias)
    +      ->accessCheck(FALSE)
    
    @@ -1093,8 +1094,7 @@ function node_access_rebuild($batch_mode = FALSE) {
    -      $entity_query->accessCheck(FALSE);
    -      $nids = $entity_query->execute();
    +      $nids = $entity_query->accessCheck(FALSE)->execute();
    

    These changes don't look great to me. They look like there are still problems with the rule.

alexpott’s picture

+++ b/core/lib/Drupal/Core/Menu/DefaultMenuLinkTreeManipulators.php
@@ -134,9 +134,9 @@ public function checkNodeAccess(array $tree) {
+      $access_check = TRUE;
 
       $query = $this->entityTypeManager->getStorage('node')->getQuery();
-      $query->accessCheck(TRUE);
       $query->condition('nid', $nids, 'IN');
 
       // Allows admins to view all nodes, by both disabling node_access
@@ -145,14 +145,14 @@ public function checkNodeAccess(array $tree) {

@@ -145,14 +145,14 @@ public function checkNodeAccess(array $tree) {
       // entries per user.
       $access_result = AccessResult::allowed()->cachePerPermissions();
       if ($this->account->hasPermission('bypass node access')) {
-        $query->accessCheck(FALSE);
+        $access_check = FALSE;
       }
       else {
         $access_result->addCacheContexts(['user.node_grants:view']);
         $query->condition('status', NodeInterface::PUBLISHED);
       }
 
-      $nids = $query->execute();
+      $nids = $query->accessCheck($access_check)->execute();

This also looks suspiciously like the rule is not correctly implemented. This change should not be necessary.

spokje’s picture

Assigned: spokje » Unassigned
spokje’s picture