Evaluating user-defined conditions
andy at andybev.com
Tue Jun 10 11:12:02 BST 2014
On Tue, 2014-06-10 at 11:37 +0200, Abigail wrote:
> On Tue, Jun 10, 2014 at 09:26:17AM +0100, Andrew Beverley wrote:
> > On Tue, 2014-06-10 at 09:20 +0200, Abigail wrote:
> > > > # Sanitise
> > > > $_ = $code;
> > > > return unless /^[ \S]+$/; # Only allow normal spaces
> > > > return if /[\[\]]+/; # No brackets should remain
> > > > return if /\\/; # No escapes please
> > > > s/"[^"]+"//g; # Remove quoted strings
> > > > m!^([-()*+/0-9<> ]|&&|eq)+$! or return; # Allowed expression chars
> > >
> > >
> > > So, you excluding having any alpha char (except 'eq') in the resulting
> > > expression? Because that's what the last line does. Perhaps that's your
> > > intention, because I've no idea what $value is going to be, other than
> > > "it could be a string in quotes".
> > Yes, $value is either an integer or a string in quotes. The 2 lines
> > previous to the last line should remove any string in quotes, therefore
> > just leaving operators and integers?
> So, your loop replaces [$var] with a string in quotes, only for s/"[^"]+"//g;
> to remove it? I'm a bit confused what purpose that serves.
The code that's run is what is in-between those 2 statements. The latter
is a sanity check. I didn't explain that properly.
> Considering that you want to be really restrictive, a parser is going to
> be quite simple. Why not just write a parser instead of hoping you've
> catched anything potentially bad?
Because it was 2am and I needed something for a demo today ;-)
But yes, I agree that's the best way.
More information about the london.pm