Details
-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
12.10.8
-
None
-
Unknown
-
Description
Disclaimer: maybe it's a feature and not a bug...
Reproduction steps:
- Create a new custom right, whose DescriptionRight follow this scheme:
@Override public String getName() { return "something"; } @Override public RuleState getDefaultState() { return RuleState.ALLOW; } @Override public RuleState getTieResolutionPolicy() { return RuleState.DENY; } @Override public boolean getInheritanceOverridePolicy() { return true; } @Override public Set<Right> getImpliedRights() { return Collections.emptySet(); } @Override public Set<EntityType> getTargetedEntityType() { return Collections.singleton(EntityType.DOCUMENT); } @Override public boolean isReadOnly() { return false; }
- create a new user and new page in the wiki
- go to Administration > Extension Rights and forbid this new right to the new user
- on a new page, check access of the new right and the new user on several pages, by creating a new page with the following code:
{{velocity}} $services.security.authorization.hasAccess('something', 'newUser', 'NewPage.WebHome') {{/velocity}}
Expected result:
- the hasAccess call should returns false, since the right is explictely denied for the new user at wiki level and there's no right put on the new page to override it
Obtained result:
- the hasAccess call always return true, on all documents.
After debugging a bit, the reason is that because the getTargetedEntityType method returns only DOCUMENT entity type, the settings at wiki level are apparently not taken into account at all. I'm not sure I understand such restriction: it would make much more sense for me if the targetedEntityType was used for checking the right (i.e. you cannot check this right against a wiki since it's not a targeted type, so in that case it should returns always a deny), but not for setting it (i.e you should always be able to set the right at any level).