Hopbot log for 2008-08-25 - Helma IRC channel: #helma on irc.freenode.net
2008-08-25:
[20:09] <daniel_> may i ask all of you for your attention for a quick poll:[20:09] <midnightmonster> attending!
[20:09] <daniel_> are you using helma's log facilities or are you using an external log facility such as log4j?
[20:09] <daniel_> (-:
[20:10] <midnightmonster> so far I'm logging to console while developing and don't have anything very systematic for logging besides that
[20:10] * midnightmonster is useless
[20:12] * daniel_ thinks that helma's logging support is obsolete and should be deprecated. everything done by helma logging can and should be done by log4j by delivering a default configuration which lets log4j behave as helma's current logging system
[20:13] <midnightmonster> sounds reasonable to me
[20:14] <daniel_> the only advantage in keeping helma's logging system is to advoid to have another jar dependency, but distribution file size shouldn't be a problem anymore nowadays anyways
[20:14] <osimons> daniel_: i've just looked at helma for a few hours, but just 10 minutes ago i reviewed this for helma-ng: http://dev.helma.org/ng/helma.logging/ - seems the project is heading in your direction...
[20:16] <daniel_> sorry to not have it mentioned, i was only talking about helma 1.x
[20:19] <osimons> yeah, understood that - mine was more a general observation about the future. my 3 hours of helma experience does not put me in a position to advice about anything... :-)
[20:24] <osimons> anyway, the reason i came here was a question: it seems that helma just uses the rhino policy of making all java classes available to scripts, and no obvious ways of restricting that by configuration? how would i hook in org.mozilla.javascript.ClassShutter? do i need to rewrite the core server and dispatcher code?
[20:25] <daniel_> btw: helma 1.x already supports using log4j or any other logging system, my motivation is to get rid of partially reinvented wheels which exist in helma 1.x currently
[20:26] <daniel_> to have a quick answer to your question: no, it can be done by configuration
[20:26] * osimons thinks js script opening java.awt UI frames on the server isn't so cool...
[20:27] <daniel_> agreed, let me have a quick look in the source to see what would be the easiest way for doing something like this
[20:27] <osimons> daniel_: no, it can - or no it can't? a bit unclear phrasing...
[20:27] <daniel_> (in helma 1.x (-;)
[20:27] <daniel_> oh sorry...
[20:27] <daniel_> no it can't
[20:28] <osimons> daniel_: yeah, whatever version - as mentioned, i'm just reviewing atm but a sandbox with classshutter and/or security would be needed.
[20:28] <midnightmonster> osimons, yeah, but Helma mostly assumes that you're writing your app in JavaScript, not that it's something analogous to decoration for webpages as in the browser. So there are ample ways to hang yourself as in any competent environment.
[20:29] <daniel_> easiest way would be to extend org.helma.main.HelmaSecurityManager
[20:33] <osimons> daniel_: thanks. that looks a useful starting point. new securitymanager + roll my own run-code.
[20:34] <daniel_> what do you mean by run-code?
[20:35] <osimons> servlet-like code that instantiates the various contexts, i suppose?
[20:38] <daniel_> if your only goal is to prevent access to specific java classes or the other way around (to limit access to specific java classes), it should be enough to extend the security manager. i didn't try it but i don't see a reason for doing anything more than that.
[20:40] <osimons> daniel_: really? just make my own that extends it, and that will be used instead if found on classpath?
[20:40] * osimons is a java noob as well... just doing python today...
[20:41] <daniel_> let me check something in the docs...
[20:42] * daniel_ ... well lets just say it ... hates incomplete docs (-:
[20:43] <daniel_> i've just found a hidden feature that lets you configure the security manager
[20:43] <osimons> oh? nice!
[20:43] <daniel_> so yes, extending the seucurity manager and telling helma to use it is all you need to do
[20:44] <daniel_> global / server-wide property setting securityManager
[20:44] <daniel_> zumbrunn, got some work for ya (-;
[20:45] <daniel_> securityManager, global: class name of security manager to use instead of helma's default security manager which by the way allows to do everything except exiting the jvm or setting another security manager
[20:46] <osimons> hehe. thanks. very interesting.
[20:48] <daniel_> you're welcome
[20:49] <daniel_> out of curiosity, what are you using currently that you eventually would want to replace with helma?
[20:58] <osimons> daniel_: not really replacing, more building a cluster service/application to execute arbitrary code from users - and therefore i want to make select functionality available with a predefined api based on allowed classes/modules
[21:00] <osimons> daniel_: much in the spirit of http://code.google.com/appengine/docs/python, allthough i'm not exactly google... ;-)
[21:02] <daniel_> do you focus on hosting helma applications or arbitrary js applications?
[21:03] <osimons> daniel_: my now 4 hours of helma investigation is not exactly enough to determine anything...
[21:04] <osimons> but, with regards to storage and the like, some app contruct is likely the most viable alternative to separate - like helma
[21:06] <daniel_> btw, i've written a helma 1.x plugin recently, that allows helma applications to be developed in php
[21:06] <daniel_> http://sourceforge.net/projects/warpapps
[21:07] <osimons> but, what i like is rhino, the security and context/scope/sandbox evaluation of scripts - the template/macro/dispatch code and so on did not trigger my enthusiasm
[21:07] <daniel_> although not yet complete, its quite stable and usable. i am planning to develop even more additional scripting environment plugins
[21:08] <osimons> daniel_: they are more rhino/javax.scripting plugins rather than tied to helma?
[21:10] <daniel_> no they are more tied to helma
[21:11] <osimons> ah. a helma plugin - spotted it now on sf. haven't gotten around to plugins yet - i'll glance over your code though to see what that entails, though. thanks for the pointer.
[21:13] <zumbrunn> what's the deal with the securityManager stuff?
[21:13] <zumbrunn> how does one use it?
[21:14] <zumbrunn> not sure what to document how exactly
[21:14] <daniel_> read my message above?
[21:14] <zumbrunn> yes
[21:14] <daniel_> it allows to set a java security manager that replaces helma's default security manager
[21:15] <daniel_> helma's default security manager only prevents apps from exiting helma and (re-)setting the security manager
[21:16] <zumbrunn> is that directly related to class shutters? or is that completely separate?
[21:16] <daniel_> what are class shutters (-: ?
[21:16] <osimons> separate
[21:16] <osimons> hang on.
[21:16] <zumbrunn> btw, app.invoke() and app.invokeAsync() are important in that context
[21:17] <zumbrunn> because they allow you to easily run code in a different scope/context
[21:17] <zumbrunn> and to lock its access down independently of the main helma host environment
[21:17] <osimons> http://www.nabble.com/Can-I-disable-the-ability-to-call-java-code-from-rhino--td15015838.html
[21:18] <daniel_> ok got it, thanks.
[21:18] <osimons> => both the rhino class invokation filter (ClassShutter) and java security can do the job it seems, but they are not related
[21:19] <osimons> http://www.mozilla.org/rhino/apidocs/ - ClassShutter is down on the left there
[21:20] <daniel_> i'd guess the class shutter approach can do it in a more fine grained way compared to what the java security manager can do as the extending the helma default security manager knows about the app context, but not anything deeper
[21:20] <osimons> right - but both can also be used without problem, from what i read
[21:21] <daniel_> hm... class shutter is an interface
[21:21] <daniel_> so wouldn't one need to change all java default class implementations to aplly filtering (-; ?
[21:22] <osimons> daniel_: it is like file access - where the classshutter can only allow/disallow the use of some file module (all or nothing). however with security policy, file classes can be available, but usage restricted
[21:22] <osimons> daniel_: no, the filtering is done by the scripting context i think as things pass between java and js
[21:24] <daniel_> ya agreed, but only java classes implementing class shutter could be filtered or is there a default setting like restrict access to java classes that do not implement the class shutter interface?
[21:24] * osimons did not intend to make such an astute 'no' as he really hasn't tried this well enough yet...
[21:24] <daniel_> well it looks like.
[21:25] <daniel_> to me it looks like class shutter is the best approach for classes provided by the application server, helma in this case
[21:25] <osimons> daniel_: right, so you need it in the core servlet/dispatch code when you set up the context/scope for the execution of the individual app - i think
[21:25] <daniel_> whereas the more generic security manager approach can be used for any java class including java classes you can't or do not want to change
[21:27] <osimons> yes - like with securitymanager and checkRead/Write/Delete for instance I could restrict file access to the app directory for instance
[21:27] <daniel_> just found out that i didn't read far enough (-:
[21:28] <daniel_> class shutter is the way to go
[21:28] <daniel_> my first (wrong) impression was that any class that you want to be filtered needs to implement the class shutter interface (-;
[21:29] <osimons> so, same approach the and helma could in theory have a default classshutter implementation and config to supply optional customized to use?
[21:29] <daniel_> yes
[21:29] <daniel_> could be implemented quite easy
[21:31] <daniel_> chris, as this would result in new configuration properties, wouldn't it btw nice to have all properties only influencing one specific scripting engine in its own properties file?
[21:37] <osimons> daniel_: that php thing of yours, what is that? does that basically replace the macros/skin main code with something that pass it off to php for rendering and return content?
[21:37] <daniel_> osimons: i've added class shutters to my list of nice-to-haves (http://dev.helma.org/wiki/HOWTO+improve+Helma+1.x/)
[21:38] <daniel_> helma 1.x skins and macros are implemented in java as part of the core framework. so not, php does not change the behaviour of scripts or macros in any way.
[21:38] <daniel_> it only allows you to write applications in php instead of js.
[21:39] <daniel_> but like js accesses java objects of the core framework, php does it too.
[21:40] <osimons> daniel_: ok, i see. so all the benefits of the java/rhino/core but with a lower barrier for adoption for app makers?
[21:40] <osimons> thanks for adding the improvement request. i take it you are a dev then?
[21:41] <daniel_> all the benefits of the java/core, and yes, the motivation to write it was to have lower barriers for app makers
[21:41] <daniel_> as of helma 1.x you can only use one scripting engine per application
[21:42] <daniel_> but of course it would be even better to have all the benefits and possibilities and have as much different scripting languages per applications as you like
[21:44] <daniel_> yes, i a helma dev (although i've just returned back to helma some weeks ago after not doing any helma development within the last years)
[21:49] <osimons> daniel_: ah. found it - scriptingEngine = org.warp.scripting.quercus.QuercusEngine - that is then a php implementation in java, right?
[21:50] <daniel_> correct
[21:50] <daniel_> it is offered under a dual license. the gpl version lacks compilation support )-:
[21:51] * osimons heads over to the jython project to check status there...
[21:51] <daniel_> www.caucho.com/quercus
[21:52] <daniel_> first page @ jyathon says: Dynamic compilation to Java bytecodes - leads to highest possible performance without sacrificing interactivity.
[21:52] <daniel_> looks like jython might be my next plugin (-:
[21:53] <daniel_> i do however completly lack python experience
[21:53] <osimons> hehe. yes, please :-)
[21:54] <osimons> nah. don't let me hassle you. you been most helpful so far - i'm a happy camper for now :-)
[21:54] <daniel_> so i might be able to write the plugin.. willing to port my welcomePhp application once done?
[21:55] <daniel_> (-:
[21:56] <osimons> hehe. looks like most code will follow same structure, so that is easy. templating in python is messy, though - some 377446 different alternatives... php easier that way...
[21:56] <osimons> ah - no. it is just code. you use the skin thingy of course.
[21:59] <osimons> from what it looks like, that just means translating the .php files to identical .py syntax? if so, then certainly possible...
[21:59] <daniel_> correct.
[22:00] <daniel_> as i do not know anything about python so far, is there any site out there?
[22:00] <daniel_> something like "python4java geeks" (-:
[22:01] <osimons> http://diveintopython.org/ - generally nice intro book (online)
[22:01] <daniel_> so lets dive into it (-:
[22:03] <osimons> hehe. you help me with java code and my 'sandbox', and i'll help you with python code - no problemo :-
[22:04] <daniel_> you need to know that i've not written the php plugin because i personally would prefer to write helma applications in php, i've written it to see how well helma is capable of handling different scripting environments (as js has been the only one for years). i am quite interested in writing a plugin for as many scripting languages out there as possible
[22:05] <daniel_> so that one can always choose whats best for a specific helma application or his/her personal preference
[22:05] <osimons> that sounds like a very good ambition
[22:06] <daniel_> i will even write one for bash (-;
[22:06] <osimons> from what i read earlier today on my foray into java scripting, it seems java6(?) adds the same ambition with the javax.scripting stuff?
[22:07] <daniel_> i didn't have a closer look at this effort yet, but i guess it would allow me to write an abstract helma scripting engine plugin which could make use of any javax.scripting language
[22:10] <osimons> beats me, could not find the reference again in my close to 100 open browser windows, but integrating rhino in an extensible scripting frameworks seemed to be the gist of it iirc
[22:25] <daniel_> hm...