15 Mar
2013
15 Mar
'13
1:58 p.m.
Hi Denis,
On Fri, Mar 15, 2013 at 12:25 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
opposed
common
hand,
the
to
volunteering
It was, but I was not aware that workspace may need (to be confirmed) that
special unsupported case.
As JV and other have already mentioned, this is not a special use case at
all. You also need to consider the fact that with the virtual=1 by default,
we are basically moving to XEM as the default product instead of XE, so
this feature is becoming more important.
In a multiwiki environment, you basically have 2 major use cases:
1) Farm use case, where each wiki is isolated and manages its own local
users and does not interact with other wikis
2) Workspaces(intranets/etc.) use case, where the main wiki is the entry
point and it is in charge of managing the users and the subwikis are shared
locations where global users work on. This means that they need to be given
access to those wikis, based on their needs, and this implies that global
users need to become members of local groups (subwiki:XWiki.XWikiAllGroup).
The alternative of giving individual (per-user) wiki-level rights (in each
subwiki) is just not practical.
Hope this helped,
Eduard
I am just saying that while I would like the new module as a default, this
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
while
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
>>
>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>>
>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
>> wrote:
>>>
>>>> 2013/3/14 Denis Gervalle <dgl(a)softec.lu>
>>>>
>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>> jerome(a)velociter.fr
>>>>>> wrote:
>>>>>
>>>>>> Hi Denis,
>>>>>>
>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>>>>>>
>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle
<dgl(a)softec.lu>
>>>> wrote:
>>>>>>>
>>>>>>> Hi devs,
>>>>>>>>
>>>>>>>> We have a new (component based) authorization module
since a >>>> now,
>>>>>>>> and I think 5.0 is the perfect time to introduce it as
the
default
>>>> right
>>>>>>> service. First, I simply propose to change the default in
xwiki.cfg:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>
>>>>>>> internal.**XWikiCachingRightService
>>>>>>>
>>>>>>> (Later, I propose that we deprecate that bridge and that we
create a
>>>>>>> friendly (xwiki
oriented) interface over the more generic
>>>>>>> org.xwiki.security.**authorization.**AuthorizationManager.
But
leave
>>>>>>>> this for a
>>>>>>>> later proposal.)
>>>>>>>>
>>>>>>>> So this vote is about changing the default in xwiki.cfg
before
>> 5.0M2.
>>>>>>>>
>>>>>>>> pros:
>>>>>>>> - improved performance, since the new service is using
caching
>>>>>>>> techniques
>>>>>>>> and a single page load required lots of calls to it.
>>>>>>>> - ability for extension to add new rights
>>>>>>>> - define right declaratively
>>>>>>>> - separate method for checking and verifying right
(throws >>>> to
>>>>>>>> boolean return)
>>>>>>>> - fix some long waiting bugs like XWIKI-5174,
XWIKI-6987, as
well
>>>> as
>>>>>>>> some unstated ones
>>>>>>>>
>>>>>>>> Also XWIKI-4550
>>>>>>>
>>>>>>> - possibility to easily solve issues like XWIKI-4491
>>>>>>>> - no more admin right per default
>>>>>>>> - being in good position to improve it and release
dependencies
to
>>>>>>>> oldcore for
security matters.
>>>>>>>> - possibility for third party to adapt the right settler
to
their
>>>>>>>> special
>>>>>>>> needs (right decision is plugable)
>>>>>>>> - a consistant right evaluation with very few exception
that
could
>>>> be
>>>>>>>> explained and documented
>>>>>>>>
>>>>>>>> cons:
>>>>>>>> - no more admin right per default, but since we have DW,
the
>>>> initial
>>>>>>>> setup is no more a problem, and advanced users may use
superadmin.
>>>>>>> - groups are only checked from the user wiki, not from the
accessed
>>>>>>>> entity wiki.
>>>>>>>>
>>>>>>>
>>>>>> This sound like a big regression.
>>>>>>
>>>>>> Can you explicit more ? Does this mean that adding a global
(main
>> wiki)
>>>>>> user in a local group has no effect ?
>>>>>>
>>>>>
>>>>> You have got it right. This could be improved, and help is welcome.
>> What
>>>>> happen is that the user groups are evaluated independently to the
>>>> targeted
>>>>> entity, and therefore only in the user wiki.
>>>>>
>>>>> I admit this is a regression, but I have not cross lots of use case
>> like
>>>>> those. The simple display in admin of Global user in local Group is
>> even
>>>>> broken (double xwiki:xwiki:...) so this does not seems to me a
>>>>> usage.
>>>>> You may provide access to global group in a local wiki to achieve
the
>>>> same
>>>>> goals.
>>>>>
>>>>>
>>>> This looks to be indeed a big regression. It's quite a common use
case
> to
>>> have only global users and to create groups in the local wiki that
> refer to
>>> local users.
>>>
>> ^^^^^^^^
>> I suppose you means global users here.
>>
>> IMHO, having user managed by a separate entity (global admin), and
these
>>> same individual users grouped by another one (local admin) is very
>> uncommon
>>> delegation of authority to me (but I may be wrong). On the other >>
having a local admin providing access to local ressources to global
group
>>> (and potentially some global users) makes more sense. In that way, >> same
>>> admin manage its users, and group its users, and the local admin
trust
>> the
>>> global admin to know its users.
>>>
>>> That said, I am not against any improvement on the way it works, if
it
> is a
>> common use case (moreover used by workspace), we should obviously
support
>> it. However, I am convince that
evaluating groups based on both the
user
>>> and the targeted entity is not easily achievable and conduct to very
>>> complex partial caching.
>>>
>>> I have currently not implemented in the security module anything that
>> would
>>> cause all wikis to be scanned, and I would really like to avoid that >>> happen. So, it will be difficult to
avoid partial caching, but we
need
to
think
>> limit that at the higher level, the
subwiki. This would allow to had
only
>> scan both the wiki of the user and the
target entry to consider our
cache
>>> valid. It means subwiki will be unable to share groups (I do not > this
>> has ever worked), but it will keep performance on large farm.
>>
>> This would really need to be fixed sooner than later otherwise I know
>>> plenty of projects for which migration to 5.0 would be almost
impossible
>>>>
>>>
>>> I will need helps to achieve that for 5.0
>>
>> ok so before changing anything we need a plan i.e. someone to
>> work on this, right?
>>
>
> Do we really need that for 5.0 ?
> Using the new module as a default does not means the old right service
is
> unavailable. Couldn't we simply define
which case needs to revert to
the
old
modules in the RN, and have 5.0 without this feature ? We may even
release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
does not prevent a user to use the old one until we
properly support that
particular feature.
the
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks
-Vincent
> WDYT ?
>
>
>>
>> Thanks
>> -Vincent
>>
>>>> This would really need to be fixed sooner than later otherwise I
know
>>> plenty of projects for which migration to 5.0 would be almost
impossible
>>>
>>> I think even Workspaces is using that so XEM by default would fail
with
>>>> this.
>>>>
>>>> Ludovic
>>>>
>>>>>
>>>>>>
>>>>>> Jérôme
>>>>>>
>>>>>>
>>>>>> - may exhibit some other minor differences compare to existing
>>>>>>>> implementation (but mostly consistency fixes)
>>>>>>>> - test could be improved, critical part (right, settler,
data
>>>>>>>> structure,
>>>>>>>> cache) are covered at almost 100%, api at 60%, this is
probably
>>>> better
>>>>>>>> than the old right service
>>>>>>>> - documentation should be improved, but this is not
worse than
>>>> old
>>>>>>> one anyway
>>>>>>>
>>>>>>> Since I use the new module in all my production servers for
several
>>>>>>> months
>>>>>>> with success, and I really think that if we do not do it now
we
will
>>>>>>> never
>>>>>>> go ahead, here is my big +1
>>>>>>>
>>>>>>> WDYT ?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs