- Issue created by @Anybody
- π©πͺ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
- π©πͺGermany Anybody Porta Westfalica
@Marceldeb: Thanks! That's exactly the point :)
- πΈπ°Slovakia coaston
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 ?
- πΈπ°Slovakia coaston
@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? - πΈπ°Slovakia coaston
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.