Repository navigation
[Bug] Clear cached permission definitions on cache:clear - #2067
Conversation
UserPermissionVoter caches the list of permission keys in the Pimcore cache without lifetime or tags. Permissions created later by a bundle installer (e.g. plugin_datahub_config) were therefore never supported by the voter, so every IsGranted() on them was denied - even for admins - until pimcore:cache:clear. Symfony's cache:clear (also run after pimcore:bundle:install) does not touch the Pimcore cache pool. Register a kernel.cache_clearer that drops the cached list. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot review overview
🔵 Needs a closer look
The implementation is sound, but permission authorization behavior warrants final maintainer security review.
Review effort: Balanced
Findings: None
What changed in this PR
Clears stale permission-definition caches during Symfony cache:clear, allowing newly installed bundle permissions to be recognized (src/Security/CacheClearer/UserPermissionCacheClearer.php:34-36).
Changes:
- Adds an internal cache clearer and registers it with
kernel.cache_clearer(config/security.yaml:16-18). - Adds a unit test verifying removal of the permission cache key (
tests/Unit/Security/CacheClearer/UserPermissionCacheClearerTest.php:26-33). - Correctly addresses bundle-install cache clearing, though runtime permission additions remain outside its scope.
The change is appropriately placed, introduces no public API break, and covers all uses of the shared permission cache key. No blocking defects were identified.
| File | Description |
|---|---|
src/Security/CacheClearer/UserPermissionCacheClearer.php |
Removes cached permission definitions during cache clearing. |
config/security.yaml |
Registers the new Symfony cache clearer. |
tests/Unit/Security/CacheClearer/UserPermissionCacheClearerTest.php |
Tests permission-cache invalidation. |
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Problem
After installing a bundle that adds a permission (e.g.
pimcore/data-hub+pimcore/data-hub-simple-rest), Studio endpoints guarded by that permission return 403 Access Denied — even for admins — untilpimcore:cache:clearis run.Root cause
UserPermissionVotercaches all keys ofusers_permission_definitionsunderstudio_backend_user_permissionsin the Pimcore cache (no lifetime, no tags) and onlysupports()attributes in that list. A permission created after the list was cached (e.g.plugin_datahub_configfrom the data-hub installer) is supported by no voter, so every#[IsGranted(...)]on it is denied.Symfony's
cache:clear— whichpimcore:bundle:installruns after every install — does not touch the Pimcore cache pool, so the stale list survived. Only saving a user (UserUpdateService) orpimcore:cache:clearrefreshed it.Fix
Register a
kernel.cache_clearer(UserPermissionCacheClearer) that removes the cached list oncache:clear. The bundle-install flow now picks up new permissions; the per-request path of the voter is unchanged.Verification
Reproduced on a local demo-enterprise install as admin,
GET /pimcore-studio/api/bundle/data-hub/config:Definition::create('plugin_datahub_config')->save()(as the installer does) →cache:clearUnit test added; PHPStan and php-cs-fixer clean.
Known limitation
Permissions added at runtime without a subsequent
cache:clear(e.g. raw-SQL migrations run without a cache clear) are still not picked up until the next cache clear / user save. Closing that would need a cache tag invalidated in core'sPermission\Definitionsave.🤖 Generated with Claude Code