Комментарии 18
странно что у вас функции в одном классе имеют разный стиль именования
Да, php_syntax_error была честно украдена с php.net и немного исправлена/подправлена.
validatePHPCode — уже потуги моего сознания.
Согласен, что стиль разный и надо бы все унифицировать.
validatePHPCode — уже потуги моего сознания.
Согласен, что стиль разный и надо бы все унифицировать.
Имеется еще вот такое решение github.com/fieryprophet/php-sandbox
Да, это решение выглядит намного полнее. Хотя на первый взгляд и намного более громоздкое.
С другой стороны, проверка кода идет с использованием статического анализатора, что теоретически может не полностью совпадать с поведением PHP ( к примеру анализатор без проблем анализирует неймспейсы, тогда как PHP в текущей версии может их не поддерживать).
С другой стороны, проверка кода идет с использованием статического анализатора, что теоретически может не полностью совпадать с поведением PHP ( к примеру анализатор без проблем анализирует неймспейсы, тогда как PHP в текущей версии может их не поддерживать).
Символично, что статья написана в песочнице.
А разве runkit под виндой не работает? Вроде подробные инструкции для сборки php_runkit.dll есть.
Работает, но нужны лишние движения.
Когда в команде удаленно работает несколько разработчиков (ну разработчики еще ладно), 2 дизайнера и у всех разные операционки, то не очень хочется всех их консультировать как заставить проект работать.
С другой стороны, конечно, это не относится к сути проблемы. Runkit делает работу лучше. Но нам на данном этапе было проще использовать вышеприведенный класс. Свои базовые задачи он решает без проблем.
Когда в команде удаленно работает несколько разработчиков (ну разработчики еще ладно), 2 дизайнера и у всех разные операционки, то не очень хочется всех их консультировать как заставить проект работать.
С другой стороны, конечно, это не относится к сути проблемы. Runkit делает работу лучше. Но нам на данном этапе было проще использовать вышеприведенный класс. Свои базовые задачи он решает без проблем.
Можно же легко обойти ограничения вызоыва функций через call_user_func или даже через хитрый eval.
Хотя ничего не стоит добавить эти функции в список запрещенных изначально.
Нужно об этом не забывать.
Хотя ничего не стоит добавить эти функции в список запрещенных изначально.
Нужно об этом не забывать.
include и require пропускаются специально?
Нет, нужно добавить их обработку. Спасибо
еще из возникших непоняток.
1. пропускает вызов конструктора без параметров и скобок и дальнейшие вызовы методов созданного инстанса
2. пропускает статические вызовы через
В совокупности с наличием ООПных системных интерфейсов типа SplFileInfo указанные выше пункты кажутся потенциально опасными, хотя сходу что-то плохое не придумывается.
1. пропускает вызов конструктора без параметров и скобок и дальнейшие вызовы методов созданного инстанса
class test {
public function method($a) {
echo $a;
}
}
$test = new test;
$test->method('in method');
2. пропускает статические вызовы через
class test {
public static function stat() {
echo 'static';
}
}
$class = 'test';
$class::stat();В совокупности с наличием ООПных системных интерфейсов типа SplFileInfo указанные выше пункты кажутся потенциально опасными, хотя сходу что-то плохое не придумывается.
Вызов конструктора без параметров это нормально для PHP. В любом случае проверка синтаксиса делается на стороне PHP, я никак этим не занимаюсь.
По поводу вызова методов созданного класса — это сделано специально. Пользователь может насоздавать сколько угодно внутренних классов и функций. Главное, чтобы он за описанные рамки песочницы не выходил.
SplFileInfo — пользователь не сможет вызвать его, если не разрешим ему это явно.
По поводу вызова методов созданного класса — это сделано специально. Пользователь может насоздавать сколько угодно внутренних классов и функций. Главное, чтобы он за описанные рамки песочницы не выходил.
SplFileInfo — пользователь не сможет вызвать его, если не разрешим ему это явно.
А унаследоваться от него?
Под пунктом 1 имелось ввиду, что при одинаковых настройках — разрешено только echo — код
не пропускается, а по сути аналогичный код без скобок — пропускакется.
и это как-то странно на мой взгляд.
class test {
public function method($a)
{
echo $a;
}
}
$test = new test();
$test->method('in method');
не пропускается, а по сути аналогичный код без скобок — пропускакется.
class test {
public function method($a)
{
echo $a;
}
}
$test = new test;
$test->method('in method');
и это как-то странно на мой взгляд.
Пропускается и со скобками и без скобок: ideone.com/e1qx28
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Песочница для PHP