Hopbot log for 2008-09-15 - Helma IRC channel: #helma on irc.freenode.net

2008-09-15:

[11:46] <_daniel_> anyone ever used flex as helma client interface?
[11:46] <_daniel_> instead of ajax or plain html
[11:48] <zumbrunn> I played around with it, but never productively
[11:48] <zumbrunn> I've been thinking about it again, since they open sourced it
[11:49] <zumbrunn> (I did my playing around with it longer ago)
[14:24] <_daniel_> how did you transfer the data?
[14:25] <_daniel_> xml-rpc, amf, some other blazeds technique?
[14:33] <stoffe> Question about security/sandboxing: is there a mechanism in helma for boxing in untrusted scripts, as in sumbitted from a user?
[14:34] <stoffe> Ideally, a script should be confined to certain allowed calls, I guess
[14:34] <stoffe> But at the very least not have access to java or the server itself :)
[14:35] <jkridner|work> that's an interesting question to me as well...
[14:35] <jkridner|work> I know Rhino has the ability to make new sandboxes, but I'm not aware that Helma has any provisions to extend functionality into those sandboxes.
[14:36] <jkridner|work> The way I've been using it so far, I have full access to the Java runtime.
[14:38] <stoffe> Yes, I saw that rhino had security contexts
[14:39] <stoffe> Not sure how they fit into helmia though :)
[14:39] <stoffe> *helma
[14:46] <zumbrunn> http://helma.zumbrunn.com/reference/app.html#app.invokeAsync
[14:47] <zumbrunn> app.invokeAsync could be used for this, applying a classshutter to the separate thread
[14:47] <zumbrunn> http://helma.org/pipermail/helma-dev/2007-March/003395.html
[14:49] <zumbrunn> really, it would be ideal if better sandboxing would become part of the ecmascript language itself
[14:50] <zumbrunn> for example via a future module system
[14:51] <zumbrunn> the folks at appjet.com claim to have taken js sandboxing with rhino pretty far
[14:51] <zumbrunn> but I don't think there is any code from them
[14:53] <zumbrunn> daniel, json would probably make most sense, or E4X, for flex data exchange
[14:53] <zumbrunn> back then I used xml-rpc
[14:54] <zumbrunn> don't know what options flex offers now for the transport
[14:56] <_daniel_> my problem is that i don't know anything about flex/as in current flash versions at all
[14:56] <_daniel_> so i've no idea what is the best way so that flex/flash has the least effort deserializing the data and making flash as objects out of it
[14:57] <zumbrunn> I would assume amf would be best from that point of view
[14:57] <_daniel_> what i know so far is that adobe blazeds or adobe lifecycle is the prefered way to get data into flex client applications
[14:57] <_daniel_> both however are j2ee apps
[14:58] <_daniel_> so amf might be best for the client but worst for helma
[14:58] <zumbrunn> and they use amf, or what?
[14:58] <_daniel_> yep
[14:59] <_daniel_> i found php implementations for the amf protocol but no js implementations
[14:59] <_daniel_> the ones offered by adobe seem to be the only ones for java, for j2ee servers however
[15:01] <_daniel_> i did not have a look at the amf protocol yet
[15:04] <_daniel_> maybe i should do that first, as it _might_ be easy to translate xml representations of hopobjects to amf, if amf itself is easy
[15:17] <stoffe> The classshutter thing seems interesting
[15:17] <stoffe> can it block helma calls as well?
[15:18] <stoffe> or just java calls?
[15:18] <zumbrunn> "helma calls"?
[15:20] <stoffe> javascript calls, then :)
[15:20] <zumbrunn> :-)
[15:20] <stoffe> maybe I don't understand the whole architecture, but seems that there is plenty to havoc even with all java blocked? =)
[15:21] <zumbrunn> the main way you control what is available is by what you put into the scope object
[15:21] <stoffe> so, all helma-specific javascript calls is probably what I mean
[15:21] <zumbrunn> for example:
[15:21] <zumbrunn> ar scope = context.initStandardObjects();
[15:21] <stoffe> yes, but isn't the other calls available too?
[15:22] <stoffe> ah right
[15:22] <zumbrunn> would but Packages and all the js lingo into the scope
[15:22] <zumbrunn> but not anything helma specific
[15:23] <zumbrunn> then you could first evaluate some code to clean out things like the Packages object
[15:23] <zumbrunn> by passing in a script like "delete Packages;"
[15:24] <stoffe> right, right
[15:24] <stoffe> so the scope could be a new context, then it makes sense
[15:24] <zumbrunn> yes
[15:24] <zumbrunn> var js = Packages.org.mozilla.javascript;
[15:24] <zumbrunn> var context = js.Context.enter();
[15:24] <zumbrunn> var scope = context.initStandardObjects();
[15:25] <zumbrunn> code = "java = undefined; Packages = undefined; " + code;
[15:25] <zumbrunn> result = context.evaluateString(scope, code, '<cmd>', 1, null);;
[15:25] <zumbrunn> or something like that
[15:25] <zumbrunn> (if you are not using app.invokeAsync)
[15:25] <stoffe> right, right
[15:26] <stoffe> that seems workable :)
[15:27] <stoffe> is it possible to be more fine grained, ie, keeping say the Math package of javascript? Or a function? Maybe it's possible to close/copy them before undefining the original?
[15:31] <zumbrunn> yes, sure
[15:32] <zumbrunn> but depending on what you want to hide / keep from being accessible, it quickly gets tricky
[15:32] <stoffe> Yes, I understand that :)
[15:32] <zumbrunn> for example because objects you pass into to scope from the main helma environment might have a getClass method
[15:32] <zumbrunn> and that provides a backdoor back into the main helma scope
[15:33] <stoffe> Ok, right, that's something to look out for alright
[15:34] <stoffe> I think that I'm interested in exporting Math, maybe only parts of that, plus a few non-standard funtions
[15:34] <stoffe> My use case, or what I'm considering is simple AI stuff, controlling a battle bot, that kind of thing
[15:34] <stoffe> So nothing fancy, but some sine and square functions probably come in handy
[15:35] <stoffe> As long as I know it's possible... :D

 

 

In the channel now:

Logs by date: