- Issue created by @geek-merlin
Drupal's Entity Access aggregates access like this (in symfony language):
- the EntityAccessControlleHandler collects and aggregates the results
- it has on vote itself
- more hook_access votes are collected
- the results are aggregated wrt 3-state logic "strategy" (allowed if any allowed and no forbidden)
The 3-state Drupalism has big issues in itself:
- it is hard to get right, even senior developers fail (
SA-CONTRIB-2023-054 →
,
🐛
Creating two relationships breaks access
Active
, ...)
- it has limited expressiveness (i remember a project that wanted to marry group and domain access, which needed to swap out a lot of code)
And the whole system has a lot of issues more:
- the access votes have no names
- access votes are often aggregated already, with no way for the aggregation to tell the parts apart
Work towards an AccessAggregationApi that has these properties:
- (Like today) The EntityAccessControlleHandler collects votes from the controller itself and all hook_access implementations
- The hook_access AccessResult return values have more metadata than today
- a name and named sub-votes
- the sub-votes have a default role ("allowing", "forbidding" like today) and a priority (new)
- Optionally, the votes can be lazy
That way,
- EntityAccessControlleHandler is always in charge of overriding the access aggregation. (Marrying group and domain access is no longer a nightmare.)
- There is a smooth upgrade path from current system to modern, expressive access aggregation.
Relation to Unifying single and query access:
-
✨
Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter()
Needs work
discusses the idea of unifying single-entity and entity-query access by adding a field condition abstraction that is php-evaluated for single-entity access, and compiles to query conditions for entity queries (and was pioneered in
Entity API →
and in an advanced form
Entity Unified Access →
).
- In comment
#777578-256: Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() →
ff some problems with unifying access were stated, that should be solved or mitigated by a central aggregator, not trying to aggregate within access alterers.
- Which suggests poptponing the other issue on this.
Discuss, implement.
None.
Access aggregation.
Access aggregation api.
None.
Drupal has an access aggregation API.
Active
11.1 🔥
entity system
Enhances developer experience.
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.