If you only one to expose the JS code to do expressions, you can define a concrete and reduced context where the expression will be executed. For example, if you want to evaluate the price, just add all the properties you may need (probably all properties of the item bean) to the script execution bindings. The creation of this bindings may not be shared between client and server, but it's not complicated. Access random internal classes like MyClass::getSomethingUseful it's a bad idea, it's better to expose explicit binding, so if you want to expose MyClass::getSomethigUseful you may add a util object with a getSomethigUseful method, this is safer, and also solves your client/server problem. Although, the process to add this methods to the context may also be a little different between client and server.
This reduced context also is a good idea to reduce your second big problem, the security! Execute dangerous code through this script it's very easy, and restrict the access it's difficult. There are a lot of articles and discussions like http://stackoverflow.com/questions/1399505/sandboxing-jsr-223. I try to do something similar, but I end up using Groovy (only server) because this utility http://groovy.codehaus.org/api/org/codehaus/groovy/control/customizers/SecureASTCustomizer.html 'solves' the security problem. On Saturday, May 10, 2014 4:29:56 PM UTC+2, Phineas Gage wrote: > > I am writing a GWT app that will be usable by multiple customers. I'd like > for my customers to be able to customize the app, both on the server side > and client side by writing JavaScript. In other words, they could do things > like: > > - Set some configuration for their site, like its name, their web site > URL, address, items on their site, etc. > > - Write a JavaScript function to, for example, calculate the price for > some item based on its properties. So the price calculation could be done > on both the client and server, and no recompiling would be needed to change > the price calculation. > > The beauty of this is that they could write the JavaScript, and it could > be run using JSNI on the client and Rhino on the server, giving consistent > results. This could also get me out of the business of writing a bunch of > administrative UI code to handle the many possibilities for customization > that customers would want, and also give them much more flexibility, > particularly for price calculations, where the customers want endless > flexibility, and writing a rules engine to handle all of those cases would > be very complicated. > > Obviously, the JavaScript they write has to be runnable on both the client > and server. And, if it's just a matter of returning primitives or the > customer writing functions that take and return primitives, it's easy. > Simple JavaScript code snippets like this: > > var myname='Joe'; > > function getMyName() { return 'Joe' }; > > can be syntactically the same for both JSNI and Rhino. > > But the fun soon ends. Let's say I want to allow them to call into methods > in Java classes that I've defined, so I can give them an API to do useful > things. The syntax for accessing Java objects from JavaScript is vastly > different between Rhino and JSNI: > > // Rhino > com.abc.package.MyClass.getSomethingUseful(); > > // JSNI: first in Java > public static native String exportGetSomethingUseful() /*-{ > getSomethingUseful = > $entry(@com.abc.package.MyClass::getSomethingUseful()); > }-*/; > > // JSNI: then in JavaScript > getSomethingUseful(); > > The situation gets more challenging if you want to pass instances of your > own Java classes into JavaScript for their use, or call from JavaScript > into APIs defined in Java. You've got to define host objects in Rhino, and > I'm not even sure how you do it in JSNI without writing glue code by hand > so that they wouldn't have to learn JSNI's arcane syntax, > > My question is: I don't think it's possible for the JavaScript syntax to > be the same between JSNI and Rhino without writing some glue code on both > the client and server in JavaScript to insulate them from these syntactical > differences when working with APIs defined in Java. Am I right, or have I > missed anything? > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
