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 <dale.henrichs@gemtalksystems.com>:

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 <btc@openinworld.com> 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 <norbert@hartl.name>:
  
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