Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This is an idea we've been kicking around at both NYC Camp and Midwest Drupal Summit.
It would be much cleaner -- and force us to properly abstract our code -- if we moved node access functions (specifically, hook_query_node_access_alter) into a separate module. Once we do that, it should also become easier to handle expanding access control support to entities.
It also means that we don't install node_access() by default and can stop running those joins for 95% of all Drupal sites.
I would advocate for calling the new module "access_control".
Comments
Comment #1
wjaspers CreditAttribution: wjaspers commentedI think this is the pseudo-purpose of the ACL module; but core's access API is outdated--since it was originally built around nodes. Could we go one-step further and make a better generic access control system? For instance, user_access() isn't alterable.
Or--maybe I've misunderstood the issue at hand.
Comment #2
agentrickardThat is not what this issue is about.
Comment #3
sunI think that the natural outcome of the current entity system + generalized entity access efforts will result in an abstracted Entity Access API already.
Whether that needs to live in an own entity_access module... I'm not sure. I'd rather consider that to be part of the entity system (and hence, entity module).
Once abstracted, I guess that most details of the current (node) access behavior can be specified (as in opted-in/-out) via hook_entity_info(). Such details could be:
- enabled: TRUE/FALSE
- per-bundle: TRUE/FALSE
- per-user: TRUE/FALSE
This is the wrong issue to discuss that; just mentioning what I'd generally expect from an abstracted entity access API. I think that the access concept needs to be part of the entity system, not a separate module that is tacked onto it.
In a sense, I'd rather map entity access to plugins than to a module.
Comment #4
agentrickardI can see that. If we didn't move to a plugin model and had to limp along with node access as it is now, I would like to move to a new module, simply for clarity of code and support. Why enable the overhead of node access when most sites never use it.
Do we have any architecture plans for entity access yet?
Comment #5
fagoI've posted some thoughts on that in #1696660: Add an entity access API for single entity access. That said, I do think we want to move node_access / entity_access to work plugin/controller-based, so you can easily swap out or customize implementations.
Thus, a good step forward would be moving node access to a plugin class.
Comment #6
fagoAs noted in #1696660: Add an entity access API for single entity access I thought about caring a query-less solution over there. Still, I think the query alterations belong into the same plugin. So we can have a simple base implementation without the node grants system, and another more sophisticated one which implements grants/whatever.
Also, the more sophisticated ones as node-access are probably tied to a certain entity storage?
Comment #7
agentrickardOK, then should we move this discussion to that ticket. I think so. If that initiative fails, we can revisit this one.