[xwiki-devs] new rendering syntax concerning Groovy
Hello, Do you foresee a special syntax for groovy scripts as you already have for velocity using {{velocity}} with some more features? My idea is to be able to code cleanly using groovy and to put some "generic" part of scripts in separated documents and to be able to import them in other docs containing other parts of scripts. It would be really nice to be able to type some part of scripts or to define some groovy classes in a page and tell "this is groovy code which is not "WIKI-renderable" as is". Then we could simply import/include this script in another page (just paste the code without any rendering) using something like #include("MySpace.MyGroovyDoc"). xwiki.parseGroovyXXX is useful sometimes but not when you only want to include some part of scripts. Existing #includeXXX macros always render the content and here I only want to paste a script from somewhere else (xwiki.getDocument("").getContent() in fact) Moreover the idea would be also to allow using both "xwiki.parseGroovy" and the #include macro for the same groovy "document". For the time being, one need to use the trick /* groovygroovy #* */ /* *# */ and then you are condemned to use xwiki.parseGroovyXXX because no other function can interprete this tricky syntax. best regards Pascal
Hi Pascal, A {{groovy}} macro is planned. However what you seem to be asking for might cause some security issues. Groovy needs to be limited to "Programmer" authors so we are trying to avoid complex includes of groovy code that could lead to inject groovy code. Could you give a use case with an example of what you would like to achieve using groovy ? Is it something like that ---- text text text {{groovy}} {{include:MySpace.GroovyDoc}} other groovy code {{groovy}} text text test ---- And MySpace.GroovyDoc is a pure text file containing groovy code ? If we implement this it would mean checking that MySpace.GroovyDoc and the current page are own by priviledge users. So the include would need to know it is in the context of a {{groovy}} macro. It also depends when the {{groovy}} macro runs and if we allow the {{include}} to run in this context. Ludovic Pascal Voitot wrote:
Hello,
Do you foresee a special syntax for groovy scripts as you already have for velocity using {{velocity}} with some more features?
My idea is to be able to code cleanly using groovy and to put some "generic" part of scripts in separated documents and to be able to import them in other docs containing other parts of scripts.
It would be really nice to be able to type some part of scripts or to define some groovy classes in a page and tell "this is groovy code which is not "WIKI-renderable" as is". Then we could simply import/include this script in another page (just paste the code without any rendering) using something like #include("MySpace.MyGroovyDoc").
xwiki.parseGroovyXXX is useful sometimes but not when you only want to include some part of scripts. Existing #includeXXX macros always render the content and here I only want to paste a script from somewhere else (xwiki.getDocument("").getContent() in fact)
Moreover the idea would be also to allow using both "xwiki.parseGroovy" and the #include macro for the same groovy "document". For the time being, one need to use the trick /* groovygroovy #* */ /* *# */
and then you are condemned to use xwiki.parseGroovyXXX because no other function can interprete this tricky syntax.
best regards Pascal _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hello, please see below... On Tue, Aug 5, 2008 at 9:49 AM, Ludovic Dubost <[email protected]> wrote:
Hi Pascal,
A {{groovy}} macro is planned. However what you seem to be asking for might cause some security issues. Groovy needs to be limited to "Programmer" authors so we are trying to avoid complex includes of groovy code that could lead to inject groovy code.
You're right about the security issue! I was only thinking about my coding issue but not about this important issue :)
Could you give a use case with an example of what you would like to achieve using groovy ?
Is it something like that
---- text text text
{{groovy}}
{{include:MySpace.GroovyDoc}}
other groovy code
{{groovy}}
text text test ----
it could be something like that in an ideal world
And MySpace.GroovyDoc is a pure text file containing groovy code ?
If we implement this it would mean checking that MySpace.GroovyDoc and the current page are own by priviledge users. So the include would need to know it is in the context of a {{groovy}} macro. It also depends when the {{groovy}} macro runs and if we allow the {{include}} to run in this context.
I agree with you, this is not simple in this context. Anyway, I have a question: Groovy is programmed by a programmer with special rights but it can be executed by anyone. Am I right? (apparently this is the default behaviour I can see) What prevents anyone with edit rights to add $xwiki.parseGroovy in his velocity script (do you need programming rights for this) ? Moreover if you put in a document something like this: {pre} <% I do some groovy things %> {/pre} then in another one you put # some velocity things $xwiki.getDocument("GroovyDoc").getContent() # some other things Is the groovy simply injected here and executed when someone with default rights access the last doc? (Apparently with default rights, that's what happened... I may have missed something) Pascal
Ludovic
Pascal Voitot wrote:
Hello,
Do you foresee a special syntax for groovy scripts as you already have for velocity using {{velocity}} with some more features?
My idea is to be able to code cleanly using groovy and to put some "generic" part of scripts in separated documents and to be able to import them in other docs containing other parts of scripts.
It would be really nice to be able to type some part of scripts or to define some groovy classes in a page and tell "this is groovy code which is not "WIKI-renderable" as is". Then we could simply import/include this script in another page (just paste the code without any rendering) using something like #include("MySpace.MyGroovyDoc").
xwiki.parseGroovyXXX is useful sometimes but not when you only want to include some part of scripts. Existing #includeXXX macros always render the content and here I only want to paste a script from somewhere else (xwiki.getDocument("").getContent() in fact)
Moreover the idea would be also to allow using both "xwiki.parseGroovy" and the #include macro for the same groovy "document". For the time being, one need to use the trick /* groovygroovy #* */ /* *# */
and then you are condemned to use xwiki.parseGroovyXXX because no other function can interprete this tricky syntax.
best regards Pascal _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Pascal Voitot wrote:
I agree with you, this is not simple in this context.
Anyway, I have a question: Groovy is programmed by a programmer with special rights but it can be executed by anyone. Am I right? (apparently this is the default behaviour I can see) What prevents anyone with edit rights to add $xwiki.parseGroovy in his velocity script (do you need programming rights for this) ?
The groovy script needs to be own by a programmer. This is the responsibility of the programmer to do a groovy script that is secure or to do himself checkProgrammingRights in his code. If he does then the page doing parseGroovyFromPage needs programming rights. parseGroovyFromString always needs programming rights.
Moreover if you put in a document something like this:
{pre} <% I do some groovy things %> {/pre}
then in another one you put
# some velocity things $xwiki.getDocument("GroovyDoc").getContent() # some other things
Is the groovy simply injected here and executed when someone with default rights access the last doc? (Apparently with default rights, that's what happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be parsed. Mixing velocity with groovy is dangerous, because You could beat the groovy cache if the script passed to groovy is different on every evaluation. This can lead to high memory usage. Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
So, this is the responsability of the programmer to control the access to his code... This is quite free but requires a good knowledge about what you do... (I wonder wether providing the {{include}} macros would bring much more dangerous issues in this case apart from the memory issue you evoked) Does parseGroovy takes care about not duplicating script parsing to prevent groovy parser from plundering memory? I need to think about all of this because Groovy integrated in xwiki with velocity also is so much powerful to my mind that it might be worth digging into it... Pascal On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <[email protected]> wrote:
Pascal Voitot wrote:
I agree with you, this is not simple in this context.
Anyway, I have a question: Groovy is programmed by a programmer with special rights but it can be executed by anyone. Am I right? (apparently this is the default behaviour
I
can see) What prevents anyone with edit rights to add $xwiki.parseGroovy in his velocity script (do you need programming rights for this) ?
The groovy script needs to be own by a programmer. This is the responsibility of the programmer to do a groovy script that is secure or to do himself checkProgrammingRights in his code. If he does then the page doing parseGroovyFromPage needs programming rights. parseGroovyFromString always needs programming rights.
Moreover if you put in a document something like this:
{pre} <% I do some groovy things %> {/pre}
then in another one you put
# some velocity things $xwiki.getDocument("GroovyDoc").getContent() # some other things
Is the groovy simply injected here and executed when someone with default rights access the last doc? (Apparently with default rights, that's what happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be parsed. Mixing velocity with groovy is dangerous, because You could beat the groovy cache if the script passed to groovy is different on every evaluation. This can lead to high memory usage.
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Pascal Voitot wrote:
So, this is the responsability of the programmer to control the access to his code... This is quite free but requires a good knowledge about what you do... (I wonder wether providing the {{include}} macros would bring much more dangerous issues in this case apart from the memory issue you evoked)
Does parseGroovy takes care about not duplicating script parsing to prevent groovy parser from plundering memory?
Yes parseGroovy is cached (the class is only compiled once). It also allows good separation between priviledge code and user code. Programmers can write complex code + velocity macros, and less experienced users can use these macros or classes. Ludovic
I need to think about all of this because Groovy integrated in xwiki with velocity also is so much powerful to my mind that it might be worth digging into it...
Pascal
On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <[email protected]> wrote:
Pascal Voitot wrote:
I agree with you, this is not simple in this context.
Anyway, I have a question: Groovy is programmed by a programmer with special rights but it can be executed by anyone. Am I right? (apparently this is the default behaviour
I
can see) What prevents anyone with edit rights to add $xwiki.parseGroovy in his velocity script (do you need programming rights for this) ?
The groovy script needs to be own by a programmer. This is the responsibility of the programmer to do a groovy script that is secure or to do himself checkProgrammingRights in his code. If he does then the page doing parseGroovyFromPage needs programming rights. parseGroovyFromString always needs programming rights.
Moreover if you put in a document something like this:
{pre} <% I do some groovy things %> {/pre}
then in another one you put
# some velocity things $xwiki.getDocument("GroovyDoc").getContent() # some other things
Is the groovy simply injected here and executed when someone with default rights access the last doc? (Apparently with default rights, that's what happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be parsed. Mixing velocity with groovy is dangerous, because You could beat the groovy cache if the script passed to groovy is different on every evaluation. This can lead to high memory usage.
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Tue, Aug 5, 2008 at 10:55 AM, Ludovic Dubost <[email protected]> wrote:
Pascal Voitot wrote:
So, this is the responsability of the programmer to control the access to his code... This is quite free but requires a good knowledge about what you do... (I wonder wether providing the {{include}} macros would bring much more dangerous issues in this case apart from the memory issue you evoked)
Does parseGroovy takes care about not duplicating script parsing to prevent groovy parser from plundering memory?
Yes parseGroovy is cached (the class is only compiled once). It also allows good separation between priviledge code and user code. Programmers can write complex code + velocity macros, and less experienced users can use these macros or classes.
Finally, this might not be a bad choice even if it brings some constraints... Do you intend to write some precise docs about this because this is not really clear without wandering for some time... one last question (I'm lazy so I prefer asking than thinking ;)): Where do you advise to put user.hasProgrammingRight() ? If you don't put it in the doc called by parseGroovy, I don't see the interest... Then do you put it outside the groovy part using velocity: if($user.hasProgrammingRights) { /* groovy part */ } (maybe this is not clever due to the mixing of velocity with groovy) or in the groovy part ? In both case, it will generate an exception as parseGroovy will fail. How to have a clean "you don't have access to this content" Pascal
Ludovic
I need to think about all of this because Groovy integrated in xwiki with velocity also is so much powerful to my mind that it might be worth digging into it...
Pascal
On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <[email protected]> wrote:
Pascal Voitot wrote:
I agree with you, this is not simple in this context.
Anyway, I have a question: Groovy is programmed by a programmer with special rights but it can be executed by anyone. Am I right? (apparently this is the default behaviour
I
can see) What prevents anyone with edit rights to add $xwiki.parseGroovy in his velocity script (do you need programming rights for this) ?
The groovy script needs to be own by a programmer. This is the responsibility of the programmer to do a groovy script that is secure or to do himself checkProgrammingRights in his code. If he does then the page doing parseGroovyFromPage needs programming rights. parseGroovyFromString always needs programming rights.
Moreover if you put in a document something like this:
{pre} <% I do some groovy things %> {/pre}
then in another one you put
# some velocity things $xwiki.getDocument("GroovyDoc").getContent() # some other things
Is the groovy simply injected here and executed when someone with default rights access the last doc? (Apparently with default rights, that's what happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be parsed. Mixing velocity with groovy is dangerous, because You could beat the groovy cache if the script passed to groovy is different on every evaluation. This can lead to high memory usage.
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I'm a bit stupid... In a previous mail, you told that the checkProgrammingRights should be done in the code directly... Is it true? In fact, I'm a bit lost reading everything again :) The programmer programs the groovy script, that's a fact... Can users access a document calling $xwiki.parseGroovy without programming rights and execute the groovy script? (apparently yes in my tests) Or do you strongly advise programmers to prevent users from using groovy scripts when they don't have programming rights using checkProgrammingRights? Sorry for disturbing you ;) PAscal On Tue, Aug 5, 2008 at 11:08 AM, Pascal Voitot <[email protected]>wrote:
On Tue, Aug 5, 2008 at 10:55 AM, Ludovic Dubost <[email protected]> wrote:
Pascal Voitot wrote:
So, this is the responsability of the programmer to control the access to his code... This is quite free but requires a good knowledge about what you do... (I wonder wether providing the {{include}} macros would bring much more dangerous issues in this case apart from the memory issue you evoked)
Does parseGroovy takes care about not duplicating script parsing to prevent groovy parser from plundering memory?
Yes parseGroovy is cached (the class is only compiled once). It also allows good separation between priviledge code and user code. Programmers can write complex code + velocity macros, and less experienced users can use these macros or classes.
Finally, this might not be a bad choice even if it brings some constraints... Do you intend to write some precise docs about this because this is not really clear without wandering for some time...
one last question (I'm lazy so I prefer asking than thinking ;)): Where do you advise to put user.hasProgrammingRight() ? If you don't put it in the doc called by parseGroovy, I don't see the interest... Then do you put it outside the groovy part using velocity: if($user.hasProgrammingRights) { /* groovy part */ } (maybe this is not clever due to the mixing of velocity with groovy) or in the groovy part ? In both case, it will generate an exception as parseGroovy will fail. How to have a clean "you don't have access to this content"
Pascal
Ludovic
I need to think about all of this because Groovy integrated in xwiki with velocity also is so much powerful to my mind that it might be worth digging into it...
Pascal
On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <[email protected]> wrote:
Pascal Voitot wrote:
I agree with you, this is not simple in this context.
Anyway, I have a question: Groovy is programmed by a programmer with special rights but it can be executed by anyone. Am I right? (apparently this is the default behaviour
I
can see) What prevents anyone with edit rights to add $xwiki.parseGroovy in his velocity script (do you need programming rights for this) ?
The groovy script needs to be own by a programmer. This is the responsibility of the programmer to do a groovy script that is secure or to do himself checkProgrammingRights in his code. If he does then the page doing parseGroovyFromPage needs programming rights. parseGroovyFromString always needs programming rights.
Moreover if you put in a document something like this:
{pre} <% I do some groovy things %> {/pre}
then in another one you put
# some velocity things $xwiki.getDocument("GroovyDoc").getContent() # some other things
Is the groovy simply injected here and executed when someone with default rights access the last doc? (Apparently with default rights, that's what happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be parsed. Mixing velocity with groovy is dangerous, because You could beat the groovy cache if the script passed to groovy is different on every evaluation. This can lead to high memory usage.
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Let's take an example public class Groovy { public boolean delete(String docname, Context context) { def xwiki = context.getWiki(); def xwiki2 = xwiki.xWiki; def context2 = context.context; xwiki2.deleteDocument(docName, context2); return true; } } This script is a priviledge script and will use the underlying xwiki api. This means that no rights check are performed on the call to xwiki2.deleteDocument. If you let this class in your wiki, any use can use parseGroovyFromPage to instanciate the class and call delete() and delete any page regardeless of the user rights. To fix this you do: public class Groovy { public boolean delete(String docname, Context context) { if (!context.hasProgrammingRights()) return false; def xwiki = context.getWiki(); def xwiki2 = xwiki.xWiki; def context2 = context.context; xwiki2.deleteDocument(docName, context2); return true; } } If the author of the page making the call to parseGroovyFromPage and deleteDocument is not a "programmer" then the call fails. For example if the page is $xwiki.parseGroovyFromPage("..").deleteDocument($context.user,$context) Then any use can access the page setup by the programmer to delete it's own page. If the user tries to change the page to replace by $context.user by any page, then the programmers right is revoked and the call fails Therefore you delete() function is secure. Ludovic Pascal Voitot wrote:
I'm a bit stupid... In a previous mail, you told that the checkProgrammingRights should be done in the code directly... Is it true?
In fact, I'm a bit lost reading everything again :)
The programmer programs the groovy script, that's a fact... Can users access a document calling $xwiki.parseGroovy without programming rights and execute the groovy script? (apparently yes in my tests) Or do you strongly advise programmers to prevent users from using groovy scripts when they don't have programming rights using checkProgrammingRights?
Sorry for disturbing you ;)
PAscal
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
see below On Tue, Aug 5, 2008 at 6:52 PM, Ludovic Dubost <[email protected]> wrote:
Let's take an example
public class Groovy {
public boolean delete(String docname, Context context) { def xwiki = context.getWiki(); def xwiki2 = xwiki.xWiki; def context2 = context.context;
xwiki2.deleteDocument(docName, context2); return true; } }
This script is a priviledge script and will use the underlying xwiki api. This means that no rights check are performed on the call to xwiki2.deleteDocument. If you let this class in your wiki, any use can use parseGroovyFromPage to instanciate the class and call delete() and delete any page regardeless of the user rights.
To fix this you do:
public class Groovy {
public boolean delete(String docname, Context context) { if (!context.hasProgrammingRights()) return false;
def xwiki = context.getWiki(); def xwiki2 = xwiki.xWiki; def context2 = context.context;
xwiki2.deleteDocument(docName, context2); return true; } }
If the author of the page making the call to parseGroovyFromPage and deleteDocument is not a "programmer" then the call fails. For example if the page is
$xwiki.parseGroovyFromPage("..").deleteDocument($context.user,$context)
Then any use can access the page setup by the programmer to delete it's own page. If the user tries to change the page to replace by $context.user by any page, then the programmers right is revoked and the call fails
Therefore you delete() function is secure.
That's what I understood at first sight... (and why don't you include this small doc in xwiki.org doc to help people understand what they should do or not...) My second idea was: why not prevent the groovy parsing and instantiation when you don't have the rights?(it would spare some memory and process time) Thank you for your explanation Pascal
Ludovic
Pascal Voitot wrote:
I'm a bit stupid... In a previous mail, you told that the checkProgrammingRights should be done in the code directly... Is it true?
In fact, I'm a bit lost reading everything again :)
The programmer programs the groovy script, that's a fact... Can users access a document calling $xwiki.parseGroovy without programming rights and execute the groovy script? (apparently yes in my tests) Or do you strongly advise programmers to prevent users from using groovy scripts when they don't have programming rights using checkProgrammingRights?
Sorry for disturbing you ;)
PAscal
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
If you have a few minutes to space, don't hesitate to transform this into xwiki.org docs.. That would help a lot Ludovic Pascal Voitot wrote:
see below
On Tue, Aug 5, 2008 at 6:52 PM, Ludovic Dubost <[email protected]> wrote:
Let's take an example
public class Groovy {
public boolean delete(String docname, Context context) { def xwiki = context.getWiki(); def xwiki2 = xwiki.xWiki; def context2 = context.context;
xwiki2.deleteDocument(docName, context2); return true; } }
This script is a priviledge script and will use the underlying xwiki api. This means that no rights check are performed on the call to xwiki2.deleteDocument. If you let this class in your wiki, any use can use parseGroovyFromPage to instanciate the class and call delete() and delete any page regardeless of the user rights.
To fix this you do:
public class Groovy {
public boolean delete(String docname, Context context) { if (!context.hasProgrammingRights()) return false;
def xwiki = context.getWiki(); def xwiki2 = xwiki.xWiki; def context2 = context.context;
xwiki2.deleteDocument(docName, context2); return true; } }
If the author of the page making the call to parseGroovyFromPage and deleteDocument is not a "programmer" then the call fails. For example if the page is
$xwiki.parseGroovyFromPage("..").deleteDocument($context.user,$context)
Then any use can access the page setup by the programmer to delete it's own page. If the user tries to change the page to replace by $context.user by any page, then the programmers right is revoked and the call fails
Therefore you delete() function is secure.
That's what I understood at first sight... (and why don't you include this small doc in xwiki.org doc to help people understand what they should do or not...) My second idea was: why not prevent the groovy parsing and instantiation when you don't have the rights?(it would spare some memory and process time)
Thank you for your explanation Pascal
Ludovic
Pascal Voitot wrote:
I'm a bit stupid... In a previous mail, you told that the checkProgrammingRights should be
done
in the code directly... Is it true?
In fact, I'm a bit lost reading everything again :)
The programmer programs the groovy script, that's a fact... Can users access a document calling $xwiki.parseGroovy without
programming
rights and execute the groovy script? (apparently yes in my tests) Or do you strongly advise programmers to prevent users from using groovy scripts when they don't have programming rights using checkProgrammingRights?
Sorry for disturbing you ;)
PAscal
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Pascal Voitot wrote:
On Tue, Aug 5, 2008 at 10:55 AM, Ludovic Dubost <[email protected]> wrote:
Pascal Voitot wrote:
So, this is the responsability of the programmer to control the access to his code... This is quite free but requires a good knowledge about what
you
do... (I wonder wether providing the {{include}} macros would bring much more dangerous issues in this case apart from the memory issue you evoked)
Does parseGroovy takes care about not duplicating script parsing to
prevent
groovy parser from plundering memory?
Yes parseGroovy is cached (the class is only compiled once). It also allows good separation between priviledge code and user code. Programmers can write complex code + velocity macros, and less experienced users can use these macros or classes.
Finally, this might not be a bad choice even if it brings some constraints... Do you intend to write some precise docs about this because this is not really clear without wandering for some time...
one last question (I'm lazy so I prefer asking than thinking ;)): Where do you advise to put user.hasProgrammingRight() ? If you don't put it in the doc called by parseGroovy, I don't see the interest...
Then do you put it outside the groovy part using velocity: if($user.hasProgrammingRights) { /* groovy part */ } (maybe this is no
clever due to the mixing of velocity with groovy)
This would not be secure
or in the groovy part ?
It should be inside the page with the Groovy class. Any function that bypasses rights need to have it's own right check Ludovic
In both case, it will generate an exception as parseGroovy will fail. How to have a clean "you don't have access to this content"
Pascal
Ludovic
I need to think about all of this because Groovy integrated in xwiki with velocity also is so much powerful to my mind that it might be worth
digging
into it...
Pascal
On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <[email protected]>
wrote:
Pascal Voitot wrote:
I agree with you, this is not simple in this context.
Anyway, I have a question: Groovy is programmed by a programmer with special rights but it can be executed by anyone. Am I right? (apparently this is the default
behaviour
I
can see) What prevents anyone with edit rights to add $xwiki.parseGroovy in his velocity script (do you need programming rights for this) ?
The groovy script needs to be own by a programmer. This is the responsibility of the programmer to do a groovy script that is secure or to do himself checkProgrammingRights in his code. If he does then the page doing parseGroovyFromPage needs programming rights. parseGroovyFromString always needs programming rights.
Moreover if you put in a document something like this:
{pre} <% I do some groovy things %> {/pre}
then in another one you put
# some velocity things $xwiki.getDocument("GroovyDoc").getContent() # some other things
Is the groovy simply injected here and executed when someone with
default
rights access the last doc? (Apparently with default rights, that's
what
happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be parsed. Mixing velocity with groovy is dangerous, because You could beat the groovy cache if the script passed to groovy is different on every evaluation. This can lead to high memory usage.
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hi Pascal, Let's analyse the way it currently works in the new rendering. Let's take velocity first: {{velocity}} ... velocity code here... {{include document="..."/}} ... velocity code here... {{/velocity}} These are the steps that are executed: 1/ The whole text is parsed using the wiki syntax parser. This generates an XDOM object containing a single MacroBlock wrapping the velocity macro. 2/ When it's rendered, the Macroblock executes, finds the velocity macro and executes it. 3/ velocity is run on the part inside the velocity macro. 4/ the wiki syntax parser is then executed on the part on which velocity has been executed. This means that the macros inside the velocity block are now executed. This means the include macro is executed. If it contains velocity code it'll be parsed as a standard paragraph text and all special characters are escaped. So if you have velocity script in the document you're including for example it'll be displayed as is without being executed. You'd need to have the velocity macro wrapping it in the document to include for it to be executed. Thus I don't think we have any security issue here. Now let's look at groovy. The macro is not written yet but I think it'll work like what is described below. First the following is NOT valid: {{groovy}} ... groovy code here... {{include document="..."/}} ... groovy code here... {{/velocity}} Groovy will execute on the part inside the groovy macro and will fail on the {{include}} part I think since it's not valid groovy syntax. Now the groovy code could do something like out.println("{{include document='...'/}}") In this case the resulting macro will get executed (since the logic is that the new rendering uses the MacroTransformation to execute the macros and this transformation continues to execute till there's no more macro to execute). Now if the included document contains groovy code not inside a groovy macro nothing will happen and the code will be printed as standard text (no groovy execution). If it's inside a groovy macro then it'll get executed but only once since the groovy macro in the page doing the include will have already executed. To summarize, I think the fact that outside macros execute before nested macros prevents dangerous things to happen in general. Now I haven't analysed all cases yet so if you see something dangerous please let me know so that I can fix it while it's possible. To answer your question Pascal, you would write: {{groovy}} ... some groovy code... {{/groovy}} {{include document="... page containing a groovy macro..." context="current"/}} Let me know if I missed something. Thanks -Vincent On Aug 5, 2008, at 9:36 AM, Pascal Voitot wrote:
Hello,
Do you foresee a special syntax for groovy scripts as you already have for velocity using {{velocity}} with some more features?
My idea is to be able to code cleanly using groovy and to put some "generic" part of scripts in separated documents and to be able to import them in other docs containing other parts of scripts.
It would be really nice to be able to type some part of scripts or to define some groovy classes in a page and tell "this is groovy code which is not "WIKI-renderable" as is". Then we could simply import/include this script in another page (just paste the code without any rendering) using something like #include("MySpace.MyGroovyDoc").
xwiki.parseGroovyXXX is useful sometimes but not when you only want to include some part of scripts. Existing #includeXXX macros always render the content and here I only want to paste a script from somewhere else (xwiki.getDocument("").getContent() in fact)
Moreover the idea would be also to allow using both "xwiki.parseGroovy" and the #include macro for the same groovy "document". For the time being, one need to use the trick /* groovygroovy #* */ /* *# */
and then you are condemned to use xwiki.parseGroovyXXX because no other function can interprete this tricky syntax.
best regards Pascal _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
see below On Tue, Aug 5, 2008 at 5:09 PM, Vincent Massol <[email protected]> wrote:
Hi Pascal,
Let's analyse the way it currently works in the new rendering. Let's take velocity first:
{{velocity}} ... velocity code here... {{include document="..."/}} ... velocity code here... {{/velocity}}
These are the steps that are executed: 1/ The whole text is parsed using the wiki syntax parser. This generates an XDOM object containing a single MacroBlock wrapping the velocity macro. 2/ When it's rendered, the Macroblock executes, finds the velocity macro and executes it. 3/ velocity is run on the part inside the velocity macro. 4/ the wiki syntax parser is then executed on the part on which velocity has been executed. This means that the macros inside the velocity block are now executed. This means the include macro is executed. If it contains velocity code it'll be parsed as a standard paragraph text and all special characters are escaped. So if you have velocity script in the document you're including for example it'll be displayed as is without being executed. You'd need to have the velocity macro wrapping it in the document to include for it to be executed.
Thus I don't think we have any security issue here.
Now let's look at groovy. The macro is not written yet but I think it'll work like what is described below. First the following is NOT valid:
{{groovy}} ... groovy code here... {{include document="..."/}} ... groovy code here... {{/velocity}}
Groovy will execute on the part inside the groovy macro and will fail on the {{include}} part I think since it's not valid groovy syntax.
I agree
Now the groovy code could do something like out.println("{{include document='...'/}}") In this case the resulting macro will get executed (since the logic is that the new rendering uses the MacroTransformation to execute the macros and this transformation continues to execute till there's no more macro to execute).
Now if the included document contains groovy code not inside a groovy macro nothing will happen and the code will be printed as standard text (no groovy execution). If it's inside a groovy macro then it'll get executed but only once since the groovy macro in the page doing the include will have already executed.
To summarize, I think the fact that outside macros execute before nested macros prevents dangerous things to happen in general. Now I haven't analysed all cases yet so if you see something dangerous please let me know so that I can fix it while it's possible.
So you think this might no be dangerous to use include for groovy?
To answer your question Pascal, you would write:
{{groovy}} ... some groovy code... {{/groovy}}
{{include document="... page containing a groovy macro..." context="current"/}}
Let me know if I missed something.
I have a question: if you create a groovy object in the first {{groovy}}, could you use it also in the {{include}} (if it basically contains also {{groovy}} script) since you include the doc in current context? I mean: are these 2 completely different groovy executions or do they share the same execution context? br Pascal
Thanks -Vincent
On Aug 5, 2008, at 9:36 AM, Pascal Voitot wrote:
Hello,
Do you foresee a special syntax for groovy scripts as you already have for velocity using {{velocity}} with some more features?
My idea is to be able to code cleanly using groovy and to put some "generic" part of scripts in separated documents and to be able to import them in other docs containing other parts of scripts.
It would be really nice to be able to type some part of scripts or to define some groovy classes in a page and tell "this is groovy code which is not "WIKI-renderable" as is". Then we could simply import/include this script in another page (just paste the code without any rendering) using something like #include("MySpace.MyGroovyDoc").
xwiki.parseGroovyXXX is useful sometimes but not when you only want to include some part of scripts. Existing #includeXXX macros always render the content and here I only want to paste a script from somewhere else (xwiki.getDocument("").getContent() in fact)
Moreover the idea would be also to allow using both "xwiki.parseGroovy" and the #include macro for the same groovy "document". For the time being, one need to use the trick /* groovygroovy #* */ /* *# */
and then you are condemned to use xwiki.parseGroovyXXX because no other function can interprete this tricky syntax.
best regards Pascal _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Aug 5, 2008, at 5:29 PM, Pascal Voitot wrote: [snip]
To summarize, I think the fact that outside macros execute before nested macros prevents dangerous things to happen in general. Now I haven't analysed all cases yet so if you see something dangerous please let me know so that I can fix it while it's possible.
So you think this might no be dangerous to use include for groovy?
It's exactly like now. If your groovy script is dangerous, whether it's in one a standalone page or included in another page, it'll still be as dangerous so you'll need to protect it. If the page is itself protected the include will fail (not implemented yet in the new rendering but planned). Thus you should either protect the page or use an if to test for some rights. One possibility we have would be to add an executionRights parameter to the groovy macro in the new rendering that would default to "programming" so that only users with programming rights would be able to execute a groovy macro by default (to allow anyone you would add executionRights="view"). Basically this would simply do the test for rights on behalf of the programmer. WDYT?
To answer your question Pascal, you would write:
{{groovy}} ... some groovy code... {{/groovy}}
{{include document="... page containing a groovy macro..." context="current"/}}
Let me know if I missed something.
I have a question: if you create a groovy object in the first {{groovy}}, could you use it also in the {{include}} (if it basically contains also {{groovy}} script) since you include the doc in current context? I mean: are these 2 completely different groovy executions or do they share the same execution context?
Yes they'll share the same context. Thanks -Vincent
On Thu, Aug 7, 2008 at 8:46 AM, Vincent Massol <[email protected]> wrote:
On Aug 5, 2008, at 5:29 PM, Pascal Voitot wrote:
[snip]
To summarize, I think the fact that outside macros execute before nested macros prevents dangerous things to happen in general. Now I haven't analysed all cases yet so if you see something dangerous please let me know so that I can fix it while it's possible.
So you think this might no be dangerous to use include for groovy?
It's exactly like now. If your groovy script is dangerous, whether it's in one a standalone page or included in another page, it'll still be as dangerous so you'll need to protect it. If the page is itself protected the include will fail (not implemented yet in the new rendering but planned). Thus you should either protect the page or use an if to test for some rights.
One possibility we have would be to add an executionRights parameter to the groovy macro in the new rendering that would default to "programming" so that only users with programming rights would be able to execute a groovy macro by default (to allow anyone you would add executionRights="view"). Basically this would simply do the test for rights on behalf of the programmer.
WDYT?
This is a philosophical question ;) What do you prefer: let people control security completely or enforce some basic security because people can't be expert immediately? To my mind, ensuring some basic security controls is safer... And also providing a mechanism to toggle it off knowing what you do... So why not add this execution right control by default in the groovy macro and provide an option allowing everyone to execute this groovy macro! It would also prevent the groovy parsing and execution which is not bad for performance and memory!
To answer your question Pascal, you would write:
{{groovy}} ... some groovy code... {{/groovy}}
{{include document="... page containing a groovy macro..." context="current"/}}
Let me know if I missed something.
I have a question: if you create a groovy object in the first {{groovy}}, could you use it also in the {{include}} (if it basically contains also {{groovy}} script) since you include the doc in current context? I mean: are these 2 completely different groovy executions or do they share the same execution context?
Yes they'll share the same context.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Ludovic Dubost -
Pascal Voitot -
Vincent Massol