And you trust your users why?

[dragonchild]

Database queries?? I don't think so. If you're letting your user tell you what query you're going to run, you're asking for bankruptcy. I would never allow my users to construct queries through a Perl app. If they need to be constructing queries, give them SQL*Plus access. It has had 9 major revisions to get security and other issues correct. Plus, they'll be executing based on the roles they were granted, not the roles the application was granted.

Personally, I tell my users "Please choose from the following options" which I have supplied to them. I then combine those options according to a very flexible (but rigid) set of rules to construct the query on the fly.

As for message filtering ... you don't need to use eval, there, either. You use either dispatch or switch statements. Unless, of course, you like playing on the edge. I do something exactly like this in PDF::Template, in my <if> node. You get to indicate the LHS, RHS, and the operator. If I don't recognize the operator, then it's a numeric equality check. If you don't like that, tough. And, it's the same with the mathematical operators. You get the four basic ones. Anything else and I complain. Loudly.

You can never NEVER trust your users, even if it's just to keep them from typing 'rm -rf /' accidentally.

[halley]

Wow, sounds like you got your knickers in a bunch over some unfounded assumptions.

I didn't say that database queries were always the full-blown enterprise/ecommerce type. There are simpler databases of one form or another in just about any application. At the lowest level, any perl instance of grep { } is a database query: it's scanning and selecting data elements from a dataset which match a criteria.

I didn't say that I would use Perl for my user-supplied criteria mechanism in most database-centric applications, especially criteria that are tainted by being input by any old end-user.

Think about what a SQL server really is, architecturally. A SQL statement IS a user-supplied criteria. The SQL database must (1) parse the criteria specification (using SQL syntax rules), then (2) compare the appropriate database structures for complying entries.

There are also different concepts of "user." A system administrator is a "user." A program script which does a use MyModule; is a "user" of that module. The user-supplied criteria may not be accessible to the Joe "dubya dubya dubya" Point-n-Drool web surfer, but it's still sitting in the ~/.shoppin-cart-a-rama.rc for the web administrator to, well, administer.

And that's why I said, rightfully I think, that there are security issues in using eval in this context. Not all security issues are show-stoppers, but they're each a chance to make a reasoned and complete review of various methods of data attack. If you can successfully block all reasonable and timely data attacks, then the security issue has been resolved.

[dragonchild]

IMHO, you're comparing apples and oranges. There is a major difference between clients and users. Programs are not "users". They are "clients". They have a well-defined, well-formed, and limited usage of a supplier's capabilities. They are trusted.

People, on the other hand, are "users". They are not well-defined, well-formed, nor are they limited in their capability to err. Programs that deal with "users" must take this into account. (The exception is administrator-type "users", which are trusted, so they can be considered "clients".)

I don't think that suggesting eval here without knowing more about what the OP wants to do is valid. It turns out that the OP's need is better served through other means. eval, imho, is meant for two situations:

1. Quick'n'dirty hacking on a problem in a one-off situation
2. Situations where there simply is not any other method of solving the problem

It doesn't appear that either situation applies here.