[VOTE] Use the new security-authorization module per default in XWiki 5.0

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Use the new security-authorization module per default in XWiki 5.0

Eduard Moraru
Hi Denis,

On Fri, Mar 15, 2013 at 12:25 PM, Denis Gervalle <[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[hidden email]>
> wrote:
>
> >
> > On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:
> >
> > > On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]>
> > wrote:
> > >
> > >>
> > >> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
> > >>
> > >>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]>
> > >> wrote:
> > >>>
> > >>>> 2013/3/14 Denis Gervalle <[hidden email]>
> > >>>>
> > >>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
> > >> [hidden email]
> > >>>>>> wrote:
> > >>>>>
> > >>>>>> Hi Denis,
> > >>>>>>
> > >>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
> > >>>>>>
> > >>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
> > >>>> 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.
>

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

> does not prevent a user to use the old one until we properly support that
> particular feature.
>
>
> >
> > 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
> 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
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Use the new security-authorization module per default in XWiki 5.0

Jérôme Velociter
In reply to this post by Denis Gervalle-2
Le 15/03/13 10:33, Denis Gervalle a écrit :

> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]> wrote:
>
>> 2013/3/14 Denis Gervalle <[hidden email]>
>>
>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[hidden email]
>>>> wrote:
>>>> Hi Denis,
>>>>
>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>>>>
>>>>   On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
>> 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,

Can you explain why we would need to do that in this case ?

Jérôme.

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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Use the new security-authorization module per default in XWiki 5.0

Denis Gervalle-2
On Fri, Mar 15, 2013 at 2:22 PM, Jerome Velociter <[hidden email]>wrote:

> Le 15/03/13 10:33, Denis Gervalle a écrit :
>
>  On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]>
>> wrote:
>>
>>  2013/3/14 Denis Gervalle <[hidden email]>
>>>
>>>  On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[hidden email]
>>>>
>>>>> wrote:
>>>>> Hi Denis,
>>>>>
>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>>>>>
>>>>>   On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
>>>>>
>>>> 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,
>>
>
> Can you explain why we would need to do that in this case ?
>

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.


