On Mar 15, 2013, at 8:44 PM, Denis Gervalle <[email protected]> wrote: > On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[email protected]> wrote: > >> >> On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[email protected]> wrote: >> >>> On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[email protected]> >> wrote: >>> >>>> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]> wrote: >>>>> 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 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
