[1.0.x] Access By Taxonomy

Thank you for applying!

Please read Review process for security advisory coverage: What to expect → for more details and Security advisory coverage application checklist → to understand what reviewers look for. Tips for ensuring a smooth review → gives some hints for a smoother review.

The important notes are the following.

• If you have not done it yet, you should run phpcs --standard=Drupal,DrupalPractice on the project, which alone fixes most of what reviewers would report.
• For the time this application is open, only your commits are allowed.
• The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status won't be changed by this application and no other user will be able to opt projects into security advisory policy.
• We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.

To the reviewers

Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .

The important notes are the following.

• It is preferable to wait for a Code Review Administrator before commenting on newly created applications. Code Review Administrators will do some preliminary checks that are necessary before any change on the project files is suggested.
• Reviewers should show the output of a CLI tool → only once per application.
• It may be best to have the applicant fix things before further review.

For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .

1. FILE: README.md

The module uses a README.md file instead of a README.txt file. While the Drupal coding standards have not been yet updated about that, the Drupal.org community consider that positive.
Since there is a README.md file, that should follow the content and formatting described in README.md template → .

2. FILE: access_by_taxonomy.info.yml

core_version_requirement: ^8 || ^9 || ^10

The Drupal Core versions before 8.7.7 do not recognize the core_version_requirement → key.

3. FILE: access_by_taxonomy.module

/**
 * @file
 * Contains the implementation of hooks for node access control.
 */

The usual description for a .module file is Hook implementations for the [module name] module. where [module name] is the module name given in the .info.yml file.

/**
 * Implements hook_form_FORM_ID_alter().
 */
function access_by_taxonomy_form_node_form_alter(&$form, FormStateInterface $formState, $_form_id) {

/**
 * Implements hook_form_FORM_ID_alter().
 */
function access_by_taxonomy_form_taxonomy_term_form_alter(&$form, FormStateInterface $formState, $form_id) {

The description for that hook should also say for which form that hook is implemented, either by indicating that with the name of the class that implements the form (namespace included) or the form ID (which is usually indicated by getFormId()).

4. FILE: src/AccessByTaxonomyPermissions.php

  /**
   * AccessByTaxonomyPermissions constructor.
   *
   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
   *   The entity type manager service.
   */
  public function __construct(EntityTypeManagerInterface $entity_type_manager) {

FILE: src/NodeAccessService.php

  /**
   * RoleGrants service constructor.
   *
   * @param \Drupal\access_by_taxonomy\AccessByTaxonomyService $accessByTaxonomyService
   *   The Access by Taxonomy service.
   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
   *   The entity type manager service.
   * @param \Drupal\Core\Database\Connection $database
   *   The database connection.
   * @param \Drupal\node\NodeGrantDatabaseStorage $grantStorage
   *   The node grant storage service.
   * @param \Drupal\Core\Logger\LoggerChannel $loggerChannel
   *   The logger factory service.
 */
  final public function __construct(AccessByTaxonomyService $accessByTaxonomyService, EntityTypeManagerInterface $entity_type_manager, Connection $database, NodeGrantDatabaseStorage $grantStorage, LoggerChannel $loggerChannel) {

The documentation comment for constructors is not mandatory anymore, If it is given, the description must be Constructs a new [class name] object. where [class name] includes the class namespace.

Thank you very much. Code updated.

I forgot to mention: if you go to our project code: https://git.drupalcode.org/project/access_by_taxonomy you'll see we have pipelines enabled, and everything is green.

Rest seems fine to me.

Let’s wait for other reviewers and Code Review Administrator to take a look and if everything goes fine, you will get the role.

Thank you very much! :) let's hope!

• The following points are just a start and don't necessarily encompass all the changes that may be necessary
• A specific point may just be an example and may apply in other places
• A review is about code that does not follow the coding standards, contains possible security issues, or does not correctly use the Drupal API; the single points are not ordered, not even by importance

src/AccessByTaxonomyService.php

    catch (\Exception $e) {
      $this->loggerChannelAccessByTaxonomy->error($e->getMessage());
      return [];

The first argument for logger methods that log a message is a literal string. Passing a dynamic string is considered a security issue.

$term = Term::load($tid);

It is probably better to use the entity storage to load the taxonomy term, like already done from the code for other entities.

      $msg[40] = t('Author, %name can access this content if they have the %permission permission', [
        '%name' => $author,
        '%permission' => 'view own unpublished content',
      ]);

Since the class injected the translation manager, it should use that to get a translatable string instead of t().

    if ($num_deleted > 0) {
      $this->loggerChannelAccessByTaxonomy->info('Deleted :num rows from node_access table after deletion or role :role', [
        ':num' => $num_deleted,
        ':role' => $roleId,
      ]);
    }

Placeholders starting with a colon are for values that need to be filtered for dangerous protocols; that is not the case for numbers and entity IDs, which are supposed to be numbers.

Thank you very much for your review.

https://git.drupalcode.org/issue/access_by_taxonomy-3469105

i had already created this fork for working on the security fixes, so i went on on that. We'll merge that to the main branch soon.

I tackled all your points. Indeed many of them recurred in many places, but luckily our codebase is not too big to go through.

I am changing priority as per Issue priorities → .

I'm seeing a few issues, mostly pretty minor:

In tests/src/FunctionalJavascript/FormAjaxTest.php, line 77:

    $field_storage = FieldStorageConfig::create([

This creates the storage for the field_tags field, but is never used again. There is no need to assign to the variable, you can just call FieldStorageConfig::create() as a method without assigning the result.

On line 209 of the same file:

    $txt = $page->find('css', 'tbody tr:first-child .diff-addedline .diffchanged')->getText();

Normally I would expect this to be followed by assertEquals to check the expected text is in the element, but you don't do this, and the $txt variable is never used. If you just want to check the element exists on the page, you could change this to $this->assertSession()->elementExists().

The next problem I've found is in /src/NodeAccessService.php on line 127:

      'title' => t('Updating content access permissions'),

This should use $this->t(). I see you're using StringTranslationTrait in the class, which enables this but not actually availing of it.

I note line 174 of the same file also uses t(), but that's in a static function, where the $this variable isn't initialised, so it's correct.

However, there are several static functions in this class, which leads me to wonder is this the best place for them, since they can't use injected dependencies. I wonder would it make sense to move some or all of them into a separate service?

I also note that this module doesn't currently have a Drupal 11 version. I don't think that's a reason it shouldn't opt in to the security policy, but it would definitely be a disincentive for people considering this module. Adding support for D11 shouldn't be difficult.

Thank you! Fixed those issues and also did the jump to d11.

That service that has static methods in it is mostly used for batch processing and so on, so i don't think it would make sense splitting it.