14 Mar
2013
14 Mar
'13
11:28 p.m.
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 <dgl(a)softec.lu> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
- 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