14 Mar
2013
14 Mar
'13
9:20 p.m.
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
- 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.
- 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
14 Mar
14 Mar
10:59 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
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.
- 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
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
11:12 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
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:
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
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. - 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
11:28 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
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
11:49 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Thu, Mar 14, 2013 at 11:28 PM, Caleb James DeLisle <
calebdelisle(a)lavabit.com> wrote:
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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
11:55 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
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
11:38 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <jerome(a)velociter.fr>wrote;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:
You have got it right. This could be improved, and help is welcome. What
happen is that the user groups are evaluated independently to the targeted
entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like
those. The simple display in admin of Global user in local Group is even
broken (double xwiki:xwiki:...) so this does not seems to me a common usage.
You may provide access to global group in a local wiki to achieve the same
goals.
Hi 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 ?
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.
Jérôme
- may exhibit some other minor differences compare to existing
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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
15 Mar
15 Mar
3:12 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
2013/3/14 Denis Gervalle <dgl(a)softec.lu>
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<
http://lists.xwiki.org/mailman/listinfo/devs>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter
<jerome(a)velociter.fr
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 ?
You have got it right. This could be improved, and help is welcome. What
happen is that the user groups are evaluated independently to the targeted
entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like
those. The simple display in admin of Global user in local Group is even
broken (double xwiki:xwiki:...) so this does not seems to me a common
usage.
You may provide access to global group in a local wiki to achieve the same
goals.
This looks to be indeed a big regression. It's quite a common use case to
have only global users and to create groups in the local wiki that refer to
local users.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I think even Workspaces is using that so XEM by default would fail with
this.
Ludovic
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.
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
10:33 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
2013/3/14 Denis Gervalle <dgl(a)softec.lu>
to
You have got it right. This could be improved, and help is welcome. What
happen is that the user groups are evaluated independently to the targeted
^^^^^^^^
I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these
same individual users grouped by another one (local admin) is very uncommon
delegation of authority to me (but I may be wrong). On the other hand,
having a local admin providing access to local ressources to global group
(and potentially some global users) makes more sense. In that way, the same
admin manage its users, and group its users, and the local admin trust the
global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a
common use case (moreover used by workspace), we should obviously support
it. However, I am convince that evaluating groups based on both the user
and the targeted entity is not easily achievable and conduct to very
complex partial caching.
I have currently not implemented in the security module anything that would
cause all wikis to be scanned, and I would really like to avoid that to
happen. So, it will be difficult to avoid partial caching, but we need to
limit that at the higher level, the subwiki. This would allow to had only
scan both the wiki of the user and the target entry to consider our cache
valid. It means subwiki will be unable to share groups (I do not think this
has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
On Thu, Mar 14, 2013 at 11:12 PM, Jerome
Velociter <jerome(a)velociter.fr
wrote:
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> >>
>> 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 >>> 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.
>
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 ?
entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like
those. The simple display in admin of Global user in local Group is even
broken (double xwiki:xwiki:...) so this does not seems to me a common
usage.
You may provide access to global group in a local wiki to achieve the
same
goals.
This looks to be indeed a big regression. It's quite a common use case to
have only global users and to create groups in the local wiki that refer to
local users.
plenty of projects for which migration to 5.0 would be
almost impossible
I will need helps to achieve that for 5.0
> This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be
almost impossible
> I think even Workspaces is using that so XEM by default would fail with
> this.
>
> Ludovic
>
> >
> > >
> > > 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<
> > http://lists.xwiki.org/mailman/listinfo/devs>
> > >
> >
> >
> >
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > eGuilde sarl - CTO
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
10:47 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
ok so before changing anything we need a plan i.e. someone volunteering to work on this,
right?
Thanks
-Vincent
2013/3/14 Denis Gervalle <dgl(a)softec.lu>
to
targeted
^^^^^^^^
I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these
same individual users grouped by another one (local admin) is very uncommon
delegation of authority to me (but I may be wrong). On the other hand,
having a local admin providing access to local ressources to global group
(and potentially some global users) makes more sense. In that way, the same
admin manage its users, and group its users, and the local admin trust the
global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a
common use case (moreover used by workspace), we should obviously support
it. However, I am convince that evaluating groups based on both the user
and the targeted entity is not easily achievable and conduct to very
complex partial caching.
I have currently not implemented in the security module anything that would
cause all wikis to be scanned, and I would really like to avoid that to
happen. So, it will be difficult to avoid partial caching, but we need to
limit that at the higher level, the subwiki. This would allow to had only
scan both the wiki of the user and the target entry to consider our cache
valid. It means subwiki will be unable to share groups (I do not think this
has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
On Thu, Mar 14, 2013 at 11:12 PM, Jerome
Velociter <jerome(a)velociter.fr
wrote:
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> >>
>> 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 >>> 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.
>>
>
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 ?
You have got it right. This could be improved, and help is welcome. What
happen is that the user groups are evaluated independently to the entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like
those. The simple display in admin of Global user in local Group is even
broken (double xwiki:xwiki:...) so this does not seems to me a common
usage.
You may provide access to global group in a local wiki to achieve the
same
goals.
This looks to be indeed a big regression. It's quite a common use case to
have only global users and to create groups in the local wiki that refer to
local users.
plenty of projects for which migration to 5.0
would be almost impossible
I will need helps to achieve that for 5.0 > This would really need to be fixed sooner than
later otherwise I know
> plenty of projects for which migration to 5.0 would be almost impossible
>
> I think even Workspaces is using that so XEM by default would fail with
> this.
>
> Ludovic
>
>>
>>>
>>> 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 ?
10:50 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
uncommon
Do we really need that for 5.0 ?
Using the new module as a default does not means the old right service is
unavailable. Couldn't we simply define which case needs to revert to the
old modules in the RN, and have 5.0 without this feature ? We may even
release XEM without it if workspace need so.
WDYT ?
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com>
wrote:
> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>
>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
jerome(a)velociter.fr
>>> 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.
>>>>>
>>>>
>>> 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
?
>>>
>>
>> You have got it right. This could be improved, and help is welcome.
What
>> happen is that the user groups are
evaluated independently to the
> targeted
>> entity, and therefore only in the user wiki.
>>
>> I admit this is a regression, but I have not cross lots of use case
like
>> those. The simple display in admin of
Global user in local Group is
even
>> broken (double xwiki:xwiki:...) so this
does not seems to me a common
>> usage.
>> You may provide access to global group in a local wiki to achieve the
> same
>> goals.
>>
>>
> This looks to be indeed a big regression. It's quite a common use case
to
> have only global users and to create groups
in the local wiki that
refer to
local
users.
^^^^^^^^
I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these
same individual users grouped by another one (local admin) is very delegation of authority to me (but I may be
wrong). On the other hand,
having a local admin providing access to local ressources to global group
(and potentially some global users) makes more sense. In that way, the
same
admin manage its users, and group its users, and
the local admin trust
the
global admin to know its users.
That said, I am not against any improvement on the way it works, if it
is a
common use case (moreover used by workspace), we
should obviously support
it. However, I am convince that evaluating groups based on both the user
and the targeted entity is not easily achievable and conduct to very
complex partial caching.
I have currently not implemented in the security module anything that
would
cause all wikis to be scanned, and I would really
like to avoid that to
happen. So, it will be difficult to avoid partial caching, but we need to
limit that at the higher level, the subwiki. This would allow to had only
scan both the wiki of the user and the target entry to consider our cache
valid. It means subwiki will be unable to share groups (I do not think
this
has ever worked), but it will keep performance on
large farm.
This would really need to be fixed sooner than later otherwise I know
ok so before changing anything we need a plan i.e. someone volunteering to
work on this, right?
plenty of projects for which migration to 5.0
would be almost impossible
I will need helps to achieve that for 5.0
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
> This would really need to be fixed sooner
than later otherwise I know
> plenty of projects for which migration to 5.0 would be almost impossible
>
> I think even Workspaces is using that so XEM by default would fail with
> this.
>
> Ludovic
>
>>
>>>
>>> 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 ?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:57 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol
<vincent(a)massol.net> wrote:
I thought the config change you were proposing was global… I'm lost…
Thanks
-Vincent
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
uncommon
Do we really need that for 5.0 ?
Using the new module as a default does not means the old right service is
unavailable. Couldn't we simply define which case needs to revert to the
old modules in the RN, and have 5.0 without this feature ? We may even
release XEM without it if workspace need so. On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com>
wrote:
> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>
>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
jerome(a)velociter.fr
>>> 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.
>>>>>
>>>>
>>> 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
?
>>>
>>
>> You have got it right. This could be improved, and help is welcome.
What
>> happen is that the user groups are
evaluated independently to the
> targeted
>> entity, and therefore only in the user wiki.
>>
>> I admit this is a regression, but I have not cross lots of use case
like
>> those. The simple display in admin of
Global user in local Group is
even
>> broken (double xwiki:xwiki:...) so this
does not seems to me a common
>> usage.
>> You may provide access to global group in a local wiki to achieve the
> same
>> goals.
>>
>>
> This looks to be indeed a big regression. It's quite a common use case
to
> have only global users and to create groups
in the local wiki that
refer to
local
users.
^^^^^^^^
I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these
same individual users grouped by another one (local admin) is very delegation of authority to me (but I may be
wrong). On the other hand,
having a local admin providing access to local ressources to global group
(and potentially some global users) makes more sense. In that way, the
same
admin manage its users, and group its users, and
the local admin trust
the
global admin to know its users.
That said, I am not against any improvement on the way it works, if it
is a
common use case (moreover used by workspace), we
should obviously support
it. However, I am convince that evaluating groups based on both the user
and the targeted entity is not easily achievable and conduct to very
complex partial caching.
I have currently not implemented in the security module anything that
would
cause all wikis to be scanned, and I would really
like to avoid that to
happen. So, it will be difficult to avoid partial caching, but we need to
limit that at the higher level, the subwiki. This would allow to had only
scan both the wiki of the user and the target entry to consider our cache
valid. It means subwiki will be unable to share groups (I do not think
this
has ever worked), but it will keep performance on
large farm.
This would really need to be fixed sooner than later otherwise I know
ok so before changing anything we need a plan i.e. someone volunteering to
work on this, right?
plenty of projects for which migration to 5.0
would be almost impossible
I will need helps to achieve that for 5.0 WDYT ?
>
> Thanks
> -Vincent
>
>>> This would really need to be fixed sooner than later otherwise I know
>>> plenty of projects for which migration to 5.0 would be almost impossible
>>>
>>> I think even Workspaces is using that so XEM by default would fail with
>>> this.
>>>
>>> Ludovic
>>>
>>>>
>>>>>
>>>>> 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 ?
11:25 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that
special unsupported case.
I am just saying that while I would like the new module as a default, this
does not prevent a user to use the old one until we properly support that
particular feature.
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>
>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
> wrote:
>>
>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>>>
>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
> jerome(a)velociter.fr
>>>>> 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.
>>>>>>>
>>>>>>
>>>>> 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 ?
>>>>>
>>>>
>>>> You have got it right. This could be improved, and help is welcome.
> What
>>>> happen is that the user groups are evaluated independently to the
>>> targeted
>>>> entity, and therefore only in the user wiki.
>>>>
>>>> I admit this is a regression, but I have not cross lots of use case
> like
>>>> those. The simple display in admin of Global user in local Group is
> even
>>>> broken (double xwiki:xwiki:...) so this does not seems to me a common
>>>> usage.
>>>> You may provide access to global group in a local wiki to achieve the
>>> same
>>>> goals.
>>>>
>>>>
>>> This looks to be indeed a big regression. It's quite a common use case
> to
>>> have only global users and to create groups in the local wiki that
> refer to
>>> local users.
>>>
>> ^^^^^^^^
>> I suppose you means global users here.
>>
>> IMHO, having user managed by a separate entity (global admin), and
these
>> same individual users grouped by another
one (local admin) is very
> uncommon
>> delegation of authority to me (but I may be wrong). On the other hand,
>> having a local admin providing access to local ressources to global
group
>> (and potentially some global users) makes
more sense. In that way, the
> same
>> admin manage its users, and group its users, and the local admin trust
> the
>> global admin to know its users.
>>
>> That said, I am not against any improvement on the way it works, if it
> is a
>> common use case (moreover used by workspace), we should obviously
support
>> it. However, I am convince that
evaluating groups based on both the
user
>> and the targeted entity is not easily
achievable and conduct to very
>> complex partial caching.
>>
>> I have currently not implemented in the security module anything that
> would
>> cause all wikis to be scanned, and I would really like to avoid that to
>> happen. So, it will be difficult to avoid partial caching, but we need
to
>> limit that at the higher level, the
subwiki. This would allow to had
only
>> scan both the wiki of the user and the
target entry to consider our
cache
>> valid. It means subwiki will be unable to
share groups (I do not think
> this
>> has ever worked), but it will keep performance on large farm.
>>
>> This would really need to be fixed sooner than later otherwise I know
>>> plenty of projects for which migration to 5.0 would be almost
impossible
>>>
>>
>> I will need helps to achieve that for 5.0
>
> ok so before changing anything we need a plan i.e. someone volunteering
to
work on
this, right?
Do we really need that for 5.0 ?
Using the new module as a default does not means the old right service is
unavailable. Couldn't we simply define which case needs to revert to the
old modules in the RN, and have 5.0 without this feature ? We may even
release XEM without it if workspace need so.
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
WDYT ?
>
> Thanks
> -Vincent
>
>>> This would really need to be fixed sooner than later otherwise I know
>>> plenty of projects for which migration to 5.0 would be almost
impossible
>>>
>>> I think even Workspaces is using that so XEM by default would fail
with
>>> this.
>>>
>>> Ludovic
>>>
>>>>
>>>>>
>>>>> 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 ?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:06 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol
<vincent(a)massol.net> wrote:
I don't see why you consider this use case as special, when all the
users are managed in the main wiki and you want local admins to be
able to manage groups in their wiki you need this. Or am I missing
something ?
JV.
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that
special unsupported case. On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>
>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
> wrote:
>>
>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>>>
>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
> jerome(a)velociter.fr
>>>>> 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.
>>>>>>>
>>>>>>
>>>>> 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 ?
>>>>>
>>>>
>>>> You have got it right. This could be improved, and help is welcome.
> What
>>>> happen is that the user groups are evaluated independently to the
>>> targeted
>>>> entity, and therefore only in the user wiki.
>>>>
>>>> I admit this is a regression, but I have not cross lots of use case
> like
>>>> those. The simple display in admin of Global user in local Group is
> even
>>>> broken (double xwiki:xwiki:...) so this does not seems to me a common
>>>> usage.
>>>> You may provide access to global group in a local wiki to achieve the
>>> same
>>>> goals.
>>>>
>>>>
>>> This looks to be indeed a big regression. It's quite a common use case
> to
>>> have only global users and to create groups in the local wiki that
> refer to
>>> local users.
>>>
>> ^^^^^^^^
>> I suppose you means global users here.
>>
>> IMHO, having user managed by a separate entity (global admin), and
these
>> same individual users grouped by another
one (local admin) is very
> uncommon
>> delegation of authority to me (but I may be wrong). On the other hand,
>> having a local admin providing access to local ressources to global
group
>> (and potentially some global users) makes
more sense. In that way, the
> same
>> admin manage its users, and group its users, and the local admin trust
> the
>> global admin to know its users.
>>
>> That said, I am not against any improvement on the way it works, if it
> is a
>> common use case (moreover used by workspace), we should obviously
support
>> it. However, I am convince that
evaluating groups based on both the
user
>> and the targeted entity is not easily
achievable and conduct to very
>> complex partial caching.
>>
>> I have currently not implemented in the security module anything that
> would
>> cause all wikis to be scanned, and I would really like to avoid that to
>> happen. So, it will be difficult to avoid partial caching, but we need
to
>> limit that at the higher level, the
subwiki. This would allow to had
only
>> scan both the wiki of the user and the
target entry to consider our
cache
>> valid. It means subwiki will be unable to
share groups (I do not think
> this
>> has ever worked), but it will keep performance on large farm.
>>
>> This would really need to be fixed sooner than later otherwise I know
>>> plenty of projects for which migration to 5.0 would be almost
impossible
>>>
>>
>> I will need helps to achieve that for 5.0
>
> ok so before changing anything we need a plan i.e. someone volunteering
to
work on
this, right?
Do we really need that for 5.0 ?
Using the new module as a default does not means the old right service is
unavailable. Couldn't we simply define which case needs to revert to the
old modules in the RN, and have 5.0 without this feature ? We may even
release XEM without it if workspace need so.
12:14 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
It was, but I was not aware that workspace may need (to be confirmed) that
I probably expressed myself badly. This is currently unsupported in the new
module. I am just saying that even if we release a 5.0 with this
regression, a simple like in xwiki.cfg will put back the old right service
for those who need this. First, only XEM is impacted, second only user with
this kind of delegation need that. So, this is not the general case IMO.
See my reply to Ludovic for more about how we need to work on that missing
feature.
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>
> > On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <vincent(a)massol.net>
> wrote:
> >
> >>
> >> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
> >>
> >>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com>
> >> wrote:
> >>>
> >>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
> >>>>
> >>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
> >> jerome(a)velociter.fr
> >>>>>> 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.
> >>>>>>>>
> >>>>>>>
> >>>>>> 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 ?
> >>>>>>
> >>>>>
> >>>>> You have got it right. This could be improved, and help is
welcome.
> >> What
> >>>>> happen is that the user groups are evaluated independently to
the
> >>>> targeted
> >>>>> entity, and therefore only in the user wiki.
> >>>>>
> >>>>> I admit this is a regression, but I have not cross lots of use
case
> >> like
> >>>>> those. The simple display in admin of Global user in local Group
is
> >> even
> >>>>> broken (double xwiki:xwiki:...) so this does not seems to me a
common
> >>>>> usage.
> >>>>> You may provide access to global group in a local wiki to
achieve
the
> >>>> same
> >>>>> goals.
> >>>>>
> >>>>>
> >>>> This looks to be indeed a big regression. It's quite a common
use
case
> >> to
> >>>> have only global users and to create groups in the local wiki that
> >> refer to
> >>>> local users.
> >>>>
> >>> ^^^^^^^^
> >>> I suppose you means global users here.
> >>>
> >>> IMHO, having user managed by a separate entity (global admin), and
> these
> >>> same individual users grouped by another one (local admin) is very
> >> uncommon
> >>> delegation of authority to me (but I may be wrong). On the other
hand,
> >>> having a local admin providing
access to local ressources to global
> group
> >>> (and potentially some global users) makes more sense. In that way,
the
> >> same
> >>> admin manage its users, and group its users, and the local admin
trust
> >> the
> >>> global admin to know its users.
> >>>
> >>> That said, I am not against any improvement on the way it works, if
it
> >> is a
> >>> common use case (moreover used by workspace), we should obviously
> support
> >>> it. However, I am convince that evaluating groups based on both the
> user
> >>> and the targeted entity is not easily achievable and conduct to very
> >>> complex partial caching.
> >>>
> >>> I have currently not implemented in the security module anything
that
> >> would
> >>> cause all wikis to be scanned, and I would really like to avoid
that to
> >>> happen. So, it will be difficult
to avoid partial caching, but we
need
> to
> >>> limit that at the higher level, the subwiki. This would allow to had
> only
> >>> scan both the wiki of the user and the target entry to consider our
> cache
> >>> valid. It means subwiki will be unable to share groups (I do not
think
> >> this
> >>> has ever worked), but it will keep performance on large farm.
> >>>
> >>> This would really need to be fixed sooner than later otherwise I
know
> >>>> plenty of projects for which
migration to 5.0 would be almost
> impossible
> >>>>
> >>>
> >>> I will need helps to achieve that for 5.0
> >>
> >> ok so before changing anything we need a plan i.e. someone
volunteering
> to
> >> work on this, right?
> >>
> >
> > Do we really need that for 5.0 ?
> > Using the new module as a default does not means the old right
service
is
> > unavailable. Couldn't we simply
define which case needs to revert to
the
old modules in the RN, and have 5.0 without this
feature ? We may even
release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
special unsupported case.
I don't see why you consider this use case as special, when all the
users are managed in the main wiki and you want local admins to be
able to manage groups in their wiki you need this. Or am I missing
something ?
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
12:35 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean
<jv(a)xwiki.com> wrote:
Sure but it's not that simple. We certainly don't want users to be in a situation
where their wiki doesn't work, then they spend time trying to understand. After a few
days they post to the list and then only change the config property. This will be bad for
us. It has to work. Of course we could put it in the Release Notes but it won't help
much in practice.
I'd prefer that we have someone committed to work on this before we change the default
so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by default so that we
can start fixing build/tests?
Thanks
-Vincent
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
that
I probably expressed myself badly. This is currently unsupported in the new
module. I am just saying that even if we release a 5.0 with this
regression, a simple like in xwiki.cfg will put back the old right service
for those who need this. First, only XEM is impacted, second only user with
this kind of delegation need that. So, this is not the general case IMO. On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>
>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <vincent(a)massol.net>
> wrote:
>>
>>>
>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>>>
>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com>
>>> wrote:
>>>>
>>>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>>>>>
>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>>> jerome(a)velociter.fr
>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>> 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 ?
>>>>>>>
>>>>>>
>>>>>> You have got it right. This could be improved, and help is
welcome.
>>> What
>>>>>> happen is that the user groups are evaluated independently to
the
>>>>> targeted
>>>>>> entity, and therefore only in the user wiki.
>>>>>>
>>>>>> I admit this is a regression, but I have not cross lots of use
case
>>> like
>>>>>> those. The simple display in admin of Global user in local Group
is
>>> even
>>>>>> broken (double xwiki:xwiki:...) so this does not seems to me a
common
>>>>>> usage.
>>>>>> You may provide access to global group in a local wiki to achieve
the
>>>>> same
>>>>>> goals.
>>>>>>
>>>>>>
>>>>> This looks to be indeed a big regression. It's quite a common use
case
>>> to
>>>>> have only global users and to create groups in the local wiki that
>>> refer to
>>>>> local users.
>>>>>
>>>> ^^^^^^^^
>>>> I suppose you means global users here.
>>>>
>>>> IMHO, having user managed by a separate entity (global admin), and
> these
>>>> same individual users grouped by another one (local admin) is very
>>> uncommon
>>>> delegation of authority to me (but I may be wrong). On the other
hand,
>>>> having a local admin providing
access to local ressources to global
> group
>>>> (and potentially some global users) makes more sense. In that way,
the
>>> same
>>>> admin manage its users, and group its users, and the local admin
trust
>>> the
>>>> global admin to know its users.
>>>>
>>>> That said, I am not against any improvement on the way it works, if
it
>>> is a
>>>> common use case (moreover used by workspace), we should obviously
> support
>>>> it. However, I am convince that evaluating groups based on both the
> user
>>>> and the targeted entity is not easily achievable and conduct to very
>>>> complex partial caching.
>>>>
>>>> I have currently not implemented in the security module anything
that
>>> would
>>>> cause all wikis to be scanned, and I would really like to avoid
that to
>>>> happen. So, it will be difficult
to avoid partial caching, but we
need
> to
>>>> limit that at the higher level, the subwiki. This would allow to had
> only
>>>> scan both the wiki of the user and the target entry to consider our
> cache
>>>> valid. It means subwiki will be unable to share groups (I do not
think
>>> this
>>>> has ever worked), but it will keep performance on large farm.
>>>>
>>>> This would really need to be fixed sooner than later otherwise I
know
>>>>> plenty of projects for which
migration to 5.0 would be almost
> impossible
>>>>>
>>>>
>>>> I will need helps to achieve that for 5.0
>>>
>>> ok so before changing anything we need a plan i.e. someone
volunteering
> to
>>> work on this, right?
>>>
>>
>> Do we really need that for 5.0 ?
>> Using the new module as a default does not means the old right
service is
>> unavailable. Couldn't we simply
define which case needs to revert to
the
> old
modules in the RN, and have 5.0 without this feature ? We may even
> release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) special unsupported case.
I don't see why you consider this use case as special, when all the
users are managed in the main wiki and you want local admins to be
able to manage groups in their wiki you need this. Or am I missing
something ?
See my reply to Ludovic for more about how we need to
work on that missing
feature.
>
> JV.
8:44 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
(main
I probably expressed myself badly. This is currently unsupported in the new
This is really a lot of works for just a single line commit (redefining all
jenkins modules for the branch)
I think everyone has been +1 on the principe to push this new component
forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the
results:
(a few tests failed whatever the RightService used, however, here is the
delta)
UITest: 1 failure, 1 error
SeleniumTest: 4 failures
Rest: 2 failures
Storage: 3 failures
WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all agree,
I would like to commit on master ASAP, so all of you may help fixing those
tests.
Thomas proposed to help me fixing and improving tests while I add the
missing feature of global user in local group on monday (Good news, I
already some code that seems to be working, need to optimize a bit and
test thoroughly).
If everyone take a minimum of time to help fixing their own tests as
needed, I do not see why we could not be ready for 5.0M2.
And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a
real boost ?
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent
Drean <jv(a)xwiki.com>
wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
>>
>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>>
>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <vincent(a)massol.net
>> wrote:
>>>
>>>>
>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu>
wrote:
>>>>
>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com
>>>>> wrote:
>>>>>>
>>>>>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>>>>>>>
>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>>>>> jerome(a)velociter.fr
>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> This sound like a big regression.
>>>>>>>>>
>>>>>>>>> Can you explicit more ? Does this mean that adding a
global >>>>> wiki)
>>>>>>>>> user in a local group has no effect ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> You have got it right. This could be improved, and help
is
> welcome.
>>>>> What
>>>>>>>> happen is that the user groups are evaluated
independently to the
>>>>>>> targeted
>>>>>>>> entity, and therefore only in the user wiki.
>>>>>>>>
>>>>>>>> I admit this is a regression, but I have not cross lots
of use
> case
>>>>> like
>>>>>>>> those. The simple display in admin of Global user in
local Group
> is
>>>>> even
>>>>>>>> broken (double xwiki:xwiki:...) so this does not seems to
me a
> common
>>>>>>>> usage.
>>>>>>>> You may provide access to global group in a local wiki to
achieve
> the
>>>>>>> same
>>>>>>>> goals.
>>>>>>>>
>>>>>>>>
>>>>>>> This looks to be indeed a big regression. It's quite a
common use
> case
>>>>> to
>>>>>>> have only global users and to create groups in the local wiki
that
>>>>> refer to
>>>>>>> local users.
>>>>>>>
>>>>>> ^^^^^^^^
>>>>>> I suppose you means global users here.
>>>>>>
>>>>>> IMHO, having user managed by a separate entity (global admin),
and
>>> these
>>>>>> same individual users grouped by another one (local admin) is
very
>>>>> uncommon
>>>>>> delegation of authority to me (but I may be wrong). On the other
> hand,
>>>>>> having a local admin providing access to local ressources to
global
>>> group
>>>>>> (and potentially some global users) makes more sense. In that
way,
> the
>>>>> same
>>>>>> admin manage its users, and group its users, and the local admin
> trust
>>>>> the
>>>>>> global admin to know its users.
>>>>>>
>>>>>> That said, I am not against any improvement on the way it works,
if
> it
>>>>> is a
>>>>>> common use case (moreover used by workspace), we should
obviously
>>> support
>>>>>> it. However, I am convince that evaluating groups based on both
the
>>> user
>>>>>> and the targeted entity is not easily achievable and conduct to
very
>>>>>> complex partial caching.
>>>>>>
>>>>>> I have currently not implemented in the security module anything
> that
>>>>> would
>>>>>> cause all wikis to be scanned, and I would really like to avoid
> that to
>>>>>> happen. So, it will be difficult to avoid partial caching, but
we
> need
>>> to
>>>>>> limit that at the higher level, the subwiki. This would allow to
had
>>> only
>>>>>> scan both the wiki of the user and the target entry to consider
our
>>> cache
>>>>>> valid. It means subwiki will be unable to share groups (I do not
> think
>>>>> this
>>>>>> has ever worked), but it will keep performance on large farm.
>>>>>>
>>>>>> This would really need to be fixed sooner than later otherwise I
> know
>>>>>>> plenty of projects for which migration to 5.0 would be
almost
>>> impossible
>>>>>>>
>>>>>>
>>>>>> I will need helps to achieve that for 5.0
>>>>>
>>>>> ok so before changing anything we need a plan i.e. someone
> volunteering
>>> to
>>>>> work on this, right?
>>>>>
>>>>
>>>> Do we really need that for 5.0 ?
>>>> Using the new module as a default does not means the old right
> service is
>>>> unavailable. Couldn't we simply define which case needs to revert to
> the
>>>> old modules in the RN, and have 5.0 without this feature ? We may
even
>> release XEM without it if workspace need so.
>
> I thought the config change you were proposing was global… I'm lost…
>
It was, but I was not aware that workspace may need (to be confirmed)
that
special unsupported case.
I don't see why you consider this use case as special, when all the
users are managed in the main wiki and you want local admins to be
able to manage groups in their wiki you need this. Or am I missing
something ?
module. I am just saying that even if we release
a 5.0 with this
regression, a simple like in xwiki.cfg will put back the old right
service
for those who need this. First, only XEM is
impacted, second only user
with
this kind of delegation need that. So, this is
not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a
situation where their wiki doesn't work, then they spend time trying to
understand. After a few days they post to the list and then only change the
config property. This will be bad for us. It has to work. Of course we
could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change
the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by
default so that we can start fixing build/tests?
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
See my reply to Ludovic for more about how we
need to work on that
missing
feature.
>
> JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
16 Mar
16 Mar
8:57 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Mar 15, 2013, at 8:44 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol
<vincent(a)massol.net> wrote:
Sure, and all the more since I'm on holidays so I'll let you guys fix the build
instability :)
I just hope it'll be nice and stable again when I'm back in one week! :)
Have fun
Thanks
-Vincent
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
(main
new
This is really a lot of works for just a single line commit (redefining all
jenkins modules for the branch)
I think everyone has been +1 on the principe to push this new component
forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the
results:
(a few tests failed whatever the RightService used, however, here is the
delta)
UITest: 1 failure, 1 error
SeleniumTest: 4 failures
Rest: 2 failures
Storage: 3 failures
WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all agree,
I would like to commit on master ASAP, so all of you may help fixing those
tests.
Thomas proposed to help me fixing and improving tests while I add the
missing feature of global user in local group on monday (Good news, I
already some code that seems to be working, need to optimize a bit and
test thoroughly).
If everyone take a minimum of time to help fixing their own tests as
needed, I do not see why we could not be ready for 5.0M2.
And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a
real boost ? On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent
Drean <jv(a)xwiki.com>
wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <vincent(a)massol.net>
wrote:
>
>>
>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>>
>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <vincent(a)massol.net
>> wrote:
>>>
>>>>
>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu>
wrote:
>>>>
>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com
>>>>> wrote:
>>>>>>
>>>>>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>>>>>>>
>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>>>>> jerome(a)velociter.fr
>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> This sound like a big regression.
>>>>>>>>>
>>>>>>>>> Can you explicit more ? Does this mean that adding a
global >>>>> wiki)
>>>>>>>>> user in a local group has no effect ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> You have got it right. This could be improved, and help
is
> welcome.
>>>>> What
>>>>>>>> happen is that the user groups are evaluated
independently to the
>>>>>>> targeted
>>>>>>>> entity, and therefore only in the user wiki.
>>>>>>>>
>>>>>>>> I admit this is a regression, but I have not cross lots
of use
> case
>>>>> like
>>>>>>>> those. The simple display in admin of Global user in
local Group
> is
>>>>> even
>>>>>>>> broken (double xwiki:xwiki:...) so this does not seems to
me a
> common
>>>>>>>> usage.
>>>>>>>> You may provide access to global group in a local wiki to
achieve
> the
>>>>>>> same
>>>>>>>> goals.
>>>>>>>>
>>>>>>>>
>>>>>>> This looks to be indeed a big regression. It's quite a
common use
> case
>>>>> to
>>>>>>> have only global users and to create groups in the local wiki
that
>>>>> refer to
>>>>>>> local users.
>>>>>>>
>>>>>> ^^^^^^^^
>>>>>> I suppose you means global users here.
>>>>>>
>>>>>> IMHO, having user managed by a separate entity (global admin),
and
>>> these
>>>>>> same individual users grouped by another one (local admin) is
very
>>>>> uncommon
>>>>>> delegation of authority to me (but I may be wrong). On the other
> hand,
>>>>>> having a local admin providing access to local ressources to
global
>>> group
>>>>>> (and potentially some global users) makes more sense. In that
way,
> the
>>>>> same
>>>>>> admin manage its users, and group its users, and the local admin
> trust
>>>>> the
>>>>>> global admin to know its users.
>>>>>>
>>>>>> That said, I am not against any improvement on the way it works,
if
> it
>>>>> is a
>>>>>> common use case (moreover used by workspace), we should
obviously
>>> support
>>>>>> it. However, I am convince that evaluating groups based on both
the
>>> user
>>>>>> and the targeted entity is not easily achievable and conduct to
very
>>>>>> complex partial caching.
>>>>>>
>>>>>> I have currently not implemented in the security module anything
> that
>>>>> would
>>>>>> cause all wikis to be scanned, and I would really like to avoid
> that to
>>>>>> happen. So, it will be difficult to avoid partial caching, but
we
> need
>>> to
>>>>>> limit that at the higher level, the subwiki. This would allow to
had
>>> only
>>>>>> scan both the wiki of the user and the target entry to consider
our
>>> cache
>>>>>> valid. It means subwiki will be unable to share groups (I do not
> think
>>>>> this
>>>>>> has ever worked), but it will keep performance on large farm.
>>>>>>
>>>>>> This would really need to be fixed sooner than later otherwise I
> know
>>>>>>> plenty of projects for which migration to 5.0 would be
almost
>>> impossible
>>>>>>>
>>>>>>
>>>>>> I will need helps to achieve that for 5.0
>>>>>
>>>>> ok so before changing anything we need a plan i.e. someone
> volunteering
>>> to
>>>>> work on this, right?
>>>>>
>>>>
>>>> Do we really need that for 5.0 ?
>>>> Using the new module as a default does not means the old right
> service is
>>>> unavailable. Couldn't we simply define which case needs to revert to
> the
>>>> old modules in the RN, and have 5.0 without this feature ? We may
even
>>> release XEM without it if workspace need so.
>>
>> I thought the config change you were proposing was global… I'm lost…
>>
>
> It was, but I was not aware that workspace may need (to be confirmed)
that
> special unsupported case.
I don't see why you consider this use case as special, when all the
users are managed in the main wiki and you want local admins to be
able to manage groups in their wiki you need this. Or am I missing
something ?
I probably expressed myself badly. This is currently unsupported in the module. I am just saying that even if we release
a 5.0 with this
regression, a simple like in xwiki.cfg will put back the old right
service
for those who need this. First, only XEM is
impacted, second only user
with
this kind of delegation need that. So, this is
not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a
situation where their wiki doesn't work, then they spend time trying to
understand. After a few days they post to the list and then only change the
config property. This will be bad for us. It has to work. Of course we
could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change
the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by
default so that we can start fixing build/tests?
> Thanks
> -Vincent
>
>> See my reply to Ludovic for more about how we need to work on that
> missing
>> feature.
>>
>>
>>>
>>> JV.
2:28 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 8:44 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
--
Thomas Mortagne
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol
<vincent(a)massol.net> wrote:
+1
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
(main
new
This is really a lot of works for just a single line commit (redefining all
jenkins modules for the branch)
I think everyone has been +1 on the principe to push this new component
forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the
results:
(a few tests failed whatever the RightService used, however, here is the
delta)
UITest: 1 failure, 1 error
SeleniumTest: 4 failures
Rest: 2 failures
Storage: 3 failures
WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all agree,
I would like to commit on master ASAP, so all of you may help fixing those
tests.
Thomas proposed to help me fixing and improving tests while I add the
missing feature of global user in local group on monday (Good news, I
already some code that seems to be working, need to optimize a bit and
test thoroughly).
If everyone take a minimum of time to help fixing their own tests as
needed, I do not see why we could not be ready for 5.0M2.
And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a
real boost ? On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent
Drean <jv(a)xwiki.com>
wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <vincent(a)massol.net>
wrote:
>
>>
>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>>
>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <vincent(a)massol.net
>> wrote:
>>>
>>>>
>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu>
wrote:
>>>>
>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com
>>>>> wrote:
>>>>>>
>>>>>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>>>>>>>
>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>>>>> jerome(a)velociter.fr
>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> This sound like a big regression.
>>>>>>>>>
>>>>>>>>> Can you explicit more ? Does this mean that adding a
global >>>>> wiki)
>>>>>>>>> user in a local group has no effect ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> You have got it right. This could be improved, and help
is
> welcome.
>>>>> What
>>>>>>>> happen is that the user groups are evaluated
independently to the
>>>>>>> targeted
>>>>>>>> entity, and therefore only in the user wiki.
>>>>>>>>
>>>>>>>> I admit this is a regression, but I have not cross lots
of use
> case
>>>>> like
>>>>>>>> those. The simple display in admin of Global user in
local Group
> is
>>>>> even
>>>>>>>> broken (double xwiki:xwiki:...) so this does not seems to
me a
> common
>>>>>>>> usage.
>>>>>>>> You may provide access to global group in a local wiki to
achieve
> the
>>>>>>> same
>>>>>>>> goals.
>>>>>>>>
>>>>>>>>
>>>>>>> This looks to be indeed a big regression. It's quite a
common use
> case
>>>>> to
>>>>>>> have only global users and to create groups in the local wiki
that
>>>>> refer to
>>>>>>> local users.
>>>>>>>
>>>>>> ^^^^^^^^
>>>>>> I suppose you means global users here.
>>>>>>
>>>>>> IMHO, having user managed by a separate entity (global admin),
and
>>> these
>>>>>> same individual users grouped by another one (local admin) is
very
>>>>> uncommon
>>>>>> delegation of authority to me (but I may be wrong). On the other
> hand,
>>>>>> having a local admin providing access to local ressources to
global
>>> group
>>>>>> (and potentially some global users) makes more sense. In that
way,
> the
>>>>> same
>>>>>> admin manage its users, and group its users, and the local admin
> trust
>>>>> the
>>>>>> global admin to know its users.
>>>>>>
>>>>>> That said, I am not against any improvement on the way it works,
if
> it
>>>>> is a
>>>>>> common use case (moreover used by workspace), we should
obviously
>>> support
>>>>>> it. However, I am convince that evaluating groups based on both
the
>>> user
>>>>>> and the targeted entity is not easily achievable and conduct to
very
>>>>>> complex partial caching.
>>>>>>
>>>>>> I have currently not implemented in the security module anything
> that
>>>>> would
>>>>>> cause all wikis to be scanned, and I would really like to avoid
> that to
>>>>>> happen. So, it will be difficult to avoid partial caching, but
we
> need
>>> to
>>>>>> limit that at the higher level, the subwiki. This would allow to
had
>>> only
>>>>>> scan both the wiki of the user and the target entry to consider
our
>>> cache
>>>>>> valid. It means subwiki will be unable to share groups (I do not
> think
>>>>> this
>>>>>> has ever worked), but it will keep performance on large farm.
>>>>>>
>>>>>> This would really need to be fixed sooner than later otherwise I
> know
>>>>>>> plenty of projects for which migration to 5.0 would be
almost
>>> impossible
>>>>>>>
>>>>>>
>>>>>> I will need helps to achieve that for 5.0
>>>>>
>>>>> ok so before changing anything we need a plan i.e. someone
> volunteering
>>> to
>>>>> work on this, right?
>>>>>
>>>>
>>>> Do we really need that for 5.0 ?
>>>> Using the new module as a default does not means the old right
> service is
>>>> unavailable. Couldn't we simply define which case needs to revert to
> the
>>>> old modules in the RN, and have 5.0 without this feature ? We may
even
>>> release XEM without it if workspace need so.
>>
>> I thought the config change you were proposing was global… I'm lost…
>>
>
> It was, but I was not aware that workspace may need (to be confirmed)
that
> special unsupported case.
I don't see why you consider this use case as special, when all the
users are managed in the main wiki and you want local admins to be
able to manage groups in their wiki you need this. Or am I missing
something ?
I probably expressed myself badly. This is currently unsupported in the module. I am just saying that even if we release
a 5.0 with this
regression, a simple like in xwiki.cfg will put back the old right
service
for those who need this. First, only XEM is
impacted, second only user
with
this kind of delegation need that. So, this is
not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a
situation where their wiki doesn't work, then they spend time trying to
understand. After a few days they post to the list and then only change the
config property. This will be bad for us. It has to work. Of course we
could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change
the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by
default so that we can start fixing build/tests?
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs See my reply to Ludovic for more about how we
need to work on that
missing
feature.
>
> JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:36 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 9:44 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol
<vincent(a)massol.net> wrote:
+1. I'll help fixing the failing tests.
Thanks,
Marius
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
(main
new
This is really a lot of works for just a single line commit (redefining all
jenkins modules for the branch)
I think everyone has been +1 on the principe to push this new component
forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the
results:
(a few tests failed whatever the RightService used, however, here is the
delta)
UITest: 1 failure, 1 error
SeleniumTest: 4 failures
Rest: 2 failures
Storage: 3 failures
WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all agree,
I would like to commit on master ASAP, so all of you may help fixing those
tests.
Thomas proposed to help me fixing and improving tests while I add the
missing feature of global user in local group on monday (Good news, I
already some code that seems to be working, need to optimize a bit and
test thoroughly).
If everyone take a minimum of time to help fixing their own tests as
needed, I do not see why we could not be ready for 5.0M2.
And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a
real boost ? On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent
Drean <jv(a)xwiki.com>
wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <vincent(a)massol.net>
wrote:
>
>>
>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>>
>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <vincent(a)massol.net
>> wrote:
>>>
>>>>
>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu>
wrote:
>>>>
>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com
>>>>> wrote:
>>>>>>
>>>>>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>>>>>>>
>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>>>>> jerome(a)velociter.fr
>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> This sound like a big regression.
>>>>>>>>>
>>>>>>>>> Can you explicit more ? Does this mean that adding a
global >>>>> wiki)
>>>>>>>>> user in a local group has no effect ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> You have got it right. This could be improved, and help
is
> welcome.
>>>>> What
>>>>>>>> happen is that the user groups are evaluated
independently to the
>>>>>>> targeted
>>>>>>>> entity, and therefore only in the user wiki.
>>>>>>>>
>>>>>>>> I admit this is a regression, but I have not cross lots
of use
> case
>>>>> like
>>>>>>>> those. The simple display in admin of Global user in
local Group
> is
>>>>> even
>>>>>>>> broken (double xwiki:xwiki:...) so this does not seems to
me a
> common
>>>>>>>> usage.
>>>>>>>> You may provide access to global group in a local wiki to
achieve
> the
>>>>>>> same
>>>>>>>> goals.
>>>>>>>>
>>>>>>>>
>>>>>>> This looks to be indeed a big regression. It's quite a
common use
> case
>>>>> to
>>>>>>> have only global users and to create groups in the local wiki
that
>>>>> refer to
>>>>>>> local users.
>>>>>>>
>>>>>> ^^^^^^^^
>>>>>> I suppose you means global users here.
>>>>>>
>>>>>> IMHO, having user managed by a separate entity (global admin),
and
>>> these
>>>>>> same individual users grouped by another one (local admin) is
very
>>>>> uncommon
>>>>>> delegation of authority to me (but I may be wrong). On the other
> hand,
>>>>>> having a local admin providing access to local ressources to
global
>>> group
>>>>>> (and potentially some global users) makes more sense. In that
way,
> the
>>>>> same
>>>>>> admin manage its users, and group its users, and the local admin
> trust
>>>>> the
>>>>>> global admin to know its users.
>>>>>>
>>>>>> That said, I am not against any improvement on the way it works,
if
> it
>>>>> is a
>>>>>> common use case (moreover used by workspace), we should
obviously
>>> support
>>>>>> it. However, I am convince that evaluating groups based on both
the
>>> user
>>>>>> and the targeted entity is not easily achievable and conduct to
very
>>>>>> complex partial caching.
>>>>>>
>>>>>> I have currently not implemented in the security module anything
> that
>>>>> would
>>>>>> cause all wikis to be scanned, and I would really like to avoid
> that to
>>>>>> happen. So, it will be difficult to avoid partial caching, but
we
> need
>>> to
>>>>>> limit that at the higher level, the subwiki. This would allow to
had
>>> only
>>>>>> scan both the wiki of the user and the target entry to consider
our
>>> cache
>>>>>> valid. It means subwiki will be unable to share groups (I do not
> think
>>>>> this
>>>>>> has ever worked), but it will keep performance on large farm.
>>>>>>
>>>>>> This would really need to be fixed sooner than later otherwise I
> know
>>>>>>> plenty of projects for which migration to 5.0 would be
almost
>>> impossible
>>>>>>>
>>>>>>
>>>>>> I will need helps to achieve that for 5.0
>>>>>
>>>>> ok so before changing anything we need a plan i.e. someone
> volunteering
>>> to
>>>>> work on this, right?
>>>>>
>>>>
>>>> Do we really need that for 5.0 ?
>>>> Using the new module as a default does not means the old right
> service is
>>>> unavailable. Couldn't we simply define which case needs to revert to
> the
>>>> old modules in the RN, and have 5.0 without this feature ? We may
even
>>> release XEM without it if workspace need so.
>>
>> I thought the config change you were proposing was global… I'm lost…
>>
>
> It was, but I was not aware that workspace may need (to be confirmed)
that
> special unsupported case.
I don't see why you consider this use case as special, when all the
users are managed in the main wiki and you want local admins to be
able to manage groups in their wiki you need this. Or am I missing
something ?
I probably expressed myself badly. This is currently unsupported in the module. I am just saying that even if we release
a 5.0 with this
regression, a simple like in xwiki.cfg will put back the old right
service
for those who need this. First, only XEM is
impacted, second only user
with
this kind of delegation need that. So, this is
not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a
situation where their wiki doesn't work, then they spend time trying to
understand. After a few days they post to the list and then only change the
config property. This will be bad for us. It has to work. Of course we
could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change
the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by
default so that we can start fixing build/tests?
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs See my reply to Ludovic for more about how we
need to work on that
missing
feature.
>
> JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 Mar
20 Mar
1:40 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
Vote has passed with four +1 and mostly general agreement.
With Thomas, we have fix the missing features, see XWIKI-8931 and
XWIKI-8933, and we are improving unit tests.
So, I will switch the default RightService later today, the jira issue
is XWIKI-8944
Your help will be welcome to fix any integration tests that start failing
after that.
Thanks,
On Sat, Mar 16, 2013 at 2:36 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
On Fri, Mar 15, 2013 at 9:44 PM, Denis Gervalle
<dgl(a)softec.lu> wrote:
all
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Mar 15, 2013, at 12:14 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
>
> > On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <jv(a)xwiki.com>
> wrote:
> >
> >> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <dgl(a)softec.lu>
wrote:
> >>> On Fri, Mar 15, 2013 at 10:57
AM, Vincent Massol <
vincent(a)massol.net>
> >> wrote:
> >>>
> >>>>
> >>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu>
wrote:
> >>>>
> >>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <
vincent(a)massol.net
> >
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle
<dgl(a)softec.lu>
wrote:
> >>>>>>
> >>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <
ludovic(a)xwiki.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
> >>>>>>>>
> >>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome
Velociter <
> >>>>>> jerome(a)velociter.fr
> >>>>>>>>>> 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.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> 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 ?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> You have got it right. This could be improved,
and help is
> >> welcome.
> >>>>>> What
> >>>>>>>>> happen is that the user groups are evaluated
independently to
the
> >>>>>>>> targeted
> >>>>>>>>> entity, and therefore only in the user wiki.
> >>>>>>>>>
> >>>>>>>>> I admit this is a regression, but I have not
cross lots of use
> >> case
> >>>>>> like
> >>>>>>>>> those. The simple display in admin of Global
user in local
Group
> >> is
> >>>>>> even
> >>>>>>>>> broken (double xwiki:xwiki:...) so this does not
seems to me a
> >> common
> >>>>>>>>> usage.
> >>>>>>>>> You may provide access to global group in a
local wiki to
achieve
> >> the
> >>>>>>>> same
> >>>>>>>>> goals.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> This looks to be indeed a big regression. It's
quite a common
use
> >> case
> >>>>>> to
> >>>>>>>> have only global users and to create groups in the
local wiki
that
> >>>>>> refer to
> >>>>>>>> local users.
> >>>>>>>>
> >>>>>>> ^^^^^^^^
> >>>>>>> I suppose you means global users here.
> >>>>>>>
> >>>>>>> IMHO, having user managed by a separate entity (global
admin),
and
> >>>> these
> >>>>>>> same individual users grouped by another one (local
admin) is
very
> >>>>>> uncommon
> >>>>>>> delegation of authority to me (but I may be wrong). On
the other
> >> hand,
> >>>>>>> having a local admin providing access to local
ressources to
global
> >>>> group
> >>>>>>> (and potentially some global users) makes more sense. In
that
way,
> >> the
> >>>>>> same
> >>>>>>> admin manage its users, and group its users, and the
local admin
> >> trust
> >>>>>> the
> >>>>>>> global admin to know its users.
> >>>>>>>
> >>>>>>> That said, I am not against any improvement on the way
it
works, if
> >> it
> >>>>>> is a
> >>>>>>> common use case (moreover used by workspace), we should
obviously
> >>>> support
> >>>>>>> it. However, I am convince that evaluating groups based
on both
the
> >>>> user
> >>>>>>> and the targeted entity is not easily achievable and
conduct to
> very
> >>>>>>> complex partial caching.
> >>>>>>>
> >>>>>>> I have currently not implemented in the security module
anything
> >> that
> >>>>>> would
> >>>>>>> cause all wikis to be scanned, and I would really like
to avoid
> >> that to
> >>>>>>> happen. So, it will be difficult to avoid partial
caching, but
we
> >> need
> >>>> to
> >>>>>>> limit that at the higher level, the subwiki. This would
allow to
> had
> >>>> only
> >>>>>>> scan both the wiki of the user and the target entry to
consider
our
> >>>> cache
> >>>>>>> valid. It means subwiki will be unable to share groups
(I do not
> >> think
> >>>>>> this
> >>>>>>> has ever worked), but it will keep performance on large
farm.
> >>>>>>>
> >>>>>>> This would really need to be fixed sooner than later
otherwise I
> >> know
> >>>>>>>> plenty of projects for which migration to 5.0 would
be almost
> >>>> impossible
> >>>>>>>>
> >>>>>>>
> >>>>>>> I will need helps to achieve that for 5.0
> >>>>>>
> >>>>>> ok so before changing anything we need a plan i.e. someone
> >> volunteering
> >>>> to
> >>>>>> work on this, right?
> >>>>>>
> >>>>>
> >>>>> Do we really need that for 5.0 ?
> >>>>> Using the new module as a default does not means the old right
> >> service is
> >>>>> unavailable. Couldn't we simply define which case needs to
revert
to
> >> the
> >>>>> old modules in the RN, and have 5.0 without this feature ? We
may
> even
> >>>>> release XEM without it if workspace need so.
> >>>>
> >>>> I thought the config change you were proposing was global… I'm
lost…
> >>>>
> >>>
> >>> It was, but I was not aware that workspace may need (to be
confirmed)
> >> that
> >>> special unsupported case.
> >>
> >> I don't see why you consider this use case as special, when all the
> >> users are managed in the main wiki and you want local admins to be
> >> able to manage groups in their wiki you need this. Or am I missing
> >> something ?
> >>
> >
> > I probably expressed myself badly. This is currently unsupported in
the
> new
> > module. I am just saying that even if we release a 5.0 with this
> > regression, a simple like in xwiki.cfg will put back the old right
> service
> > for those who need this. First, only XEM is impacted, second only user
> with
> > this kind of delegation need that. So, this is not the general case
IMO.
>
> Sure but it's not that simple. We certainly don't want users to be in a
> situation where their wiki doesn't work, then they spend time trying to
> understand. After a few days they post to the list and then only change
the
> config property. This will be bad for us. It
has to work. Of course we
> could put it in the Release Notes but it won't help much in practice.
>
> I'd prefer that we have someone committed to work on this before we
change
the
default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by
default so that we can start fixing build/tests?
This is really a lot of works for just a single line commit (redefining jenkins modules for the branch)
I think everyone has been +1 on the principe to push this new component
forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the
results:
(a few tests failed whatever the RightService used, however, here is the
delta)
UITest: 1 failure, 1 error
SeleniumTest: 4 failures
Rest: 2 failures
Storage: 3 failures
WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all
agree,
I would like to commit on master ASAP, so all of
you may help fixing
those
tests.
Thomas proposed to help me fixing and improving tests while I add the
missing feature of global user in local group on monday (Good news, I
already some code that seems to be working, need to optimize a bit and
test thoroughly).
If everyone take a minimum of time to help fixing their own tests as
needed, I do not see why we could not be ready for 5.0M2.
And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a
real boost ?
+1. I'll help fixing the failing tests.
Thanks,
Marius
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs See my reply to Ludovic for more about how we
need to work on that
missing
feature.
>
> JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1 Apr
1 Apr
7:06 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
Hi devs,
The security module is now documented at
http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module and
the release notes of upcoming release
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki50M2 try
to take attention of migrating user to major changes of behavior. I hope I
have not missed to mention any unexpected changes and that those change
meet your agreement. You are encouraged to review these documentations and
comments.
Thanks,
On Wed, Mar 20, 2013 at 1:40 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
Vote has passed with four +1 and mostly general
agreement.
With Thomas, we have fix the missing features, see XWIKI-8931 and
XWIKI-8933, and we are improving unit tests.
So, I will switch the default RightService later today, the jira issue
is XWIKI-8944
Your help will be welcome to fix any integration tests that start failing
after that.
Thanks,
On Sat, Mar 16, 2013 at 2:36 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On Fri, Mar 15, 2013 at 9:44 PM, Denis Gervalle
<dgl(a)softec.lu> wrote:
all
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Mar 15, 2013, at 12:14 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
>
> > On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <jv(a)xwiki.com>
> wrote:
> >
> >> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <dgl(a)softec.lu>
wrote:
> >>> On Fri, Mar 15, 2013 at 10:57
AM, Vincent Massol <
vincent(a)massol.net>
> >> wrote:
> >>>
> >>>>
> >>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu>
wrote:
> >>>>
> >>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <
vincent(a)massol.net
> >
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle
<dgl(a)softec.lu>
wrote:
> >>>>>>
> >>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <
ludovic(a)xwiki.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
> >>>>>>>>
> >>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome
Velociter <
> >>>>>> jerome(a)velociter.fr
> >>>>>>>>>> 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.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> 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 ?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> You have got it right. This could be improved,
and help is
> >> welcome.
> >>>>>> What
> >>>>>>>>> happen is that the user groups are evaluated
independently
to the
> >>>>>>>> targeted
> >>>>>>>>> entity, and therefore only in the user wiki.
> >>>>>>>>>
> >>>>>>>>> I admit this is a regression, but I have not
cross lots of
use
> >> case
> >>>>>> like
> >>>>>>>>> those. The simple display in admin of Global
user in local
Group
> >> is
> >>>>>> even
> >>>>>>>>> broken (double xwiki:xwiki:...) so this does not
seems to me
a
> >> common
> >>>>>>>>> usage.
> >>>>>>>>> You may provide access to global group in a
local wiki to
achieve
> >> the
> >>>>>>>> same
> >>>>>>>>> goals.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> This looks to be indeed a big regression. It's
quite a common
use
> >> case
> >>>>>> to
> >>>>>>>> have only global users and to create groups in the
local wiki
that
> >>>>>> refer to
> >>>>>>>> local users.
> >>>>>>>>
> >>>>>>> ^^^^^^^^
> >>>>>>> I suppose you means global users here.
> >>>>>>>
> >>>>>>> IMHO, having user managed by a separate entity (global
admin),
and
> >>>> these
> >>>>>>> same individual users grouped by another one (local
admin) is
very
> >>>>>> uncommon
> >>>>>>> delegation of authority to me (but I may be wrong). On
the
other
> >> hand,
> >>>>>>> having a local admin providing access to local
ressources to
global
> >>>> group
> >>>>>>> (and potentially some global users) makes more sense. In
that
way,
> >> the
> >>>>>> same
> >>>>>>> admin manage its users, and group its users, and the
local
admin
> >> trust
> >>>>>> the
> >>>>>>> global admin to know its users.
> >>>>>>>
> >>>>>>> That said, I am not against any improvement on the way
it
works, if
> >> it
> >>>>>> is a
> >>>>>>> common use case (moreover used by workspace), we should
obviously
> >>>> support
> >>>>>>> it. However, I am convince that evaluating groups based
on
both the
> >>>> user
> >>>>>>> and the targeted entity is not easily achievable and
conduct to
> very
> >>>>>>> complex partial caching.
> >>>>>>>
> >>>>>>> I have currently not implemented in the security module
anything
> >> that
> >>>>>> would
> >>>>>>> cause all wikis to be scanned, and I would really like
to avoid
> >> that to
> >>>>>>> happen. So, it will be difficult to avoid partial
caching, but
we
> >> need
> >>>> to
> >>>>>>> limit that at the higher level, the subwiki. This would
allow
to
> had
> >>>> only
> >>>>>>> scan both the wiki of the user and the target entry to
consider our
> >>>> cache
> >>>>>>> valid. It means subwiki will be unable to share groups
(I do
not
> >> think
> >>>>>> this
> >>>>>>> has ever worked), but it will keep performance on large
farm.
> >>>>>>>
> >>>>>>> This would really need to be fixed sooner than later
otherwise
I
> >> know
> >>>>>>>> plenty of projects for which migration to 5.0 would
be almost
> >>>> impossible
> >>>>>>>>
> >>>>>>>
> >>>>>>> I will need helps to achieve that for 5.0
> >>>>>>
> >>>>>> ok so before changing anything we need a plan i.e. someone
> >> volunteering
> >>>> to
> >>>>>> work on this, right?
> >>>>>>
> >>>>>
> >>>>> Do we really need that for 5.0 ?
> >>>>> Using the new module as a default does not means the old right
> >> service is
> >>>>> unavailable. Couldn't we simply define which case needs to
revert to
> >> the
> >>>>> old modules in the RN, and have 5.0 without this feature ? We
may
> even
> >>>>> release XEM without it if workspace need so.
> >>>>
> >>>> I thought the config change you were proposing was global… I'm
lost…
> >>>>
> >>>
> >>> It was, but I was not aware that workspace may need (to be
confirmed)
> >> that
> >>> special unsupported case.
> >>
> >> I don't see why you consider this use case as special, when all the
> >> users are managed in the main wiki and you want local admins to be
> >> able to manage groups in their wiki you need this. Or am I missing
> >> something ?
> >>
> >
> > I probably expressed myself badly. This is currently unsupported in
the
> new
> > module. I am just saying that even if we release a 5.0 with this
> > regression, a simple like in xwiki.cfg will put back the old right
> service
> > for those who need this. First, only XEM is impacted, second only
user
> with
> > this kind of delegation need that. So, this is not the general case
IMO.
>
> Sure but it's not that simple. We certainly don't want users to be in a
> situation where their wiki doesn't work, then they spend time trying to
> understand. After a few days they post to the list and then only
change the
> config property. This will be bad for us. It
has to work. Of course we
> could put it in the Release Notes but it won't help much in practice.
>
> I'd prefer that we have someone committed to work on this before we
change
the
default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by
default so that we can start fixing build/tests?
This is really a lot of works for just a single line commit (redefining jenkins modules for the branch)
I think everyone has been +1 on the principe to push this new component
forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the
results:
(a few tests failed whatever the RightService used, however, here is the
delta)
UITest: 1 failure, 1 error
SeleniumTest: 4 failures
Rest: 2 failures
Storage: 3 failures
WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all
agree,
I would like to commit on master ASAP, so all of
you may help fixing
those
tests.
Thomas proposed to help me fixing and improving tests while I add the
missing feature of global user in local group on monday (Good news, I
already some code that seems to be working, need to optimize a bit and
test thoroughly).
If everyone take a minimum of time to help fixing their own tests as
needed, I do not see why we could not be ready for 5.0M2.
And this leave us some more time to fix potential hidden issue before
RC.
So, do you agree to go that way and give this long awaited improvement a
real boost ?
+1. I'll help fixing the failing tests.
Thanks,
Marius
Thanks
-Vincent
> See my reply to Ludovic for more about how we need to work on that
missing
> feature.
>
>
>>
>> JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
15 Mar
15 Mar
1:58 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
Hi Denis,
On Fri, Mar 15, 2013 at 12:25 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
opposed
common
hand,
the
to
volunteering
It was, but I was not aware that workspace may need (to be confirmed) that
special unsupported case.
As JV and other have already mentioned, this is not a special use case at
all. You also need to consider the fact that with the virtual=1 by default,
we are basically moving to XEM as the default product instead of XE, so
this feature is becoming more important.
In a multiwiki environment, you basically have 2 major use cases:
1) Farm use case, where each wiki is isolated and manages its own local
users and does not interact with other wikis
2) Workspaces(intranets/etc.) use case, where the main wiki is the entry
point and it is in charge of managing the users and the subwikis are shared
locations where global users work on. This means that they need to be given
access to those wikis, based on their needs, and this implies that global
users need to become members of local groups (subwiki:XWiki.XWikiAllGroup).
The alternative of giving individual (per-user) wiki-level rights (in each
subwiki) is just not practical.
Hope this helped,
Eduard
I am just saying that while I would like the new module as a default, this
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
while
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
>>
>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>>
>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
>> wrote:
>>>
>>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>>>>
>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>> jerome(a)velociter.fr
>>>>>> 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 >>>> 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:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>
>>>>>>> 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 >>>> 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.
>>>>>>>>
>>>>>>>
>>>>>> 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 ?
>>>>>>
>>>>>
>>>>> You have got it right. This could be improved, and help is welcome.
>> What
>>>>> happen is that the user groups are evaluated independently to the
>>>> targeted
>>>>> entity, and therefore only in the user wiki.
>>>>>
>>>>> I admit this is a regression, but I have not cross lots of use case
>> like
>>>>> those. The simple display in admin of Global user in local Group is
>> even
>>>>> broken (double xwiki:xwiki:...) so this does not seems to me a
>>>>> usage.
>>>>> You may provide access to global group in a local wiki to achieve
the
>>>> same
>>>>> goals.
>>>>>
>>>>>
>>>> This looks to be indeed a big regression. It's quite a common use
case
> to
>>> have only global users and to create groups in the local wiki that
> refer to
>>> local users.
>>>
>> ^^^^^^^^
>> I suppose you means global users here.
>>
>> IMHO, having user managed by a separate entity (global admin), and
these
>>> same individual users grouped by another one (local admin) is very
>> uncommon
>>> delegation of authority to me (but I may be wrong). On the other >>
having a local admin providing access to local ressources to global
group
>>> (and potentially some global users) makes more sense. In that way, >> same
>>> admin manage its users, and group its users, and the local admin
trust
>> the
>>> global admin to know its users.
>>>
>>> That said, I am not against any improvement on the way it works, if
it
> is a
>> common use case (moreover used by workspace), we should obviously
support
>> it. However, I am convince that
evaluating groups based on both the
user
>>> and the targeted entity is not easily achievable and conduct to very
>>> complex partial caching.
>>>
>>> I have currently not implemented in the security module anything that
>> would
>>> cause all wikis to be scanned, and I would really like to avoid that >>> happen. So, it will be difficult to
avoid partial caching, but we
need
to
think
>> limit that at the higher level, the
subwiki. This would allow to had
only
>> scan both the wiki of the user and the
target entry to consider our
cache
>>> valid. It means subwiki will be unable to share groups (I do not > this
>> has ever worked), but it will keep performance on large farm.
>>
>> This would really need to be fixed sooner than later otherwise I know
>>> plenty of projects for which migration to 5.0 would be almost
impossible
>>>>
>>>
>>> I will need helps to achieve that for 5.0
>>
>> ok so before changing anything we need a plan i.e. someone to
>> work on this, right?
>>
>
> Do we really need that for 5.0 ?
> Using the new module as a default does not means the old right service
is
> unavailable. Couldn't we simply define
which case needs to revert to
the
old
modules in the RN, and have 5.0 without this feature ? We may even
release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
does not prevent a user to use the old one until we
properly support that
particular feature.
the
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks
-Vincent
> WDYT ?
>
>
>>
>> Thanks
>> -Vincent
>>
>>>> This would really need to be fixed sooner than later otherwise I
know
>>> plenty of projects for which migration to 5.0 would be almost
impossible
>>>
>>> I think even Workspaces is using that so XEM by default would fail
with
>>>> this.
>>>>
>>>> Ludovic
>>>>
>>>>>
>>>>>>
>>>>>> 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
>>>> 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 ?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:22 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
Le 15/03/13 10:33, Denis Gervalle a écrit :
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
Can you explain why we would need to do that in this case ?
Jérôme.
2013/3/14 Denis Gervalle <dgl(a)softec.lu>
to
targeted
^^^^^^^^
I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these
same individual users grouped by another one (local admin) is very uncommon
delegation of authority to me (but I may be wrong). On the other hand,
having a local admin providing access to local ressources to global group
(and potentially some global users) makes more sense. In that way, the same
admin manage its users, and group its users, and the local admin trust the
global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a
common use case (moreover used by workspace), we should obviously support
it. However, I am convince that evaluating groups based on both the user
and the targeted entity is not easily achievable and conduct to very
complex partial caching.
I have currently not implemented in the security module anything that would
cause all wikis to be scanned, On Thu, Mar 14, 2013 at 11:12 PM, Jerome
Velociter <jerome(a)velociter.fr
> 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 >>> 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.
>>
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 ?
You have got it right. This could be improved, and help is welcome. What
happen is that the user groups are evaluated independently to the entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like
those. The simple display in admin of Global user in local Group is even
broken (double xwiki:xwiki:...) so this does not seems to me a common
usage.
You may provide access to global group in a local wiki to achieve the
same
goals.
This looks to be indeed a big regression. It's quite a common use case to
have only global users and to create groups in the local wiki that refer to
local users.
and I would really like to avoid that to
happen. So, it will be difficult to avoid partial caching, but we need to
limit that at the higher level, the subwiki. This would allow to had only
scan both the wiki of the user and the target entry to consider our cache
valid. It means subwiki will be unable to share groups (I do not think this
has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0
would be almost impossible
I will need helps to achieve that for 5.0
> This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0
would be almost impossible
> I think even Workspaces is using that so XEM by default would fail with
> this.
>
> Ludovic
>
>>> 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<
>> http://lists.xwiki.org/mailman/listinfo/devs>
>>
>>
>> --
>> Denis Gervalle
>> SOFTEC sa - CEO
>> eGuilde sarl - CTO
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
3:11 p.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 2:22 PM, Jerome Velociter <jerome(a)velociter.fr>wrote;wrote:
Le 15/03/13 10:33, Denis Gervalle a écrit :
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
Since it cache all security decisions, it also need to keep track of user
and groups to evict those decisions when some event happen to them. The
simplest would be to know for sure all groups a user is in, so we know the
user is complete or missing from the cache. This would require scanning all
wikis to discover local groups. Obviously, this risk to be really poor on
performance, so I need to introduce support for "partial" caching of users
relations with groups. And I propose to think about it at wiki level, so we
know it will know it have information for this user in a given set of
subwiki. To take a right decision, it will need the user to be cached for
the main wiki, and the wiki the entity is in.
wrote:
2013/3/14 Denis Gervalle <dgl(a)softec.lu>
Can you explain why we would need to do that in this case ?
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <jerome(a)velociter.fr
I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these
same individual users grouped by another one (local admin) is very
uncommon
delegation of authority to me (but I may be wrong). On the other hand,
having a local admin providing access to local ressources to global group
(and potentially some global users) makes more sense. In that way, the
same
admin manage its users, and group its users, and the local admin trust the
global admin to know its users.
That said, I am not against any improvement on the way it works, if it is
a
common use case (moreover used by workspace), we should obviously support
it. However, I am convince that evaluating groups based on both the user
and the targeted entity is not easily achievable and conduct to very
complex partial caching.
I have currently not implemented in the security module anything that
would
cause all wikis to be scanned,
> 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.
>>>
>>> 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 ?
>
> You have got it right. This could be improved, and help is welcome.
What
happen is that the user groups are evaluated independently to the
targeted
entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like
those. The simple display in admin of Global user in local Group is even
broken (double xwiki:xwiki:...) so this does not seems to me a common
usage.
You may provide access to global group in a local wiki to achieve the
same
goals.
This looks to be indeed a big regression. It's quite a common use case
to
have only global users and to create groups in the local wiki that refer
to
local users.
^^^^^^^^
Jérôme.
and I would really like to avoid that to
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
happen. So, it will be difficult to avoid partial
caching, but we need to
limit that at the higher level, the subwiki. This would allow to had only
scan both the wiki of the user and the target entry to consider our cache
valid. It means subwiki will be unable to share groups (I do not think
this
has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
plenty of projects for which migration to 5.0
would be almost impossible
I will need helps to achieve that for 5.0
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0
would be almost impossible
I think even Workspaces is using that so XEM by default would fail with
this.
Ludovic
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<http://lists.xwiki.org/…
> <
>
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
8:42 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
+1 for the idea in general. I'm sure there'll be details to iron out (as pointed
out by Jerome and Ludovic). Maybe a first step (if you haven't already done so) would
be to enable it on your machine (or somewhere else) and build the full codebase to see if
all tests pass. I know quite a few functional that I know will fail and will need to be
updated but they're easy to fix.
As part of this move I'd like that the old auth code be moved to legacy modules too.
But for that to happen we need that friendly xwiki-oriented interface. Without that we
won't be able to update our code to use the new module.
Do you plan to move the security module to commons too?
Thanks
-Vincent
On 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
- 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.
- 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
10:47 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
On Fri, Mar 15, 2013 at 8:42 AM, Vincent Massol <vincent(a)massol.net> wrote:
+1 for the idea in general. I'm sure there'll
be details to iron out (as
pointed out by Jerome and Ludovic). Maybe a first step (if you haven't
already done so) would be to enable it on your machine (or somewhere else)
and build the full codebase to see if all tests pass. I know quite a few
functional that I know will fail and will need to be updated but they're
easy to fix.
I will work on that now, since most seems now favorable to this move.
As part of this move I'd like that the old auth
code be moved to legacy
modules too. But for that to happen we need that friendly xwiki-oriented
interface. Without that we won't be able to update our code to use the new
module.
We may move the old implementation right now (but not sure we need too be
in hurry for that). The new module expose the bridge (that I would like to
mark deprecated as soon as we have an xwiki-oriented interface), so only
the API needs to be kept temporarily.
Regarding the xwiki-oriented interface, the main work is to define it, and
I would like to have others participating in that specs. Writing it should
be quite easy.
Do you plan to move the security module to commons
too?
It is not impossible on mid-terms. It depends what we intent to achieve.
What really link the module to XWiki is the structure of
MainWiki-SubWiki-Space-Document. And I have used some specialized
EntityReference (SecurityReference, UserSecurityReference and
GroupSecurityReference) to support that easily. However, it should not be
too complex to abstract more these SecurityReference.
That said, supporting global users in local groups goes to less
abstractions, and imply the module to knows more about the first two level
(MainWiki-SubWiki) than it does currently.
Thanks
-Vincent
On Mar 14, 2013, at 9:20 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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
- 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.
- 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:42 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
+1 to do the switch right now but I think we need to support global
users in local groups in 5.0, need to be confirmed but I'm pretty sure
it's used in Workspaces.
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
- 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.
- 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
--
Thomas Mortagne
10:41 a.m.
New subject: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
+1 to try it out in 5.0M2.
Thanks,
Marius
On Thu, Mar 14, 2013 at 10: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
- 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.
- 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
4186
days inactive
4204
days old
28 comments
9 participants
participants (9)
-
Caleb James DeLisle -
Denis Gervalle -
Eduard Moraru -
Jean-Vincent Drean -
Jerome Velociter -
Ludovic Dubost -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol