|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #80017 Feature request: extend eval() with function/class/variable permission set
Submitted: 2020-08-25 07:00 UTC Modified: 2020-08-25 07:24 UTC
From: alex at alex-at dot net Assigned:
Status: Suspended Package: Program Execution
PHP Version: Next Major Version OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: alex at alex-at dot net
New email:
PHP Version: OS:


 [2020-08-25 07:00 UTC] alex at alex-at dot net
This is a feature request. Alas, I lack the competence to implement it myself.

The request is to basically make initially dangerous eval() really usable to i.e. easily create user expression parsers, without requiring pre-parsing of expression in order to check it.

The idea is to pass additional structure to eval() that specifies explicitly allowed variables of the current scope, functions and classes for the expression - disallowing everything else.

I.e. eval($expr, $limits = null) where $limits contains ['variables' => [...], 'functions' => [...], 'classes' => [...], 'operators' => [...], 'statements' => [...]], each option being defaulted to none (null). The default value of $limits = null provides backwards compatibility (everything is allowed).

Potential usage:

$userInput = '2+2*2'
$result = $eval('return '.$userInput.';', ['operators' => [EVAL_EXPRESSIONS], 'statements' => 'return']]);

will produce 6 as expected. 

If the user input contains something disallowed, like '2+my_func(2*2)', it should throw some exception indicating expression is invalid. But passing 'functions' => ['my_func'] in second argument can allow my_func (i.e. mathematical functions like abs, exp, etc.) to work in the user expressions.

The only remaining danger would be the invalid type returned like array instead of integer, etc., but this would be much easier to post-check.

The things to think on is operator and statement allowance. I know this is complex, but it may be a very handy addition to allow users to provide expressions from interfaces without much extra hassle.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2020-08-25 07:24 UTC]
-Status: Open +Status: Suspended
 [2020-08-25 07:24 UTC]
This feature request requires discussion which is beyond the scope
of this bug tracker.  Please send mail to the internals mailing
list[1].  I'm suspending this ticket for the time being.

[1] <>
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sat Jun 25 12:03:41 2022 UTC