On Fri, 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 ?
+1 > > >> >> 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 >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
