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