Валидность php-кода перед использованием его в eval()

[Placido]

Возникла необходимость использовать в eval() строку, введенную пользователем на сайте через форму. В связи с этим возникли два вопроса. Первый - как обезопасить себя от возможного "непотребства", которое могут ввести через форму, вроде "echo '<script>...</script>, include и т.п.', и второй - как проверить валидность кода перед вставкой его в eval().

И если по первому вопросу у меня есть мысли, например, проверить введенную строку на содержание "eval(), echo, print и т.д.", то по поводу второго возникли сложности. Если введенный код невалиден, то интерпретатор выдает ошибку парсинга, как отловить которую я не знаю. Пробовал использовать set_error_handler(), но оказалось, что "It is not possible to catch a parse error in eval() using set_error_handler().".

Поэтому прошу помощи. Подскажите, можно как-то проверить валидность php-кода, содержащегося в строке?

 

[Andkorol]

Зачетный способ прострелить себе ногу
В комментариях к eval есть несколько вполне приличных способов отловить ошибки исполняемого кода.
простейший из них

 

[Placido]

...есть несколько вполне приличных способов отловить ошибки исполняемого кода.
простейший из них

В этом простейшем способе меня смущает вот эта строка -

substr($error["message"], "PHP Parse error")

Но даже если ее заменить на

strpos($error["message"], "Parse error")

все равно вылетает

Parse error: syntax error, unexpected...

 

[Andkorol]

Да, замена на strpos в этом примере ничего не решает – т.к. в $error["message"] содержится только текст самой ошибки, без описания типа ошибки (типа "Parse error" и др).
Пример я выбрал неудачный какой-то – странно его присутствие в комментариях оф. мана.

Тем не менее – принцип использовать можно, $error["type"] содержит числовой тип ошибки, соотносимый с предопределенными константами ошибок. По нему можно точно идентифицировать ошибку – и соответственно её обработать.

все равно вылетает
Parse error: syntax error, unexpected...

Это регулируется через error_reporting.

 

[Sufir]

Если не секрет - для чего это? Что за задача, откуда такая необходимость?

 

[Placido]

Есть у меня свой текстовый онлайн-редактор (пока на локалхосте), в котором можно использовать регулярные выражения. Делал для себя - подрабатываю контент-редактором на одном сайте, приходится форматировать много текстовой информации - без регулярок никуда. Правила замены сохраняются по категориям, их можно добавлять, редактировать, группировать, применять по отдельности или группами. До недавнего времени было два типа правил - обычная замена (strtr) и замена по регулярному выражению (preg_replace). Но теперь понадобилось использовать preg_replace_callback. Паттерн и сама callback-функция вводится через форму. Пока все работает ОК, пока я работаю с этим редактором сам, но в будущем планируется разместить редактор на хостинге с доступом к нему других людей. Вот и возник этот вопрос. Если решения не найду, то права на добавление callback-правил оставлю только себе, чтобы не случилось ничего нехорошего.

 

[С.]

До недавнего времени было два типа правил - обычная замена (strtr) и замена по регулярному выражению (preg_replace). Но теперь понадобилось использовать preg_replace_callback.

Через пару итераций можно уже будет это как операционную систему подавать.

Почему даже в оффлайновых редакторах никому еще не онадонилась фича preg_replace_callback, а у тебя в онлайновом и понадобилась?

 

[Absinthe]

Первый - как обезопасить себя от возможного "непотребства", которое могут ввести через форму, вроде "echo '<script>...</script>, include и т.п.'

Никак. Не доверяешь - не делай такой функционал.

и второй - как проверить валидность кода перед вставкой его в eval().

php -l
Только идея глупая.
Плюс не решит проблем типа "функция не существует", т.к. в PHP неполноценный перехват исключений.