试图不在php中使用eval（）来评估带有条件语句的字符串

Question

I'm creating a validator that will be able to handle complex conditions by allowing the dev to use a conditional statement in the conditions rules.

Take this example with a set of rules:

...
"element_name":{
     "required": "conditional",
     "conditions" : {
         "requirements" : "(4 < 5)",
         "requirements" : "('something' == 'something_else')" 
     }
}
...

what the PHP will then do is loop through those requirements and evaluate them as code to return a boolean which will determine if the element is required or not.

The problem with using the eval() function is quite obvious. So I'm asking, given that condition statements are what will only be allowed, is there a safer way of doing this than:

$result = eval(element_name->requirements[0]);

Thank you guys.

---- UPDATE -----

Thank you Mike and everyone for the ideas, I wish I could mark you all as the answer because to be quite honest, I ended up using a little bit of everyone's idea. More of Mike's so he gets it.

So, this is probably something that is going to be looked at in the future because it's quite an attractive method of conditionally validating a field. My goal is to create an intuitive way of going about this. I liked the idea of simply slapping in a conditional statement right in the json config file. Of course, this would involve some serious security risks or a super complex parsing engine, so I ended requiring the dev to learn our method of conditional language, but as you will see, I kept it quite similar to the original one. I think it's important to have simple APIs otherwise you'll deter development on your platform. Check it out:

"element_name":{
     "required": "conditional",
     "conditions" : {
         "<" : ['4', '5'],
         "==" : [':element_id', ':other_element'], // will grab the values of those elements and compare
         "exp" : [['something', '==', 'something_else'], 'OR', [':other_element', '!=', '0']] 
     }
}

Answer 1

One solution would be to structure your JSON so that it limits the total set of operations that can be performed. For example

"element_name":{
 "required": "conditional",
 "requirements" : [
        {
            "condition1": 4,
            "condition1": 5,
            "operation": "greaterthan"
        }
}

and then in your PHP (psedo-codey but you can get the idea):

foreach($requirements as $key => $test){
    switch($test->operation) {
        case 'greaterthan':
            return ($test->condition1 > $test->condition2);
        /// put other comparison types here

    }
}

This would mean coding more business logic but would ultimately be safer and would prevent injections like eval .

Answer 2

To expand on dethtron5000's answer, one way I thought of doing this to prevent a ridiculously complex regex is to have the dev break up his conditionals into more of a multi-dimensional conditional thing and loop over it using a recursive function. At each level, you would have an "operator", which would be either "AND" or "OR" (at least I hope this is called an "operator", if not feel free to change it).

In your example you have: (32 < 40 AND 10 > 5 OR 20 == 10)

(It looks like you're json_encoding the conditionals, so I started with the following PHP array and worked backwards from there. I'm assuming you can just json_decode what your dev provides you to get a valid PHP array). The above example would be represented as the following PHP array:

$arr = array(
    'required' => 'conditional',
    'conditions' => array(
        'requirements' => array(
            'operator' => 'OR', // this makes it so that if any conditions at this level are true, it returns true
            0 => array(
                'operator' => 'AND', // this makes it so that all the conditions at this sub-level need to be satisfied to return true
                array(
                    'conditional1' => 32,
                    'conditional2' => 40,
                    'operation' => 'lessthan',
                ),
                array(
                    'conditional1' => 10,
                    'conditional2' => 5,
                    'operation' => 'greaterthan',
                ),
            ),
            1 => array(
                // Since there is only one condition here, it is not necessary to specify "AND" or "OR"
                array(
                    'conditional1' => 20,
                    'conditional2' => 10,
                    'operation' => 'equals',
                ),
            ),
        ),
    ),
);

You can then loop through the conditionals with a recursive function like this:

function check_req(Array $reqs) {
    $operator = (isset($reqs['operator'])) ? $reqs['operator'] : 'AND';
    unset($reqs['operator']);
    foreach ($reqs as $req) {
        if (isset($req['operation'])) {
            switch ($req['operation']) {
                case 'lessthan':
                    $valids[] = $req['conditional1'] < $req['conditional2'];
                    break;
                case 'greaterthan':
                    $valids[] = $req['conditional1'] > $req['conditional2'];
                    break;
                case 'equals':
                    $valids[] = $req['conditional1'] == $req['conditional2'];
                    break;
            }
        }
        else {
            $valids[] = check_req($req);
        }
    }
    if ($operator == 'OR') {
        foreach ($valids as $valid) {
            if ($valid == true) {
                return true;
            }
        }
        return false;
    }
    else {
        foreach ($valids as $valid) {
            if ($valid == false) {
                return false;
            }
        }
        return true;
    }
}

var_dump(check_req($arr['conditions']['requirements'])); // true in this case

When I json_encode it, I get:

{
    "required":"conditional",
    "conditions":{
        "requirements":{
            "operator":"OR",
            "0":{
                "operator":"AND",
                "0":{
                    "conditional1":32,
                    "conditional2":40,
                    "operation":"lessthan"
                },
                "1":{
                    "conditional1":10,
                    "conditional2":5,
                    "operation":"greaterthan"
                }
            },
            "1":[{
                "conditional1":20,
                "conditional2":10,
                "operation":"equals"
            }]
        }
    }
}

I'm assuming this is what the dev would have to provide you.

Answer 3

To decompose the initial text, could you use json_decode()? This won't run anything, but will covert your big string into an array structure.

For the actual individual expressions, do you have access to parsekit_compile_string ?

This would allow the raw text to be converted into php bytecode ops. It shouldn't be hard to interpret the ops via a switch statement. Due to the constrained nature of what you said you expect in the requirements, this wouldn't be much code.

One could attempt regex without parsekit_compile_string , but this would be a more brittle solution.

Answer 4

Yes - you can use a switch statement vis:

switch($operator)

 case "==":
 return $a==$b;
 break;
 case "+":
 return $a+$b;
 break;

 etc...

 default:
 return false;
 break;

The key is how to send the parts to the switch - there are many ways after all.

It would be mad to expose eval() to untrusted user code. I can see its use in situations like Drupal, where the uber-users can create PHP pages which are then evaluated as such, but of course only trusted users can do that. Far better to restrict the code that can be run in this way.

EDIT:

In order to handle multiple operators, you still run this as your arithmetic unit, but you need to evaluate each operator separately. This may mean you have to evaluate an instruction string one character at a time to pick up such as brackets. It may be better to do the math in javascript on client side. This is safe as long as the answer is not sent to your server (eval in JS can lead to DOM injection attacks)

If I might make an impertinent suggestion, do you REALLY need to do it this way? Is there a better way, perhaps one that will deal with the input in smaller chunks? If I were using this system, I'd probably pick up a desk calculator to do the work rather than use a website! Try to do more of your users' work for them.