28 Nov
2008
28 Nov
'08
4:01 p.m.
On Fri, Nov 28, 2008 at 3:39 PM, Denis Gervalle <dgl(a)softec.st> 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:
--
Thomas Mortagne
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks for your comments...
Denis
--
Denis Gervalle
SOFTEC sa
http://www.softec.st
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs