>>>>>>>In an application I'm working with, users can insert an expression to be used as a formula to evaluate parameter values. I'm relying on VFP's own parser to do this, but there are many issues involved, including stability and security issues.
>>>>>>>
>>>>>>>I'll need to strip down the parsing to only accept a much more confined set of functions, and to prevent access to variables and run-time objects (starting with _VFP and the likes). I know that this can be done and how to do it, but wonder if anybody has done this previously or know of anything that has been already developed and it is available. For instance, if you authorize your users to edit reports, how do you secure the expressions they insert as field values?
>>>>>>
>>>>>>This is a pain.
>>>>>>
>>>>>>What I think of is
>>>>>>
>>>>>>Basic is to take the expression into a try catch for testing.
>>>>>>After that it's a pain. (But better do the pain before the try catch or the harm is done)
>>>>>>Get the expression, resolve it, typically by transforming into (reverse) polish notation, check the operators, limit it to a set of functions. (any function or operator should be an operator after the transformation). Possibly you can optimize by checking each operator against the list the moment you resolve the operator.
>>>>>>The transformation into polish notation is well known to parse an expression There is good documentaion on the web.
>>>>>>
>>>>>>If you do this for reports, you have to do this for each and every field that can hold an expression
>>>>>>-fields
>>>>>>-variables
>>>>>>-grouping
>>>>>>-PrintWhen
>>>>>>-dynamics
>>>>>>just to name some
>>>>>
>>>>>Thank you for your input, Lutz.
>>>>>
>>>>>Fortunately, there are no reports involved, but since I know people may let users edit reports, I hoped someone would have faced this problem before, and addressed it in some form.
>>>>>
>>>>>The purpose of the process I'm looking for is to limit the access to potentially dangerous objects and functions. So, I think that a simple de-tokenization that can identify authorized functions, and constants in the supported data types, will do. The evaluation will be left to the VFP parser (with proper error handler).
>>>>
>>>>I have no idea what you you mean with de-tokenization here :(
>>>
>>>If I'm not mistaken, he's basically saying that once you've parsed the input string into a sequence of tokens, you can perform a lexical analysis by traversing the parse tree to identify the identifier and check them against a list of what you want to allow or prohibit.
>>
>>If I'm not mistaken, splitting the input into a series of tokens doesn't give you a tree
>>Splitting the input into a series of tokens is called lexical analysis ( Lexer)
>>If you want a (parsing) tree you'll need a grammar and a parser
>
>Yes you're right. I'd skipped a step there (forgot the lexical analysis, which is where the parse tree is generated -- basically noodling out the structure. Or put in simple terms, the parser simply breaks sentence into separate words -- the lexical analysis is where grammar is used to make sense of the words). If we only need to check only against a list of "prohibited" identifiers, then matching the tokens output by the parser is probably OK rather than doing a full lexical analysis. (yep... it's been quite a while since I cracked open the "dragon book")

I think it's the other way around

(1) The lexer splits the input into a series ( or a stream) of tokens - which is what Antonio doing -
https://en.wikipedia.org/wiki/Lexical_analysis

(2) The parser uses a grammar and takes the input ( or stream) of tokens. The parser's job is to construct a tree conforming to the grammar
https://en.wikipedia.org/wiki/Parsing