Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Parsing conditional expressions

by Wonko the sane (Deacon)
on Mar 23, 2004 at 13:38 UTC ( [id://338989]=note: print w/replies, xml ) Need Help??


in reply to Parsing conditional expressions

Hello

I would be very interested in knowing why one would need a conditional conditional statement.
This seems like a very complex widget to need.

Wonko

Replies are listed 'Best First'.
Re: Re: Parsing conditional expressions
by halley (Prior) on Mar 23, 2004 at 13:48 UTC

    I don't know what the OP is requesting, but two major applications of this sort of technique would be database queries and message filtering, both according to user-supplied (or larger application configurable) criteria.

    [For caveats re: 'user' and 'database', see my reply to dragonchild below.]

    For example, SpamAssassin is basically a big user-criteria engine: it consults a list of user-supplied criteria and tallies a score total of matching ones, for each e-mail it inspects.

    --
    [ e d @ h a l l e y . c c ]

      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.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        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.

        --
        [ e d @ h a l l e y . c c ]

Re: Re: Parsing conditional expressions
by Lorand (Beadle) on Mar 23, 2004 at 14:15 UTC
    I need this to match some packets stored in XML (actually PDML) format. I use XML::Parser to parse the document, and when I detect an end tag </packet> I want to see if that packet meets some conditions or not.

    I need this to determine some phases of the packet flow, so I will have about 6 packet types that have to be matched, and that has to be extensible and easily modifyable, so I don't want to hardcode it. Security is not a concern, it's for a personal project.

    Thanks for the answers so far.

      Create a class called Packet and subclasses called Packet::TypeA, Packet::TypeB, etc. Then, using a factory, create the appropriate subclass. Have each subclass know how to validate itself. No need for eval.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        OK, I didn't think of this, it seems to be the best solution, however I don't know what a factory is, and couldn't find anything that would make that clear... Could you point me to some relevant documentation, maybe a place with examples?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://338989]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (2)
As of 2024-04-26 03:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found