Req #80017 [Opn->Sus]: Feature request: extend eval() with function/class/variable permission set
Edit report at https://bugs.php.net/bug.php?id=80017&edit=1
ID: 80017
Updated by: cmb@php.net
Reported by: alex at alex-at dot net
Summary: Feature request: extend eval() with
function/class/variable permission set
-Status: Open
+Status: Suspended
Type: Feature/Change Request
Package: Program Execution
PHP Version: Next Major Version
Block user comment: N
Private report: N
New Comment:
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] <https://www.php.net/mailing-lists.php#internals>
Previous Comments:
------------------------------------------------------------------------
[2020-08-25 07:00:57] alex at alex-at dot net
Description:
------------
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.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=80017&edit=1
Thread (2 messages)