5 Aug
2008
5 Aug
'08
4:17 p.m.
Pascal Voitot wrote:
On Tue, Aug 5, 2008 at 10:55 AM, Ludovic Dubost
<ludovic(a)xwiki.org> wrote:
Pascal Voitot wrote:
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...
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.
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 Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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 <ludovic(a)xwiki.org>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs