arturobernalg commented on PR #484:
URL: https://github.com/apache/jspwiki/pull/484#issuecomment-6545862103
Thanks for working on this. I ran the branch and measured how it behaves,
with a unit test that saves pages with ACLs and calls
AuthorizationManager.checkPermission for the guest session. RuleParserTest (5)
and DefaultAclManagerTest (6) pass. Three things I measured:
1. A rule for one action does not restrict the others. The guest session has
edit and comment allowed on a page with [{ALLOW view Admin OR Authenticated}]
and on one with [{ALLOW view NOT Anonymous}], the same as on a page without
ACL. With the classic [{ALLOW view Authenticated}] the guest has edit and
comment denied. In DefaultAuthorizationManager the new branch returns true when
the advanced ACL has no node for the requested action.
2. The same difference in the other direction: with [{ALLOW edit Admin AND
Editors}] the guest can still view and comment; with the classic [{ALLOW edit
Admin}] both are denied.
3. A page that has an advanced rule followed by a classic ALLOW line fails
to be saved: UnsupportedOperationException (Not supported yet.) from
AdvancedAcl.getAclEntry, called by DefaultAclManager.parseAcl line 141. I did
not measure the opposite order, a classic line first and then an advanced one.
Not measured: a user who is authenticated but not an administrator, because
all the users of the test engine end up with the Admin role. About the question
on the case of the operators: the rule is detected only when the line contains
AND, OR or NOT in upper case between blanks, while RuleParser matches the
operators ignoring the case, so [{ALLOW view Admin and Editors}] is read as a
classic rule (I read this in the code and did not run it).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
