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… 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
