Comments 18
странно что у вас функции в одном классе имеют разный стиль именования
Да, php_syntax_error была честно украдена с php.net и немного исправлена/подправлена.
validatePHPCode — уже потуги моего сознания.
Согласен, что стиль разный и надо бы все унифицировать.
Да, это решение выглядит намного полнее. Хотя на первый взгляд и намного более громоздкое.
С другой стороны, проверка кода идет с использованием статического анализатора, что теоретически может не полностью совпадать с поведением PHP ( к примеру анализатор без проблем анализирует неймспейсы, тогда как PHP в текущей версии может их не поддерживать).
А разве runkit под виндой не работает? Вроде подробные инструкции для сборки php_runkit.dll есть.
Работает, но нужны лишние движения.
Когда в команде удаленно работает несколько разработчиков (ну разработчики еще ладно), 2 дизайнера и у всех разные операционки, то не очень хочется всех их консультировать как заставить проект работать.
С другой стороны, конечно, это не относится к сути проблемы. Runkit делает работу лучше. Но нам на данном этапе было проще использовать вышеприведенный класс. Свои базовые задачи он решает без проблем.
Можно же легко обойти ограничения вызоыва функций через call_user_func или даже через хитрый eval.
Хотя ничего не стоит добавить эти функции в список запрещенных изначально.
Нужно об этом не забывать.
По умолчанию все функции запрещены.
eval и call_user_func могуть быть вызваны только если они явно разрешены.
Все зависит от режима: можно разрешить по умолчанию все функции и запретить только определенные, а можно запретить все и разрешить только минимальный набор. Все на ваш вкус.
еще из возникших непоняток.

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 — пользователь не сможет вызвать его, если не разрешим ему это явно.
Ага, клевая идея.
вот это пропускает:
class Pwd extends SplFileObject
{
    public function __construct()
    {
        $p = 'SplFileObject';
        $p::__construct('/etc/passwd');
    }
}

$pwd = new Pwd;
$str = $pwd->fgets();
echo $str;

Под пунктом 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');

и это как-то странно на мой взгляд.
Only those users with full accounts are able to leave comments. Log in, please.