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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
