Hi Tobias,
>Because then you can't send a response anymore. (If you interrupt the
actual request thread)
you can catch an InterruptedException and continue with any response you
like.
>That solution looks to me like only ensure the java classes not to
access other parts / classes from oder cls - but if you write new
File("..."); you have access - right?
Honestly I'm not sure.
Have fun
Sven
On 25.01.2016 21:08, Tobias Soloschenko wrote:
Hi Sven,
Am 25.01.16 um 20:49 schrieb Sven Meier:
Hi Tobias,
>The posibility to interrupt the script requires a thread so the
script has to run into one
why not execute the script on the container thread? It can equally
well be interrupted.
Because then you can't send a response anymore. (If you interrupt the
actual request thread)
>There has been no discussion about it since now - I am very happy to
read more suggestions! :-)
The thread-based solution looks clunky to me. I seems to me
sandboxing of a script should be based on where it is coming from,
instead on who runs it.
It is only a request / response paradigm.
http://www.jayway.com/2014/06/13/sandboxing-plugins-in-java/
Disclaimer: I didn't work this out completely :P
That solution looks to me like only ensure the java classes not to
access other parts / classes from oder cls - but if you write new
File("..."); you have access - right?
kind regards
Tobias
Have fun
Sven
On 25.01.2016 20:41, Tobias Soloschenko wrote:
Hi Sven,
I don't investigated ProtectedDomain solution, yet.
The posibility to interrupt the script requires a thread so the
script has to run into one. Also the memory check in a separate
thread requires it.
And as of a post (have to search the link) in the oracle forums the
devs also mentioned to always use a SecurityManager.
There has been no discussion about it since now - I am very happy to
read more suggestions! :-)
kind regards
Tobias
Am 25.01.2016 um 20:32 schrieb Sven Meier <[email protected]>:
Hi Tobias,
have you investigated usage of a ProtectionDomain instead of a
thread-based security approach?
Sorry if this has been answered before, I didn't follow the
discussion closely.
Regards
Sven
On 25.01.2016 17:28, Tobias Soloschenko wrote:
I think because it is not required I would not add it (it also
slows down a bit)
kind regards
Tobias
Am 25.01.2016 um 17:25 schrieb Sven Meier <[email protected]>:
Well, shouldn't it be disabled again after the script has finished?
At least because of *symmetry*?
Sven
On 25.01.2016 17:16, Tobias Soloschenko wrote:
Hi Sven,
it stays online as long as the script thread lifes to ensure the
security the whole time the script is executed. (ThreadLocal)
kind regards
Tobias
Am 25.01.2016 um 17:12 schrieb Sven Meier <[email protected]>:
Hi Tobias,
the securityManager is never disabled again, is this intended?
I find this lack of symmetry disturbing ;)
Sven
On 25.01.2016 16:21, Tobias Soloschenko wrote:
Hi,
hope that everthing is ok with nashorn-parent. :-)
I think I have committed everything to ensure the maximum
safety to run the script engine (MemoryLeakDetection,
ClassFilter, prevention for endless running script,
SecurityManager which can be enabled only for the script threads)
Anyway don't use it as public interface!
I would be very pleased if someone could review it in detail
before release of wicketstuff 7.2.0.
Again thanks a lot to Martin Grigorov who mentioned some
points to fix.
kind regards
Tobias
Am 25.01.2016 um 15:22 schrieb Martin Grigorov
<[email protected]>:
Hi,
I'm going to release WicketStuff 7.2.0 in the next few days.
Please commit your improvements now! Or wait for 7.3.0 :-)
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
