14 Mar
2013
14 Mar
'13
11:55 p.m.
On 03/14/2013 06:49 PM, Denis Gervalle wrote:
On Thu, Mar 14, 2013 at 11:28 PM, Caleb James DeLisle
<
calebdelisle(a)lavabit.com> wrote:
Indeed we can't pass over every possibility but if we can run the functional
tests and have a good explanation for each discrepancy then the change is
pretty safe. Users who tread off the common path are used to bugs because
all software has little testing of uncommon codepaths.
Tentative +1 but I still really want to see some numbers :)
Thanks,
Caleb
On 03/14/2013 06:12 PM, Jerome Velociter wrote:
No, you get it wrong. It simply means, that if the admin right is not
explicitly allowed, it is denied by default. The most important consequence
is for an empty DB, since you do not receive admin rights when your are a
"null" user. (Even more, a "null" user never receive rights)
This is not so serious since now we have the DW that reach PR right in its
own way, and is able to deploy a wiki. Only power user that are skipping
the DW and wanting to import a XAR will need to login as superadmin to do
so.
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.
Setting up this dual RightService is easy, making it pass over all possible
situation if really harder.
Please note that, while I propose to change the default, this does not
prevent a user to configure back the old RightService.
Note also, that both services could be used side-by-side, so that new
component using the new right service, may work in that configuration.
IMO, if we never decide to go forward, we have no chance to discover and
improve the new service. It was there during the whole 4.x cycle, and very
few committers look at it. A new major version release is therefore the
ideal time to go on. We can justify some breakage, and we may fix them
during the 5.x cycle.
Thanks,
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs