You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Tobias Soloschenko <to...@googlemail.com> on 2016/01/06 18:40:53 UTC
NashornResourceReference
Hi guys,
I am currently playing around a bit with the nashorn implementation of
Java 8.
I just implemented a ResourceReference to show up cool features. :-)
Features:
* Post javascript against the resource reference which is executed on
server side and optional enriched with user scoped objects that can be
accessed (read / write)
* Access to user objects can be setup in the corresponding method
* A generic interface to allow third party developers to implement
required functionality with java script
* Access to any kind of java objects made available
* No compilation needed
Example of the Reference:
https://github.com/klopfdreh/wicket/blob/cafb899d3a6fd61d4e93fc556053df3689bd8ced/wicket-core/src/test/java/org/apache/wicket/resource/NashornResourceReferenceTest.java
Examples of Nashorn:
http://winterbe.com/posts/2014/04/05/java8-nashorn-tutorial/
Improvements left to implement:
* A timeout that interrupts the javascript engine if the execution takes
to long
WDYT?
kind regards
Tobias
Re: NashornResourceReference
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi Emond,
ok, then I would let the NRR as it is, now.
Maybe there will be a way to improve it in the future.
kind regards
Tobias
> Am 08.01.2016 um 09:08 schrieb Emond Papegaaij <em...@topicus.nl>:
>
> Hi Tobias,
>
> Unfortunately, even Thread.stop is not fool-proof. For example, if you try this script, it will
> not terminate:
>
> var x = 0;
> while (true) {
> try {
> x++;
> } catch (e) {
> }
> }
>
> The problem in this case is that Thread.stop causes a ThreadDeath to be thrown inside the
> thread. This Error is caught by the catch-statement, ignored and the script will keep
> running.
>
> I don't think there is a way to protect against all kinds of mallicious scripts. There are
> simply too many ways to break a running VM. To be able to run scripts from untrusted
> sources, you will have to run these scripts in some kind of sandbox. You could, for example,
> spawn a new VM with limited resources.
>
> In one of our applications, users are able to write scripts in Groovy, which are used to
> generate reports. We use a very strict class and method whitelist, to prevent scripts from
> breaking out of its environment. We also inject code in all loops to abort a script when
> needed. However, this still does not protect us against things like claiming large amounts
> or memory. Also, a script can still catch the Exception we use to abort it and continue
> running. We simply have to trust our users to not write scripts that would harm our server.
> Therefore, we only allow a select group of users to write scripts and we can always see
> who wrote it.
>
> Best regards,
> Emond
>
>> On Thursday, January 07, 2016 07:57:36 PM Tobias Soloschenko wrote:
>> Hi Emond,
>>
>> ok the last thing left is the memory consumption. Hope that I am able to
>> find a way to make this also save.
>>
>> Any suggestions here?
>>
>> kind regards
>>
>> Tobias
>>
>>> Am 07.01.16 um 15:43 schrieb Emond Papegaaij:
>>> Hi Tobias,
>>>
>>> You have to modify the code with the snippet below. This will wait for
>>> termination with a timeout of 1 minute, after which the VM still
>>> terminates. However, in a normal webapplication, the VM will not
>>> terminate, so threads will stay active until you terminate your entire
>>> application.
>>>
>>> The code to trigger an out-of-memory is:
>>>
>>> var i = 0, o = {};
>>> while(true) {
>>>
>>> o[i++] = new Array(1000000);
>>>
>>> }
>>>
>>> Also, you can try to run the same testcase multiple times in 1 go. After
>>> about 100 executions of the script, I suspect your system will start to
>>> die on you.
Re: NashornResourceReference
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi Tobias,
Unfortunately, even Thread.stop is not fool-proof. For example, if you try this script, it will
not terminate:
var x = 0;
while (true) {
try {
x++;
} catch (e) {
}
}
The problem in this case is that Thread.stop causes a ThreadDeath to be thrown inside the
thread. This Error is caught by the catch-statement, ignored and the script will keep
running.
I don't think there is a way to protect against all kinds of mallicious scripts. There are
simply too many ways to break a running VM. To be able to run scripts from untrusted
sources, you will have to run these scripts in some kind of sandbox. You could, for example,
spawn a new VM with limited resources.
In one of our applications, users are able to write scripts in Groovy, which are used to
generate reports. We use a very strict class and method whitelist, to prevent scripts from
breaking out of its environment. We also inject code in all loops to abort a script when
needed. However, this still does not protect us against things like claiming large amounts
or memory. Also, a script can still catch the Exception we use to abort it and continue
running. We simply have to trust our users to not write scripts that would harm our server.
Therefore, we only allow a select group of users to write scripts and we can always see
who wrote it.
Best regards,
Emond
On Thursday, January 07, 2016 07:57:36 PM Tobias Soloschenko wrote:
> Hi Emond,
>
> ok the last thing left is the memory consumption. Hope that I am able to
> find a way to make this also save.
>
> Any suggestions here?
>
> kind regards
>
> Tobias
>
> Am 07.01.16 um 15:43 schrieb Emond Papegaaij:
> > Hi Tobias,
> >
> > You have to modify the code with the snippet below. This will wait for
> > termination with a timeout of 1 minute, after which the VM still
> > terminates. However, in a normal webapplication, the VM will not
> > terminate, so threads will stay active until you terminate your entire
> > application.
> >
> > The code to trigger an out-of-memory is:
> >
> > var i = 0, o = {};
> > while(true) {
> >
> > o[i++] = new Array(1000000);
> >
> > }
> >
> > Also, you can try to run the same testcase multiple times in 1 go. After
> > about 100 executions of the script, I suspect your system will start to
> > die on you.
Re: NashornResourceReference
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi Emond,
ok the last thing left is the memory consumption. Hope that I am able to
find a way to make this also save.
Any suggestions here?
kind regards
Tobias
Am 07.01.16 um 15:43 schrieb Emond Papegaaij:
> Hi Tobias,
>
> You have to modify the code with the snippet below. This will wait for termination with a
> timeout of 1 minute, after which the VM still terminates. However, in a normal
> webapplication, the VM will not terminate, so threads will stay active until you terminate
> your entire application.
>
> The code to trigger an out-of-memory is:
>
> var i = 0, o = {};
> while(true) {
> o[i++] = new Array(1000000);
> }
>
> Also, you can try to run the same testcase multiple times in 1 go. After about 100
> executions of the script, I suspect your system will start to die on you.
>
> Best regards,
> Emond
>
> On Thursday, January 07, 2016 02:50:03 PM Tobias Soloschenko wrote:
>> Hi well for me the behavior you mentioned is not shown up.
>>
>> For me the jvm is terminated. I also watched the process list.
>>
>> Maybe it depends on the os?! I use MacOS X.
>>
>> kind regards
>>
>> Tobias
>>
>>> Am 07.01.2016 um 13:43 schrieb Emond Papegaaij
>>> <em...@topicus.nl>:
>>>
>>> Hi Tobias,
>>>
>>> I've checked your code, and the testcase does stop in 5 seconds, but the
>>> thread does not. The cancelation of the future triggers an exception in
>>> the resources, which causes the test to terminate, thereby stopping the
>>> vm and the thread. However, if you add this to your testcase:
>>> try {
>>>
>>> wicketTester.startResourceReference(reference);
>>>
>>> } finally {
>>>
>>> reference.getScheduledExecutorService().shutdownNow();
>>> reference.getScheduledExecutorService().awaitTermination(
>>>
>>> 1, TimeUnit.MINUTES);
>>>
>>> }
>>> You will see that after 1 minute, the executor is still not terminated.
>>>
>>> Also, when executing my other script, I get a java.lang.OutOfMemoryError
>>> after only 3 seconds.
>>>
>>> Best regards,
>>> Emond
>>>
>>>> On Thursday, January 07, 2016 12:21:42 PM Tobias Soloschenko wrote:
>>>> Hi again,
>>>>
>>>> I updated the PR - just check it out, open the
>>>> NashornResourceReferenceTest.js and add:
>>>>
>>>> while(true){}
Re: NashornResourceReference
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi Emond,
yep I can reproduce it, now.
Try the last commit. ;-)
Kind of ugly but works to terminate the running thread.
kind regards
Tobias
> Am 07.01.2016 um 15:43 schrieb Emond Papegaaij <em...@topicus.nl>:
>
> Hi Tobias,
>
> You have to modify the code with the snippet below. This will wait for termination with a
> timeout of 1 minute, after which the VM still terminates. However, in a normal
> webapplication, the VM will not terminate, so threads will stay active until you terminate
> your entire application.
>
> The code to trigger an out-of-memory is:
>
> var i = 0, o = {};
> while(true) {
> o[i++] = new Array(1000000);
> }
>
> Also, you can try to run the same testcase multiple times in 1 go. After about 100
> executions of the script, I suspect your system will start to die on you.
>
> Best regards,
> Emond
>
>> On Thursday, January 07, 2016 02:50:03 PM Tobias Soloschenko wrote:
>> Hi well for me the behavior you mentioned is not shown up.
>>
>> For me the jvm is terminated. I also watched the process list.
>>
>> Maybe it depends on the os?! I use MacOS X.
>>
>> kind regards
>>
>> Tobias
>>
>>> Am 07.01.2016 um 13:43 schrieb Emond Papegaaij
>>> <em...@topicus.nl>:
>>>
>>> Hi Tobias,
>>>
>>> I've checked your code, and the testcase does stop in 5 seconds, but the
>>> thread does not. The cancelation of the future triggers an exception in
>>> the resources, which causes the test to terminate, thereby stopping the
>>> vm and the thread. However, if you add this to your testcase:
>>> try {
>>>
>>> wicketTester.startResourceReference(reference);
>>>
>>> } finally {
>>>
>>> reference.getScheduledExecutorService().shutdownNow();
>>> reference.getScheduledExecutorService().awaitTermination(
>>>
>>> 1, TimeUnit.MINUTES);
>>>
>>> }
>>> You will see that after 1 minute, the executor is still not terminated.
>>>
>>> Also, when executing my other script, I get a java.lang.OutOfMemoryError
>>> after only 3 seconds.
>>>
>>> Best regards,
>>> Emond
>>>
>>>> On Thursday, January 07, 2016 12:21:42 PM Tobias Soloschenko wrote:
>>>> Hi again,
>>>>
>>>> I updated the PR - just check it out, open the
>>>> NashornResourceReferenceTest.js and add:
>>>>
>>>> while(true){}
Re: NashornResourceReference
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi Tobias,
You have to modify the code with the snippet below. This will wait for termination with a
timeout of 1 minute, after which the VM still terminates. However, in a normal
webapplication, the VM will not terminate, so threads will stay active until you terminate
your entire application.
The code to trigger an out-of-memory is:
var i = 0, o = {};
while(true) {
o[i++] = new Array(1000000);
}
Also, you can try to run the same testcase multiple times in 1 go. After about 100
executions of the script, I suspect your system will start to die on you.
Best regards,
Emond
On Thursday, January 07, 2016 02:50:03 PM Tobias Soloschenko wrote:
> Hi well for me the behavior you mentioned is not shown up.
>
> For me the jvm is terminated. I also watched the process list.
>
> Maybe it depends on the os?! I use MacOS X.
>
> kind regards
>
> Tobias
>
> > Am 07.01.2016 um 13:43 schrieb Emond Papegaaij
> > <em...@topicus.nl>:
> >
> > Hi Tobias,
> >
> > I've checked your code, and the testcase does stop in 5 seconds, but the
> > thread does not. The cancelation of the future triggers an exception in
> > the resources, which causes the test to terminate, thereby stopping the
> > vm and the thread. However, if you add this to your testcase:
> > try {
> >
> > wicketTester.startResourceReference(reference);
> >
> > } finally {
> >
> > reference.getScheduledExecutorService().shutdownNow();
> > reference.getScheduledExecutorService().awaitTermination(
> >
> > 1, TimeUnit.MINUTES);
> >
> > }
> > You will see that after 1 minute, the executor is still not terminated.
> >
> > Also, when executing my other script, I get a java.lang.OutOfMemoryError
> > after only 3 seconds.
> >
> > Best regards,
> > Emond
> >
> >> On Thursday, January 07, 2016 12:21:42 PM Tobias Soloschenko wrote:
> >> Hi again,
> >>
> >> I updated the PR - just check it out, open the
> >> NashornResourceReferenceTest.js and add:
> >>
> >> while(true){}
Re: NashornResourceReference
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi Emond,
Ah! Now I see what you mean - sad that there is now way to set a timeout for the script execution. :-/
Anyway I am going to find out if the API changed in U<X> and if there is a way to handle this, now.
Out of memory - what for a script did you run?
kind regards
Tobias
> Am 07.01.2016 um 13:43 schrieb Emond Papegaaij <em...@topicus.nl>:
>
> Hi Tobias,
>
> I've checked your code, and the testcase does stop in 5 seconds, but the thread does not.
> The cancelation of the future triggers an exception in the resources, which causes the test
> to terminate, thereby stopping the vm and the thread. However, if you add this to your
> testcase:
> try {
> wicketTester.startResourceReference(reference);
> } finally {
> reference.getScheduledExecutorService().shutdownNow();
> reference.getScheduledExecutorService().awaitTermination(
> 1, TimeUnit.MINUTES);
> }
> You will see that after 1 minute, the executor is still not terminated.
>
> Also, when executing my other script, I get a java.lang.OutOfMemoryError after only 3
> seconds.
>
> Best regards,
> Emond
>
>> On Thursday, January 07, 2016 12:21:42 PM Tobias Soloschenko wrote:
>> Hi again,
>>
>> I updated the PR - just check it out, open the
>> NashornResourceReferenceTest.js and add:
>>
>> while(true){}
>>
>> For me the unit test stops running after 5 seconds.
>>
>> I also added the class filter to reject all if no own filter is defined by
>> overriding the corresponding method.
>>
>> kind regards
>>
>> Tobias
>>
>>> Am 07.01.2016 um 11:49 schrieb Emond Papegaaij
>>> <em...@topicus.nl>:
>>>
>>> Hi Tobias,
>>>
>>> Future.cancel will attempt to interrupt the thread, but this will not stop
>>> a thread executing 'while(true);'. It will stop a thread executing
>>> 'while(!isInterrupted());'. There is no way to safely stop a thread in
>>> Java (other than stopping the entire VM).
>>>
>>> Best regards,
>>> Emond
>>>
>>>> On Thursday, January 07, 2016 11:12:31 AM Tobias Soloschenko wrote:
>>>> Hi,
>>>>
>>>> I use ScheduledExecutorService and cancel - I am going to submit and show
>>>> you the changes this evening.
>>>>
>>>> kind regards
>>>>
>>>> Tobias
>>>>
>>>>> Am 07.01.2016 um 10:50 schrieb Emond Papegaaij
>>>>> <em...@topicus.nl>:
>>>>>
>>>>> Hi Tobias,
>>>>>
>>>>> How do you terminate a thread? The only way to terminate a Thread from
Re: NashornResourceReference
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi well for me the behavior you mentioned is not shown up.
For me the jvm is terminated. I also watched the process list.
Maybe it depends on the os?! I use MacOS X.
kind regards
Tobias
> Am 07.01.2016 um 13:43 schrieb Emond Papegaaij <em...@topicus.nl>:
>
> Hi Tobias,
>
> I've checked your code, and the testcase does stop in 5 seconds, but the thread does not.
> The cancelation of the future triggers an exception in the resources, which causes the test
> to terminate, thereby stopping the vm and the thread. However, if you add this to your
> testcase:
> try {
> wicketTester.startResourceReference(reference);
> } finally {
> reference.getScheduledExecutorService().shutdownNow();
> reference.getScheduledExecutorService().awaitTermination(
> 1, TimeUnit.MINUTES);
> }
> You will see that after 1 minute, the executor is still not terminated.
>
> Also, when executing my other script, I get a java.lang.OutOfMemoryError after only 3
> seconds.
>
> Best regards,
> Emond
>
>> On Thursday, January 07, 2016 12:21:42 PM Tobias Soloschenko wrote:
>> Hi again,
>>
>> I updated the PR - just check it out, open the
>> NashornResourceReferenceTest.js and add:
>>
>> while(true){}
>>
>> For me the unit test stops running after 5 seconds.
>>
>> I also added the class filter to reject all if no own filter is defined by
>> overriding the corresponding method.
>>
>> kind regards
>>
>> Tobias
>>
>>> Am 07.01.2016 um 11:49 schrieb Emond Papegaaij
>>> <em...@topicus.nl>:
>>>
>>> Hi Tobias,
>>>
>>> Future.cancel will attempt to interrupt the thread, but this will not stop
>>> a thread executing 'while(true);'. It will stop a thread executing
>>> 'while(!isInterrupted());'. There is no way to safely stop a thread in
>>> Java (other than stopping the entire VM).
>>>
>>> Best regards,
>>> Emond
>>>
>>>> On Thursday, January 07, 2016 11:12:31 AM Tobias Soloschenko wrote:
>>>> Hi,
>>>>
>>>> I use ScheduledExecutorService and cancel - I am going to submit and show
>>>> you the changes this evening.
>>>>
>>>> kind regards
>>>>
>>>> Tobias
>>>>
>>>>> Am 07.01.2016 um 10:50 schrieb Emond Papegaaij
>>>>> <em...@topicus.nl>:
>>>>>
>>>>> Hi Tobias,
>>>>>
>>>>> How do you terminate a thread? The only way to terminate a Thread from
Re: NashornResourceReference
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi Tobias,
I've checked your code, and the testcase does stop in 5 seconds, but the thread does not.
The cancelation of the future triggers an exception in the resources, which causes the test
to terminate, thereby stopping the vm and the thread. However, if you add this to your
testcase:
try {
wicketTester.startResourceReference(reference);
} finally {
reference.getScheduledExecutorService().shutdownNow();
reference.getScheduledExecutorService().awaitTermination(
1, TimeUnit.MINUTES);
}
You will see that after 1 minute, the executor is still not terminated.
Also, when executing my other script, I get a java.lang.OutOfMemoryError after only 3
seconds.
Best regards,
Emond
On Thursday, January 07, 2016 12:21:42 PM Tobias Soloschenko wrote:
> Hi again,
>
> I updated the PR - just check it out, open the
> NashornResourceReferenceTest.js and add:
>
> while(true){}
>
> For me the unit test stops running after 5 seconds.
>
> I also added the class filter to reject all if no own filter is defined by
> overriding the corresponding method.
>
> kind regards
>
> Tobias
>
> > Am 07.01.2016 um 11:49 schrieb Emond Papegaaij
> > <em...@topicus.nl>:
> >
> > Hi Tobias,
> >
> > Future.cancel will attempt to interrupt the thread, but this will not stop
> > a thread executing 'while(true);'. It will stop a thread executing
> > 'while(!isInterrupted());'. There is no way to safely stop a thread in
> > Java (other than stopping the entire VM).
> >
> > Best regards,
> > Emond
> >
> >> On Thursday, January 07, 2016 11:12:31 AM Tobias Soloschenko wrote:
> >> Hi,
> >>
> >> I use ScheduledExecutorService and cancel - I am going to submit and show
> >> you the changes this evening.
> >>
> >> kind regards
> >>
> >> Tobias
> >>
> >>> Am 07.01.2016 um 10:50 schrieb Emond Papegaaij
> >>> <em...@topicus.nl>:
> >>>
> >>> Hi Tobias,
> >>>
> >>> How do you terminate a thread? The only way to terminate a Thread from
Re: NashornResourceReference
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi Emond,
the unit test is working with while(true) - so if I execute a javascript with while(true) and cancel the future after a delay of 5 seconds - the unit test ends.
kind regards
Tobias
> Am 07.01.2016 um 11:49 schrieb Emond Papegaaij <em...@topicus.nl>:
>
> Hi Tobias,
>
> Future.cancel will attempt to interrupt the thread, but this will not stop a thread executing
> 'while(true);'. It will stop a thread executing 'while(!isInterrupted());'. There is no way to
> safely stop a thread in Java (other than stopping the entire VM).
>
> Best regards,
> Emond
>
>> On Thursday, January 07, 2016 11:12:31 AM Tobias Soloschenko wrote:
>> Hi,
>>
>> I use ScheduledExecutorService and cancel - I am going to submit and show
>> you the changes this evening.
>>
>> kind regards
>>
>> Tobias
>>
>>> Am 07.01.2016 um 10:50 schrieb Emond Papegaaij
>>> <em...@topicus.nl>:
>>>
>>> Hi Tobias,
>>>
>>> How do you terminate a thread? The only way to terminate a Thread from
>>> outside is Thread.stop, which is very dangerous. Thread.interrupt will
>>> only stop de thread if that thread supports interrupting. A simple
>>> 'while(true);' will not terminate. Even if you manage to terminate a
>>> script in a few seconds, this will not help against a script like:
>>>
>>> var i = 0, o = {};
>>> while(true) {
>>>
>>> o[i++] = new Array(1000000);
>>>
>>> }
>>>
>>> Don't understand me wrong, a resource like this can be useful in some
>>> situations, but you realy have to make sure it is not exposed to the
>>> user, or you will have to deal with rogue scripts.
>>>
>>> Best regards,
>>> Emond
>>>
>>>> On Thursday, January 07, 2016 10:25:30 AM Tobias Soloschenko wrote:
>>>> Hi Emond,
>>>>
>>>> I already implemented a thread pool which terminates long running
>>>> scripts. I am going to submit it this evening.
>>>>
>>>> Good hint with the class filter - I am going to have a look at it.
>>>> Thanks!
>>>>
>>>> kind regards
>>>>
>>>> Tobias
>>>>
>>>>> Am 07.01.2016 um 08:24 schrieb Emond Papegaaij
>>>>> <em...@topicus.nl>:
>>>>>
>>>>> Hi Tobias,
>>>>>
>>>>> This is a very nice feature indeed, but be very carefull when exposing
>>>>> server-side code to a client. What would happen if some user would post
>>>>> 'Java.type("java.lang.System").exit(0)'? A service like this must always
>>>>> be protected via some sort of whitelist filter. The Java Scripting API
>>>>> has support for ClassFilter, which can be used for this.
Re: NashornResourceReference
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi again,
I updated the PR - just check it out, open the NashornResourceReferenceTest.js and add:
while(true){}
For me the unit test stops running after 5 seconds.
I also added the class filter to reject all if no own filter is defined by overriding the corresponding method.
kind regards
Tobias
> Am 07.01.2016 um 11:49 schrieb Emond Papegaaij <em...@topicus.nl>:
>
> Hi Tobias,
>
> Future.cancel will attempt to interrupt the thread, but this will not stop a thread executing
> 'while(true);'. It will stop a thread executing 'while(!isInterrupted());'. There is no way to
> safely stop a thread in Java (other than stopping the entire VM).
>
> Best regards,
> Emond
>
>> On Thursday, January 07, 2016 11:12:31 AM Tobias Soloschenko wrote:
>> Hi,
>>
>> I use ScheduledExecutorService and cancel - I am going to submit and show
>> you the changes this evening.
>>
>> kind regards
>>
>> Tobias
>>
>>> Am 07.01.2016 um 10:50 schrieb Emond Papegaaij
>>> <em...@topicus.nl>:
>>>
>>> Hi Tobias,
>>>
>>> How do you terminate a thread? The only way to terminate a Thread from
>>> outside is Thread.stop, which is very dangerous. Thread.interrupt will
>>> only stop de thread if that thread supports interrupting. A simple
>>> 'while(true);' will not terminate. Even if you manage to terminate a
>>> script in a few seconds, this will not help against a script like:
>>>
>>> var i = 0, o = {};
>>> while(true) {
>>>
>>> o[i++] = new Array(1000000);
>>>
>>> }
>>>
>>> Don't understand me wrong, a resource like this can be useful in some
>>> situations, but you realy have to make sure it is not exposed to the
>>> user, or you will have to deal with rogue scripts.
>>>
>>> Best regards,
>>> Emond
>>>
>>>> On Thursday, January 07, 2016 10:25:30 AM Tobias Soloschenko wrote:
>>>> Hi Emond,
>>>>
>>>> I already implemented a thread pool which terminates long running
>>>> scripts. I am going to submit it this evening.
>>>>
>>>> Good hint with the class filter - I am going to have a look at it.
>>>> Thanks!
>>>>
>>>> kind regards
>>>>
>>>> Tobias
>>>>
>>>>> Am 07.01.2016 um 08:24 schrieb Emond Papegaaij
>>>>> <em...@topicus.nl>:
>>>>>
>>>>> Hi Tobias,
>>>>>
>>>>> This is a very nice feature indeed, but be very carefull when exposing
>>>>> server-side code to a client. What would happen if some user would post
>>>>> 'Java.type("java.lang.System").exit(0)'? A service like this must always
>>>>> be protected via some sort of whitelist filter. The Java Scripting API
>>>>> has support for ClassFilter, which can be used for this.
Re: NashornResourceReference
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi Tobias,
Future.cancel will attempt to interrupt the thread, but this will not stop a thread executing
'while(true);'. It will stop a thread executing 'while(!isInterrupted());'. There is no way to
safely stop a thread in Java (other than stopping the entire VM).
Best regards,
Emond
On Thursday, January 07, 2016 11:12:31 AM Tobias Soloschenko wrote:
> Hi,
>
> I use ScheduledExecutorService and cancel - I am going to submit and show
> you the changes this evening.
>
> kind regards
>
> Tobias
>
> > Am 07.01.2016 um 10:50 schrieb Emond Papegaaij
> > <em...@topicus.nl>:
> >
> > Hi Tobias,
> >
> > How do you terminate a thread? The only way to terminate a Thread from
> > outside is Thread.stop, which is very dangerous. Thread.interrupt will
> > only stop de thread if that thread supports interrupting. A simple
> > 'while(true);' will not terminate. Even if you manage to terminate a
> > script in a few seconds, this will not help against a script like:
> >
> > var i = 0, o = {};
> > while(true) {
> >
> > o[i++] = new Array(1000000);
> >
> > }
> >
> > Don't understand me wrong, a resource like this can be useful in some
> > situations, but you realy have to make sure it is not exposed to the
> > user, or you will have to deal with rogue scripts.
> >
> > Best regards,
> > Emond
> >
> >> On Thursday, January 07, 2016 10:25:30 AM Tobias Soloschenko wrote:
> >> Hi Emond,
> >>
> >> I already implemented a thread pool which terminates long running
> >> scripts. I am going to submit it this evening.
> >>
> >> Good hint with the class filter - I am going to have a look at it.
> >> Thanks!
> >>
> >> kind regards
> >>
> >> Tobias
> >>
> >>> Am 07.01.2016 um 08:24 schrieb Emond Papegaaij
> >>> <em...@topicus.nl>:
> >>>
> >>> Hi Tobias,
> >>>
> >>> This is a very nice feature indeed, but be very carefull when exposing
> >>> server-side code to a client. What would happen if some user would post
> >>> 'Java.type("java.lang.System").exit(0)'? A service like this must always
> >>> be protected via some sort of whitelist filter. The Java Scripting API
> >>> has support for ClassFilter, which can be used for this.
Re: NashornResourceReference
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,
I use ScheduledExecutorService and cancel - I am going to submit and show you the changes this evening.
kind regards
Tobias
> Am 07.01.2016 um 10:50 schrieb Emond Papegaaij <em...@topicus.nl>:
>
> Hi Tobias,
>
> How do you terminate a thread? The only way to terminate a Thread from outside is
> Thread.stop, which is very dangerous. Thread.interrupt will only stop de thread if that
> thread supports interrupting. A simple 'while(true);' will not terminate. Even if you manage
> to terminate a script in a few seconds, this will not help against a script like:
>
> var i = 0, o = {};
> while(true) {
> o[i++] = new Array(1000000);
> }
>
> Don't understand me wrong, a resource like this can be useful in some situations, but you
> realy have to make sure it is not exposed to the user, or you will have to deal with rogue
> scripts.
>
> Best regards,
> Emond
>
>> On Thursday, January 07, 2016 10:25:30 AM Tobias Soloschenko wrote:
>> Hi Emond,
>>
>> I already implemented a thread pool which terminates long running scripts. I
>> am going to submit it this evening.
>>
>> Good hint with the class filter - I am going to have a look at it. Thanks!
>>
>> kind regards
>>
>> Tobias
>>
>>> Am 07.01.2016 um 08:24 schrieb Emond Papegaaij
>>> <em...@topicus.nl>:
>>>
>>> Hi Tobias,
>>>
>>> This is a very nice feature indeed, but be very carefull when exposing
>>> server-side code to a client. What would happen if some user would post
>>> 'Java.type("java.lang.System").exit(0)'? A service like this must always
>>> be protected via some sort of whitelist filter. The Java Scripting API
>>> has support for ClassFilter, which can be used for this.
>>>
>>> Another problem is a DoS attack. A user could post several non-terminating
>>> scripts, eating all available processing threads or claim insane ammounts
>>> of memory. These types of attacks are much harder to protect against.
>>> Some scripting engines allow inserting custom code before and/or after
>>> every statement. This could used to protect against non- terminating
>>> scripts. However, preventing OutOfMemory is very difficult (if not
>>> impossible). There are simply too many ways memory can be claimed and no
>>> way of checking the ammount used.
>>>
>>> Best regards,
>>> Emond Papegaaij
>>>
>>>> On Wednesday, January 06, 2016 06:40:53 PM Tobias Soloschenko wrote:
>>>> Hi guys,
>>>>
>>>> I am currently playing around a bit with the nashorn implementation of
>>>> Java 8.
>>>>
>>>> I just implemented a ResourceReference to show up cool features. :-)
>>>>
>>>> Features:
>>>> * Post javascript against the resource reference which is executed on
>>>> server side and optional enriched with user scoped objects that can be
>>>> accessed (read / write)
>>>> * Access to user objects can be setup in the corresponding method
Re: NashornResourceReference
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi Tobias,
How do you terminate a thread? The only way to terminate a Thread from outside is
Thread.stop, which is very dangerous. Thread.interrupt will only stop de thread if that
thread supports interrupting. A simple 'while(true);' will not terminate. Even if you manage
to terminate a script in a few seconds, this will not help against a script like:
var i = 0, o = {};
while(true) {
o[i++] = new Array(1000000);
}
Don't understand me wrong, a resource like this can be useful in some situations, but you
realy have to make sure it is not exposed to the user, or you will have to deal with rogue
scripts.
Best regards,
Emond
On Thursday, January 07, 2016 10:25:30 AM Tobias Soloschenko wrote:
> Hi Emond,
>
> I already implemented a thread pool which terminates long running scripts. I
> am going to submit it this evening.
>
> Good hint with the class filter - I am going to have a look at it. Thanks!
>
> kind regards
>
> Tobias
>
> > Am 07.01.2016 um 08:24 schrieb Emond Papegaaij
> > <em...@topicus.nl>:
> >
> > Hi Tobias,
> >
> > This is a very nice feature indeed, but be very carefull when exposing
> > server-side code to a client. What would happen if some user would post
> > 'Java.type("java.lang.System").exit(0)'? A service like this must always
> > be protected via some sort of whitelist filter. The Java Scripting API
> > has support for ClassFilter, which can be used for this.
> >
> > Another problem is a DoS attack. A user could post several non-terminating
> > scripts, eating all available processing threads or claim insane ammounts
> > of memory. These types of attacks are much harder to protect against.
> > Some scripting engines allow inserting custom code before and/or after
> > every statement. This could used to protect against non- terminating
> > scripts. However, preventing OutOfMemory is very difficult (if not
> > impossible). There are simply too many ways memory can be claimed and no
> > way of checking the ammount used.
> >
> > Best regards,
> > Emond Papegaaij
> >
> >> On Wednesday, January 06, 2016 06:40:53 PM Tobias Soloschenko wrote:
> >> Hi guys,
> >>
> >> I am currently playing around a bit with the nashorn implementation of
> >> Java 8.
> >>
> >> I just implemented a ResourceReference to show up cool features. :-)
> >>
> >> Features:
> >> * Post javascript against the resource reference which is executed on
> >> server side and optional enriched with user scoped objects that can be
> >> accessed (read / write)
> >> * Access to user objects can be setup in the corresponding method
Re: NashornResourceReference
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi Emond,
I already implemented a thread pool which terminates long running scripts. I am going to submit it this evening.
Good hint with the class filter - I am going to have a look at it. Thanks!
kind regards
Tobias
> Am 07.01.2016 um 08:24 schrieb Emond Papegaaij <em...@topicus.nl>:
>
> Hi Tobias,
>
> This is a very nice feature indeed, but be very carefull when exposing server-side code to a
> client. What would happen if some user would post 'Java.type("java.lang.System").exit(0)'?
> A service like this must always be protected via some sort of whitelist filter. The Java
> Scripting API has support for ClassFilter, which can be used for this.
>
> Another problem is a DoS attack. A user could post several non-terminating scripts, eating
> all available processing threads or claim insane ammounts of memory. These types of
> attacks are much harder to protect against. Some scripting engines allow inserting custom
> code before and/or after every statement. This could used to protect against non-
> terminating scripts. However, preventing OutOfMemory is very difficult (if not impossible).
> There are simply too many ways memory can be claimed and no way of checking the
> ammount used.
>
> Best regards,
> Emond Papegaaij
>
>> On Wednesday, January 06, 2016 06:40:53 PM Tobias Soloschenko wrote:
>> Hi guys,
>>
>> I am currently playing around a bit with the nashorn implementation of
>> Java 8.
>>
>> I just implemented a ResourceReference to show up cool features. :-)
>>
>> Features:
>> * Post javascript against the resource reference which is executed on
>> server side and optional enriched with user scoped objects that can be
>> accessed (read / write)
>> * Access to user objects can be setup in the corresponding method
>> * A generic interface to allow third party developers to implement
>> required functionality with java script
>> * Access to any kind of java objects made available
>> * No compilation needed
>>
>> Example of the Reference:
>>
>> https://github.com/klopfdreh/wicket/blob/cafb899d3a6fd61d4e93fc556053df3689b
>> d8ced/wicket-core/src/test/java/org/apache/wicket/resource/NashornResourceRe
>> ferenceTest.java
>>
>> Examples of Nashorn:
>>
>> http://winterbe.com/posts/2014/04/05/java8-nashorn-tutorial/
>>
>> Improvements left to implement:
>> * A timeout that interrupts the javascript engine if the execution takes
>> to long
>>
>> WDYT?
>>
>> kind regards
>>
>> Tobias
>
Re: NashornResourceReference
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi Tobias,
This is a very nice feature indeed, but be very carefull when exposing server-side code to a
client. What would happen if some user would post 'Java.type("java.lang.System").exit(0)'?
A service like this must always be protected via some sort of whitelist filter. The Java
Scripting API has support for ClassFilter, which can be used for this.
Another problem is a DoS attack. A user could post several non-terminating scripts, eating
all available processing threads or claim insane ammounts of memory. These types of
attacks are much harder to protect against. Some scripting engines allow inserting custom
code before and/or after every statement. This could used to protect against non-
terminating scripts. However, preventing OutOfMemory is very difficult (if not impossible).
There are simply too many ways memory can be claimed and no way of checking the
ammount used.
Best regards,
Emond Papegaaij
On Wednesday, January 06, 2016 06:40:53 PM Tobias Soloschenko wrote:
> Hi guys,
>
> I am currently playing around a bit with the nashorn implementation of
> Java 8.
>
> I just implemented a ResourceReference to show up cool features. :-)
>
> Features:
> * Post javascript against the resource reference which is executed on
> server side and optional enriched with user scoped objects that can be
> accessed (read / write)
> * Access to user objects can be setup in the corresponding method
> * A generic interface to allow third party developers to implement
> required functionality with java script
> * Access to any kind of java objects made available
> * No compilation needed
>
> Example of the Reference:
>
> https://github.com/klopfdreh/wicket/blob/cafb899d3a6fd61d4e93fc556053df3689b
> d8ced/wicket-core/src/test/java/org/apache/wicket/resource/NashornResourceRe
> ferenceTest.java
>
> Examples of Nashorn:
>
> http://winterbe.com/posts/2014/04/05/java8-nashorn-tutorial/
>
> Improvements left to implement:
> * A timeout that interrupts the javascript engine if the execution takes
> to long
>
> WDYT?
>
> kind regards
>
> Tobias