Hi Sven, I personally dislike to interrupt a JEE Thread. ;-)
kind regards Tobias > Am 26.01.2016 um 11:55 schrieb Sven Meier <[email protected]>: > > 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 >
