On 03/14/2013 06:12 PM, Jerome Velociter wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
I'm not entirely sure what "no admin right by default" means. If default documents are not installed with PR then it's a great improvement but also a major break (we should have a vote for that specific rule change). If I cannot get PR to run groovy scripts on the wiki w/o enabling superadmin then -1. I think we can get a better idea of what this means by throwing together another rights service which tries both the new service and the old one and logs a warning if they disagree, running the functional tests with this information would tell us a lot more about how this behaves in practice. We can also collect hard performance data. Thanks, Caleb
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
Jérôme
- may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs