On Thu, Nov 27, 2008 at 12:37 PM, Denis Gervalle <dgl(a)softec.st> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne