Problem/Motivation
The content_access module doesn't work out-of-the-box (for me). The problem appeared to be the default record set in the node_access table. This default record is set while installing the core node module.
db_insert('node_access')
->fields([
'nid' => 0,
'gid' => 0,
'realm' => 'all',
'grant_view' => 1,
'grant_update' => 0,
'grant_delete' => 0,
])
->execute();
It is also found in node/src/NodeGrantDatabaseStorage.php
public function writeDefault() {
$this->database->insert('node_access')
->fields([
'nid' => 0,
'realm' => 'all',
'gid' => 0,
'grant_view' => 1,
'grant_update' => 0,
'grant_delete' => 0,
])
->execute();
}
The node grants system always finds this default value when checking grants and this always results in an AccessResult::allowed(). It's impossible to deny access to nodes using content_access.
There is the possibility that I am using this module in a wrong manner but I have tried many permutations of permissions to try to get this module to work without deleting this default record, without any luck.
Steps to reproduce:
- Install Drupal and content_access.
- Create content type 'Custom page'.
- Create role 'Webmaster'.
- Allow users with role webmaster to view published content (permission).
- Setup 'Access control' of content type 'Custom page' to allow all roles to view nodes of this type.
- Enable the option to override the 'Access control' on individual nodes.
- Create new node 'testnode' of type 'Custom page'.
- Setup 'Access control' of 'testnode' to not allow users with the role 'Webmaster' to view this node.
Expected behaviour:
Users with the role 'Webmaster' can't view 'testnode' and get a 403 response.
Real behaviour:
Users with the role 'Webmaster' can view 'testnode'.
Proposed resolution
On install, check if the default record exists and delete it if it does. This will result in a restrictive setup. You have to setup the 'Access control' of all content types to grant usage. I am unsure if this is a good solution but this worked for me.
Remaining tasks
Discuss if the proposed solution is a decent solution.
User interface changes
None.
API changes
None.
Data model changes
None.
Comments
Comment #2
stefdewa commentedComment #3
gisleThis should go into the version compatible with Drupal 10.
Comment #4
steven jones commentedSo...Drupal core should be handling this for us:
When a module is installed, and has an implementation of a
node_grantshook, then it'll flag the node access records as needing rebuilding. You will then need to do this at some point, but when that happens, Drupal core will sort out the default node access record as appropriate, and we'd be wise to not second-guess that system.So I think that when you install content access core will notice, and flag that node access records need rebuilding.
However, content access also tries to be a bit too clever I think, and when making changes to the settings for content access, it tries to work out if there are <= 1000 nodes that would be affected, and if so, it recomputes the node access records, and sets the rebuild flag to FALSE. But it doesn't delete the default record. Pain.
Reckon this would be pretty easy to set up a test for, but I don't know if this is going to be particularly easy to fix without not bothering to attempt to rebuild the node access records, which might be the right approach tbh. I sort of can't imagine that many people are changing these settings on a live site.