>
> Jérôme.
>
>
>    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
>>>>> [hidden email]
>>>>> http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/**mailman/listinfo/devs>
>>>>> <
>>>>>
>>>> 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
>>>> [hidden email]
>>>> http://lists.xwiki.org/**mailman/listinfo/devs<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
>>> [hidden email]
>>> http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>>>
>>>
>>
>>
> ______________________________**_________________
> devs mailing list
> [hidden email]
> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Use the new security-authorization module per default in XWiki 5.0

Denis Gervalle-2
In reply to this post by vmassol
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[hidden email]> wrote:

>
> On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[hidden email]> wrote:
>
> > On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[hidden email]>
> wrote:
> >
> >> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[hidden email]> wrote:
> >>> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[hidden email]>
> >> wrote:
> >>>
> >>>>
> >>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:
> >>>>
> >>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]
> >
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
> >>>>>>
> >>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> 2013/3/14 Denis Gervalle <[hidden email]>
> >>>>>>>>
> >>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
> >>>>>> [hidden email]
> >>>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi Denis,
> >>>>>>>>>>
> >>>>>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
> >>>>>>>> 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 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 ?


>
> Thanks
> -Vincent
>
> > See my reply to Ludovic for more about how we need to work on that
> missing
> > feature.
> >
> >
> >>
> >> JV.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Use the new security-authorization module per default in XWiki 5.0

vmassol
Administrator

On Mar 15, 2013, at 8:44 PM, Denis Gervalle <[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>> On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[hidden email]> wrote:
>>
>>> On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[hidden email]>
>> wrote:
>>>
>>>> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[hidden email]> wrote:
>>>>> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[hidden email]>
>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:
>>>>>>
>>>>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]
>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]
>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 2013/3/14 Denis Gervalle <[hidden email]>
>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>>>>>>>> [hidden email]
>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Denis,
>>>>>>>>>>>>
>>>>>>>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
>>>>>>>>>> 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 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 ?

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

>> Thanks
>> -Vincent
>>
>>> See my reply to Ludovic for more about how we need to work on that
>> missing
>>> feature.
>>>
>>>
>>>>
>>>> JV.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Use the new security-authorization module per default in XWiki 5.0

Thomas Mortagne
Administrator
In reply to this post by Denis Gervalle-2
On Fri, Mar 15, 2013 at 8:44 PM, Denis Gervalle <[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>> On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[hidden email]> wrote:
>>
>> > On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[hidden email]>
>> wrote:
>> >
>> >> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[hidden email]> wrote:
>> >>> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[hidden email]>
>> >> wrote:
>> >>>
>> >>>>
>> >>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:
>> >>>>
>> >>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]
>> >
>> >>>> wrote:
>> >>>>>
>> >>>>>>
>> >>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
>> >>>>>>
>> >>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]
>> >
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> 2013/3/14 Denis Gervalle <[hidden email]>
>> >>>>>>>>
>> >>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>> >>>>>> [hidden email]
>> >>>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Hi Denis,
>> >>>>>>>>>>
>> >>>>>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>> >>>>>>>>>>
>> >>>>>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
>> >>>>>>>> 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 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 ?

+1

>
>
>>
>> Thanks
>> -Vincent
>>
>> > See my reply to Ludovic for more about how we need to work on that
>> missing
>> > feature.
>> >
>> >
>> >>
>> >> JV.
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Use the new security-authorization module per default in XWiki 5.0

Marius Dumitru Florea
In reply to this post by Denis Gervalle-2
On Fri, Mar 15, 2013 at 9:44 PM, Denis Gervalle <[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>> On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[hidden email]> wrote:
>>
>> > On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[hidden email]>
>> wrote:
>> >
>> >> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[hidden email]> wrote:
>> >>> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[hidden email]>
>> >> wrote:
>> >>>
>> >>>>
>> >>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:
>> >>>>
>> >>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]
>> >
>> >>>> wrote:
>> >>>>>
>> >>>>>>
>> >>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
>> >>>>>>
>> >>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]
>> >
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> 2013/3/14 Denis Gervalle <[hidden email]>
>> >>>>>>>>
>> >>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>> >>>>>> [hidden email]
>> >>>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Hi Denis,
>> >>>>>>>>>>
>> >>>>>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>> >>>>>>>>>>
>> >>>>>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
>> >>>>>>>> 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 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 ?

+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
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Use the new security-authorization module per default in XWiki 5.0

Denis Gervalle-2
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 <
[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 9:44 PM, Denis Gervalle <[hidden email]> wrote:
> > On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[hidden email]>
> wrote:
> >
> >>
> >> On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[hidden email]> wrote:
> >>
> >> > On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[hidden email]>
> >> wrote:
> >> >
> >> >> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[hidden email]>
> wrote:
> >> >>> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <
> [hidden email]>
> >> >> wrote:
> >> >>>
> >> >>>>
> >> >>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]>
> wrote:
> >> >>>>
> >> >>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <
> [hidden email]
> >> >
> >> >>>> wrote:
> >> >>>>>
> >> >>>>>>
> >> >>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]>
> wrote:
> >> >>>>>>
> >> >>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <
> [hidden email]
> >> >
> >> >>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>> 2013/3/14 Denis Gervalle <[hidden email]>
> >> >>>>>>>>
> >> >>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
> >> >>>>>> [hidden email]
> >> >>>>>>>>>> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>>> Hi Denis,
> >> >>>>>>>>>>
> >> >>>>>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
> >> >>>>>>>>>>
> >> >>>>>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <
> [hidden email]>
> >> >>>>>>>> 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
> 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 ?
>
> +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
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >
> >
> >
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > eGuilde sarl - CTO
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Use the new security-authorization module per default in XWiki 5.0

Denis Gervalle-2
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 <[hidden email]> 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 <
> [hidden email]> wrote:
>
>> On Fri, Mar 15, 2013 at 9:44 PM, Denis Gervalle <[hidden email]> wrote:
>> > On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[hidden email]>
>> wrote:
>> >
>> >>
>> >> On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[hidden email]> wrote:
>> >>
>> >> > On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[hidden email]>
>> >> wrote:
>> >> >
>> >> >> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[hidden email]>
>> wrote:
>> >> >>> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <
>> [hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>>>
>> >> >>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]>
>> wrote:
>> >> >>>>
>> >> >>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <
>> [hidden email]
>> >> >
>> >> >>>> wrote:
>> >> >>>>>
>> >> >>>>>>
>> >> >>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]>
>> wrote:
>> >> >>>>>>
>> >> >>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <
>> [hidden email]
>> >> >
>> >> >>>>>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>> 2013/3/14 Denis Gervalle <[hidden email]>
>> >> >>>>>>>>
>> >> >>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>> >> >>>>>> [hidden email]
>> >> >>>>>>>>>> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>>> Hi Denis,
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <
>> [hidden email]>
>> >> >>>>>>>> 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
>> 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 ?
>>
>> +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
>> >> [hidden email]
>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>
>> >
>> >
>> >
>> > --
>> > Denis Gervalle
>> > SOFTEC sa - CEO
>> > eGuilde sarl - CTO
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
12