How to deny access to a published node, if access isn't given by reference?

Created on 4 April 2023, about 1 year ago
Updated 30 November 2023, 7 months ago

Problem/Motivation

I have a published node which should only be accessible for referenced users, but with or without "Access By Reference" permision given to all roles incl. anonymous, the node is always visible to all users (incl. anonymous) and I don't yet understand how to deny access by default?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

πŸ’¬ Support request
Status

Active

Version

3.0

Component

Documentation

Created by

πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @Anybody
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Wrong issue

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Having a look at these lines:

    function access_by_ref_node_access(NodeInterface $node, $op, AccountInterface $account) {
        // Perform basic access checks
        if(
            !isset($account) || $op == 'create' || $account->id() == 0 || !isset($node) || !$account->hasPermission('access node by reference')
        ) {
            return AccessResult::neutral();
        }
    

    it seems this module is never able to deny access for anonymous users, I guess?

  • πŸ‡³πŸ‡±Netherlands Marceldeb

    Hello Anybody,

    I think you are partly right. In the use case you are describing you have to make sure you have your permissions set up correctly.

    So, let's say the content type of your special page you want to display only to specific users is called 'special_content_type'.

    Then you should not give permission to anonymous users to view this kind of nodes. This is Drupal native functionality in core/permissions administration screen. Because if you give access to anonymous users to view your 'special_content_type' this wil (obviously) interfer with this module. By setting this permission, all anonymous users will be indeed allowed to access the node. That's how the Drupal permission screen works. So to solve your case you do not set the permission for the anonymous user to view your 'special_content_type' in the Drupal permission administration screen.

    You only configure this module to give access when a user is referenced in the specific node. Job done!

    I'm not sure why you would want to give access to anonymous users using this specific module? This use case is indeed not supported. I also don't see a valid use case for that?

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Hi @Marceldeb and thanks a lot for your feedback and taking the time!

    My real use-case was a lot more complicated, as it was using media and private fields. I tried to break it down here, while I didn't fully understand this modules logic yet. Having a look at the code mentioned in #3 things became more clear, also because of the side-effects of πŸ› Clarify "Access By Reference" permission description Fixed .

    But the focus here, and I think this is what eventually should be documented is:

    This module can't be used to deny access!

    That's important to know, because combined with the widely spread core "logic" of missing separated bundle view permissions, all published nodes are always accessible.

    It's some weeks ago, so I hope I don't mix up things here!

    In the end we decided to create https://www.drupal.org/project/entity_access_by_reference_field β†’ which uses a more explicit logic and settings and which is configured in the reference fields settings. We liked that way this worked in Drupal 7 days with https://www.drupal.org/project/nodeaccess_userreference β†’ and https://www.drupal.org/project/nodeaccess_nodereference β†’

    Which absolutely shouldn't mean access_by_ref is bad, it just wasn't totally what we were expecting and as we already wrote https://www.drupal.org/project/entity_access_by_role_field β†’ in the past, we had the basis for that implementation.
    So I think both are good alternatives for different use-cases and indivudal preferences.

    Hopefully some of the points I mentioned here can be useful to improve the documentation and SBX. Perhaps I'm not the only one getting things wrong when starting.

    So finally let me say thank you for this great work and taking the time to look through the issues! :)

  • πŸ‡³πŸ‡±Netherlands Marceldeb

    Hi,

    Thanks for you elaboration and I'm leaving this open until I've updated the readme / project description a bit more. I understand what you mean.

    I'm used to having the https://www.drupal.org/project/node_view_permissions β†’ module also active. This modules work great together with access_by_ref. By using node_view_permissions you can solve the missing separated bundle view permissions you are talking about. And then you can solve the situation that all published nodes are always accessible because of permissions.

    I actually forgot you need a separate module for that :-D

  • πŸ‡³πŸ‡±Netherlands Marceldeb
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    @Marceldeb: Thanks! That's exactly the point :)

  • Thank you @Marceldeb, #6 resolved that issue.

    @Anybody - does your module entity_access_by_reference_field fix this issue without need of installation 2 separated modules ?

  • @Marceldeb I used node_view_permission as you suggested. Now my role doesnt have ability to see Node. Once I visit node - Access denied. Now when I use this module to configure that it compares value with profile it works and I can see the node on direct link.
    However i am unable to see data in views even it is reachable with direct link. Any idea how to fix that issue with views?

  • It seems this is a core related issue and fix here helped 1349080 πŸ› node_access filters out accessible nodes when node is left joined Needs work

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    @Anybody - does your module entity_access_by_reference_field fix this issue without need of installation 2 separated modules ?

    Yes, I think so. Otherwise please correct me here.

  • πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

    We have a use case for giving access to anonymous users. Some content should be viewable by specific users, and some should be viewable by all users. It makes sense for the method of granting permission to be the same: the user entity reference field, where you can indeed select "John (123)" or "Visitor (0)" (we renamed anonymous user to Visitor). It seems Access By Ref should support this.

Production build 0.69.0 2024