On Fri, Nov 28, 2008 at 3:39 PM, Denis Gervalle <[EMAIL PROTECTED]> wrote: > Nice idea, telling the wiki that the script is secure enought to be > included from insecure document seems to be a very secure solution. > But you should take care of deep inclusion, and what would be the > logic ? B is set secure and have programming rights, A does not have > programming rigths, C does and is insecure, do you consider that C has > programming rights when included by A through B ? > That could be nice, imagine, C is a generic class runner, B choose the > class, A is the user document. If A were able to include C, any class > could be loaded, but through B, only those that B decide upon. Yes > this could definitely be a nice solution, but it has to be design > properly.
We could start by just considering recursively: allow = contentdoc.programming || (sdoc.programming && sdoc.secure) > > However, if you should go to this complexity, since we have supported > the less secure option for long now in velocity, and this does not > seems to have receive a bad feedback. So why not just treat groovy as > we treat velocity since the beginning ? > Moreover, if I were to chose, since velocity programming does not > require programming rights, I feel it is more sensible to get > influenced than groovy could be, if you respect some simple security > rules. We will need some votes here and i'm not strongly +1 or -1 on it, I'm just concerned about being less secure in general but since Velocity is already working the free way I guess we can enable it for groovy too. > > Denis > PS: I wonder if macro written in groovy requires programming rights... > > On 28 nov. 08, at 15:13, Thomas Mortagne wrote: >> >> I totally agreed than we can't have two way of managing programming >> rights here. >> >> But I'm not sure about what is the good answer. >> >> Use containing document to test programing rights: >> * Cons: >> - security: it means the groovy script has to be very careful of >> what it is doing because a document which include it can influence it >> be providing its and own objects. >> >> * Pros: >> - it makes possible to use groovy on private api for Sheet pages >> like users profiles sheet page in Deni's use case >> >> I see another solution: add some document's metadata indicating if the >> script can be included by some other document meaning that the >> programming rights can be tester on the included document or not. It >> would be false by default. This way someone with programming right can >> do some scipt in a page and explicitly indicate this can be used by >> non-programming document authors. >> >>> Thanks for your comments... >>> >>> Denis >>> >>> -- >>> Denis Gervalle >>> SOFTEC sa >>> http://www.softec.st >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
