False access-denied-link with some links of Taxonomies

The problem was in this part of the code in the class EntityRender:

  protected function setDataTargetFromRoute($target) {
    if (empty($target->getPath())) {
      return;
    }

    try {
      // @phpstan-ignore-next-line
      $route_match = \Drupal::service('router.no_access_checks')->match($target->getPath());
    }
    catch (\Exception $e) {
      $target->setSubcategory('broken-link');
      return;
    }

    // It is a view route.
    if (isset($route_match['view_id'])) {
      $target->setEntityType('view');
      $target->setEntityId($route_match['view_id'] . '.' . $route_match['display_id']);
      return;
    }

    // This case apply with entity canonical routes.
    $route_parts = explode('.', $route_match['_route']);
    if (count($route_parts) === 3 && $route_parts[0] === 'entity' && $route_parts[2] === 'canonical') {
      $entity_id = '';
      $entity = $route_parts[1];
      if (isset($route_match[$entity]) && $route_match[$entity] instanceof EntityInterface) {
        $entity_id = $route_match[$entity]->id();
      }
      $target->setEntityType($entity);
      $target->setEntityId((string) $entity_id);
    }
  }

The taxonomy term page is built using a view. For this reason, when the code detected that the view_id parameter was set in the $route_match variable, it handled the link as a view, without considering other parameters such as route_name.

When a taxonomy term had an alias, the entity was processed earlier, and this method was not called.

I have modified the code to be more precise in this aspect:

protected function setDataTargetFromRoute($target) {
    if (empty($target->getPath())) {
      return;
    }

    try {
      // @phpstan-ignore-next-line
      $route_match = \Drupal::service('router.no_access_checks')->match($target->getPath());
    }
    catch (\Exception $e) {
      $target->setSubcategory('broken-link');
      return;
    }

    if (empty($route_match['_route'])) {
      $target->setSubcategory('broken-link');
      return;
    }

    // @todo Maybe here is possible to get as well the entity object
    if (str_starts_with($route_match['_route'], 'view.')) {
      $target->setEntityType('view');
      $target->setEntityId($route_match['view_id'] . '.' . $route_match['display_id']);
      return;
    }

    // This case apply with entity canonical routes.
    $route_parts = explode('.', $route_match['_route']);
    if (count($route_parts) > 1) {
      $entity_id = '';
      $entity = $route_parts[1];
      if (isset($route_match[$entity]) && $route_match[$entity] instanceof EntityInterface) {
        $entity_id = $route_match[$entity]->id();
        $entity = $route_match[$entity]->getEntityTypeId();
      }
      $target->setEntityType($entity);
      $target->setEntityId((string) $entity_id);
    }
  }

It is ready to review and to merge. But I am not create unit test for this case. Maybe we can create a new issue to generate the unit tests.

Adding tests to cover it

I’m using this issue to introduce two minor changes:

• Restrict access to the ability to launch the Batch.
• Add the subcategory field and filter to the Entity Mesh view of nodes.

It works as expected.
I merge the issue.

After testing it with real data, I have found some use cases where the taxonomy terms are found as access-denied because a view is detected instead of the taxonomy term itself (see image)

lpeidro → changed the visibility of the branch 3512879-false-access-denied-link-with to hidden.

lpeidro → changed the visibility of the branch 3512879-false-access-denied-link-with to hidden.

There are many cases to manage. To avoid reducing the cases, a method has been implemented as the first one executed to detect whether the route corresponds to an entity route in the most flexible way possible, regardless of the entity type.

To achieve this, we use two criteria:

• The route name starts with "entity".
• There is a parameter of type entity converter.

Additionally, this parameter provides the key to retrieving the entity from the $route_match variable.

Ready for validation.

Merged!! Thank you

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