implementing hook_access for cck content types

implementing hook_access for cck content types
posted october 28th, 2007 by cailin
in

* cck
* drupal
* tech

previously, we discussed implementing all of the node hooks for CCK content types except hook_access. unfortunately, there is no access op for hook_nodeapi. adding this to drupal core is the topic of much discussion on drupal.org. so far a resolution to the issue has failed to be included in drupal 5 and drupal 6, and is now on deck for consideration in drupal 7.

this is a complicated issue, and the experts are debating with good cause. in the meantime though, if you need to move on, here's what you can do.

* install this patch to node.module
* you now have an access op exposed in hook_nodeapi

one reason that the debate is dragging on on this topic, is that the drupal developers are concerned that access control is already too complicated, and this addition will simply make drupal access control incomprehensible. this is a valid point, and to use this patch properly you do need to understand the access control order of evaluation. when determining whether or node a user may view a node, here are the questions drupal asks

1. does the user have 'administer nodes' permission. if yes, always return true
2. does the user have 'access content' permission. if no, always return false
3. invoke the new hook_nodeapi methods.
1. if no hook_nodeapi returned an explicit opinion on the matter, keep going.
2. otherwise, if any hook_nodeapi returned true, return true
4. invoke the hook_access method, if any. (note, there may be only one of these!)
1. if no hook_nodeapi returned an explicit opinion, keep going
2. if an opinion was returned, return that
5. now check was the node_access table has to say. if no opinion, keep going
6. is the user the author of the node? if yes, return true
7. give up, return false

phew, that's a complicated flow of execution. are there any easy guidelines we can draw from this? yes . . .

one downside of granting access control to hook_nodeapi is that there may now be multiple modules with an opinion on the matter. this forces the drupal core developer to make a choice as to what to do when there are multiple, conflicting answers. in this patch, they have chosen to allow positive responses to dominate over negative responses. i'm personally not convinced they will stick with this decision, so, in the meantime, if you're using this patch, try and stick to a convention in which you implement only one hook_nodeapi access control method per content type. in doing this, you're simply allowing your CCK content types to function like any other content type, rather than opening a huge kettle of access control worms.