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.
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
