- First commit to issue fork.
Because Field access is "Allowed" by default, if an access check is made against a Field specifying an unrecognized "operation", the access check result is AccessResult::allowed(). This has a great potential for producing security issues when Contrib modules perform access checks, for example, due to typos, or using "update" (which is valid for Entity access checks) instead of "edit".
In \Drupal\Core\Entity\EntityAccessControlHandler::fieldAccess(), perform a php assert() against:
1. The operation being one of "view" or "edit", or
2. The operation is recognized in any module's hook_field_entity_access() or hook_field_entity_access_alter(). A "recognized" operation is determined by the hook returning, or the alter setting a grant other than :default to, an AccessResult other than "Neutral".
None
Contrib modules passing invalid access check operations may need to be updated to use the correct field access operation in order to eliminate the new watchdog warnings and automated test failures caused by the assert(). Existing access behavior, itself, will be unaffected.
None
Needs work
11.0 🔥
field 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.
Used to track the progress of issues reviewed by the Drupal Needs Review Queue Initiative.
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.