Unauthorized users able to to view unpublished translations

I can confirm that this still happens on 8.x-1.x-dev.

To recap, here are all the steps to reproduce:
- Install clean Drupal and Content Access module
- drush si -y && drush en admin_toolbar admin_toolbar_tools language content_access content_translation -y && drush uli
- Rebuild permissions due to Content Access installation (/admin/reports/status/rebuild)
- Add a new language for the site (/admin/config/regional/language)
- Allow translating the Article content type (/admin/structure/types/manage/article → Language settings → Enable translation)
- Create a new Article in the default language (EN) and leave it published
- Translate the Article in the newly created language (FI in this case) and don't publish it
- Access to both EN and FI pages now return 403 for anonymous user even though the EN page can be seen published on the edit form
- Edit the EN content and re-save it
- Both contents are now visible for anonymous users and the unpublished FI translation shows the red "unpublished" background on its content

Patch didn't apply cleanly against 8.x-1.x, so here's a reroll. This will now include the changes done in https://www.drupal.org/project/content_access/issues/3262813 → as well.

What happened before these changes:
When saving a node, access records were by default created for all translations, because the isPublished() check was done only for the content being saved (not the translations). This meant that saving the published EN content added allowing access record for FI (or any other translations) as well.

What should happen after the patch has been installed:
When saving a node, access records are only created for the translations that are published.

We'd still need to double-check that all this doesn't mess up things for other content access modules (like the quite popular View Unpublished → ).

We always fix the latest version.

Thanks @gisle, and thank you @iSampo for the clear replication steps and new patch.

I am going to be out of touch for a week or two, but if this hasn’t been wrapped up by the time I get back I will test your replication steps to see if I can reproduce the issue, then I can confirm/reroll the patch.

Would be cool to move out of alpha :)

Rerolled patch from comment #27 against HEAD.

The last submitted patch, 30: content_access-langcode-2897104-30.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Having another go at it.

Automatic tests pass. We also need manual reviews by community members.

I spent some time today testing the patch supplied by iSampo in comment #27 (after rerolling it for the HEAD of 2.0.x-dev – i.e. the patch in comment #32), it the results are very encouraging 😁.

I would like to see some more testing, but I plan to commit this to the repo soon.

It looks like it has been fixed. This has been committed to the latest snapshot of 2.0.x-dev.

THANK YOU!

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

Guys patch is fine, but it missed something. When node view is not for all users it appears that error on translation:
Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '689868-7-content_access_roles-es' for key 'node_access.PRIMARY': INSERT INTO "node_access"
To fix it content_access_get_type_grant function "$defaults" static variable should take in consideration node language. So this function should looks like:

/**
 * Returns the default grants for a given node type.
 */
function content_access_get_type_grant(NodeInterface $node) {
  // Cache per type default grants in a static array.
  static $defaults = [];

  $node_type = $node->getType();

  if (!isset($defaults[$node_type][$node->language()->getId()])) {
    $grants = [];

    // Only process the 'view' op as node_access() will take care of
    // edit and delete.
    foreach (content_access_get_settings('view', $node_type) as $rid) {
      $gid = content_access_get_role_gid($rid);
      $grant['grant_view'] = 1;
      $grants[] = content_access_proccess_grant($grant, $gid, $node);
    }
    $defaults[$node_type][$node->language()->getId()] = $grants;
  }

  // Care for the author grant.
  $grant = $grants = [];
  $settings = [
    'view' => content_access_get_settings('view', $node_type),
    'view_own' => content_access_get_settings('view_own', $node_type),
  ];
  $grant['grant_view'] = content_access_own_op($node, $settings['view'], $settings['view_own']);
  if ($grant['grant_view']) {
    $grant['realm'] = 'content_access_author';
    $grants = [
      'author' => content_access_proccess_grant($grant, $node->getOwnerId(), $node),
    ];
  }

  return $defaults[$node_type][$node->language()->getId()] + $grants;
}

Reopening, based on comment #39.

I posted Ion Macaria's patch based on his comment 39 in issue 3364261. Please review.

The fix for 🐛 Integrity constraint violation: 1062 Duplicate entry after upgrade module Fixed has recently been committed. Does this problem still exist?

@Liam Morland yeah, that's the exact same issue isn't it? So although @ion.macaria hasn't confirmed that it fixed their issue, given that the patch came from their suggested fix, I think we can be pretty sure it does.
Also, others tested and confirmed that 🐛 Integrity constraint violation: 1062 Duplicate entry after upgrade module Fixed was fixed etc.

Thus, I'm closing this ticket again.

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

For version 8.x