Ok, I think that's what you get if you forget a tiny little detail and that is enough so everything is discussed just not what you wanted to know :)
My concern is not security. I know pretty well it would be a stupid to let anyone inject smalltalk code via http interface. If I were about security I would do the same as Esteban: Defining a allowed set of operations and make classes for them. My point is that it is purely internal what I like to use. And I think I would like it not to be restricted in the kind of queries I do. Hence the idea of using smalltalk. I'm only interested in the drawbacks that blocks might have. As they are created from string to only thing they might depend on context-wise would be self (if I decide to use a helper). My question was if there is anything besides that could make the use of blocks and serializing/materializing troublesome. thanks, norbert Am 14.07.2014 um 21:05 schrieb Dale Henrichs <[email protected]>: > Ben, > > It's not just Global references that you have to worry about ... `self > environment` is an easy way to get direct access to `Smalltalk` ... you can > use `self superclass superclass subclasses...` to navigate to just about any > class in the system ...and this is only with a couple minutes of thought:) > .... to be truly safe you have to work a bit harder and construct a sandbox > that is a subset of the standard environment ... > > Dale > > > On Mon, Jul 14, 2014 at 11:05 AM, Ben Coman <[email protected]> wrote: > Esteban A. Maringolo wrote: >> >> Are you going to be the end user of this? >> >> I wouldn't let users compile whatever Smalltalk expressions they want. >> You can't scope the globals that can be accessed by the compiler. >> > > CompilationContext had instance variable /environment/ that contains a > SystemDictionary(lots of globals). I wonder how effective it would be, or > how horribly it would break things, to change that for a limited list. > cheers -ben > > >> What I would do is model a hierarchy of "Condition" objects used by >> "Filter" objects, which are composable, and know how to translate >> themselves to SQL, Mongo condition, or even Smalltalk expressions to >> apply the conditions to a collection of objects. >> >> The other way is to have a DSL, but that's a longer road if what you >> plan is simply to apply filters. >> >> We've done both in my previous job and worked perfectly. >> >> >> Regards! >> >> >> >> Esteban A. Maringolo >> >> >> 2014-07-14 12:19 GMT-03:00 Norbert Hartl <[email protected]>: >> >>> I was looking for a solution where I can have a textual grammar for a DSL >>> in order to specify filters on objects. I didn't really search the net >>> because I know a cute little DSL for that already. It is called smalltalk, >>> you might have heard of it. >>> >>> So what I do is putting the filter spec into the image via an http >>> interface, materialize the filter in image and store it in a database to >>> have them survive image restart. A filter spec could look like this >>> >>> [ :value | ( self sectionLabelOf: value ) = 'device' ] >>> >>> I want to know if there is any trouble to expect if I'm using plain block >>> syntax for that task. As the blocks are injected using an http interface >>> there is no environment/context problem. I would have some helper class as >>> a facade to ease the filtering let's call it >>> >>> FilterHelper (would have a class side method #sectionLabelOf:) >>> >>> So getting the block code via HTTP I could do >>> >>> block := Smalltalk compiler >>> evaluate: request contents >>> for: FilterHelper >>> logged: false >>> >>> And I would serialize it into a database as a string again doing >>> >>> self store: block sourceNode formattedCode >>> >>> Are there any possible drawbacks using it this way? >>> >>> thanks, >>> >>> Norbert >>> >>> >>> >> > >
