On Thu, Nov 27, 2008 at 12:37 PM, Denis Gervalle <[EMAIL PROTECTED]> wrote:
> Hi,
>
> There is a major discrepancy in the way the programming rights are
> evaluated for the access to the privileged API from velocity compare
> to the right to execute groovy code.
>
> In the API, the right to access a priviledged API is evaluated against
> the sdoc in the current context, which is the document that contains
> the currently executed velocity code. Here is the code extracted from
> the current RightService implementation that does so:
>
> public boolean hasProgrammingRights(XWikiContext context)
> {
> XWikiDocument sdoc = (XWikiDocument) context.get("sdoc");
> if (sdoc == null)
> sdoc = context.getDoc();
> return hasProgrammingRights(sdoc, context);
> }
>
> In the XWikiGroovyRenderer, the right to render a groovy code is
> evaluated against the content doc, which is the top-level document
> that have directly or indirectly included the document that contains
> the evaluated groovy code. Here the excerpt from the code that made
> this check:
>
> if (!
> context.getWiki().getRightService().hasProgrammingRights(contentdoc,
> context)) {
> return content;
> }
>
> These are two opposed methods.
> As a direct consequence, a Sheet document (ie XWikiUserSheet) may be
> developed in velocity and use the priviledged API, but it is
> impossible to put a single line of Groovy in it, since the "instance"
> of the template documents that include the Sheet are usually created
> by users without programming rights.
>
> The debate is now, what is the original or current intend. Do you want:
> 1) to have a very secure situation, and therefore change
> hasProgrammingRights() implementation (why do we have a sdoc than?), or
> 2) to have a flexible, more responsible solution, were user having
> programming rights should take care not writing risky code, and
> therefore change the groovy renderer to accept groovy code based on
> contextdoc (sdoc in that place), so groovy and velocity gets the same
> access level ?
>
> The current situation is for me not acceptable, since it is a mix of
> 1) and 2) depending on the language, and there is no reason that the
> language influence the rights you have.
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
