Восхитительное зло PHP

Представьте, что мы хотим создать язык, который был бы супер-сетевым. Это означает, что язык будет поддерживать все, что делает PHP, но также и несколько дополнительных битов синтаксиса. Небольшой пример может быть:

 $numbers = [1, 2, 3, 4, 5]; print_r($numbers[2..4]); 

Как мы можем преобразовать это в действительный код PHP? Я ответил на этот точный вопрос в предыдущем посте , но суть его заключается в использовании кода, подобного следующему:

 function replace($matches) { return ' call_user_func(function($list) { $lower = '.explode('..', $matches[2])[0].'; $upper = '.explode('..', $matches[2])[1].'; return array_slice( $list, $lower, $upper - $lower ); }, $'.$matches[1].') '; } function parse($code) { $replaced = preg_replace_callback( '/\$(\S+)\[(\S+)\]/', 'replace', $code ); eval($replaced); } parse(' $numbers = [1, 2, 3, 4, 5]; print_r($numbers[2..4]); '); 

Этот код берет строку PHP-подобного синтаксиса и анализирует ее, заменяя новый синтаксис стандартным синтаксисом PHP. Как только синтаксис является стандартным PHP, код может быть оценен. По сути, он выполняет внутреннюю замену кода, что возможно только тогда, когда код может выполняться динамически.

Чтобы сделать это, без функции eval нам нужно было бы построить компилятор. То, что принимает код высокого уровня и возвращает код низкого уровня. В этом случае потребуется взять наш супер-языковой код PHP и вернуть верный код PHP.

параллелизм

Давайте посмотрим на другую основную функцию: exec . Возможно, больше осуждено, чем даже eval , exec повсеместно осуждается всеми, кроме самых авантюрных разработчиков. И мне интересно, почему.

Если вы незнакомы, exec работает так:

 exec("ls -la | wc -l", $output); print $output[0]; // number of files in the current dir 

exec — это способ для разработчиков PHP запустить команду операционной системы в новом подпроцессе текущего скрипта. Немного подтолкнув, мы можем фактически заставить этот подпроцесс работать полностью в фоновом режиме:

 exec("sleep 30 > /dev/null 2> /dev/null &"); 

Для этого: мы перенаправляем stdout и stderr в /dev/null и добавляем & в конец команды, которую мы хотим запустить в фоновом режиме. Есть много причин, по которым вы захотите сделать что-то подобное, но мое любимое — это возможность выполнять медленные и / или блокирующие задачи вне основного процесса PHP.

Изображение у вас был такой скрипт:

 foreach ($images as $image) { $source = imagecreatefromjpeg($image["src_path"]); $icon = imagecreatetruecolor(64, 64); imagecopyresampled( $source, $icon, 0, 0, 0, 0, 64, 64, $image["width"], $image["height"] ); imagejpeg($icon, $image["ico_path"]); imagedestroy($icon); imagedestroy($source); } 

Это хорошо, для нескольких изображений. Но представьте себе сотни изображений или десятки запросов в секунду. Подобный трафик может легко повлиять на производительность сервера. В подобных случаях мы можем изолировать медленный код и запускать его параллельно (или даже удаленно) с пользовательским кодом.

Вот как мы можем запустить медленный код:

 exec("php slow.php > /dev/null 2> /dev/null &"); 

Мы могли бы даже сделать шаг вперед, сгенерировав динамический скрипт для запуска интерфейса командной строки PHP. Для начала мы можем установить SuperClosure :

 require __DIR__ . '/vendor/autoload.php'; use SuperClosure\Serializer; function defer(Closure $closure) { $serializer = new Serializer(); $serialized = $serializer->serialize($closure); $autoload = __DIR__ . '/vendor/autoload.php'; $raw = ' require \'' . $autoload . '\'; use SuperClosure\Serializer; $serializer = new Serializer(); $serialized = \'' . $serialized . '\'; call_user_func( $serializer->unserialize($serialized) ); '; $encoded = base64_encode($raw); $script = 'eval(base64_decode(\'' . $encoded . '\'));'; exec('php -r "' . $script . '"', $output); return $output; } $output = defer(function() { print "hi"; }); 

Зачем нам нужно жестко кодировать скрипт (для параллельного запуска), когда мы можем просто динамически генерировать код, который хотим запустить, и направлять его прямо в двоичный файл PHP?

Мы даже можем объединить этот трюк exec с eval , кодируя исходный код, который мы хотим запустить, и декодируя его при выполнении. Это делает команду для запуска подпроцесса намного более аккуратной в целом.

Мы даже можем добавить уникальный идентификатор, чтобы подпроцесс легче отслеживать и уничтожать:

 function defer(Closure $closure, $id = null) { // create $script if (is_string($id)) { $script = '/* id:' . $id . ' */' . $script; } $shh = '> /dev/null 2> /dev/null &'; exec( 'php -r "' . $script . '" ' . $shh, $output ); return $output; } 

Оставаться в безопасности

Основная причина, по которой многие разработчики не любят и / или не советуют использовать eval и exec заключается в том, что их неправильное использование приводит к гораздо более катастрофическим последствиям, чем, скажем, count .

Я бы посоветовал вместо того, чтобы слушать этих людей и немедленно отмахиваться от eval и exec , вы узнаете, как их безопасно использовать. Главное, чего вы хотите избежать — это использовать их с нефильтрованным пользовательским вводом.

Избегайте любой ценой:

 exec($_GET["op"] . " " . $_GET["path"]); 

Попробуйте вместо этого:

 $op = $_GET["op"]; $path = $_GET["path"]; if (allowed_op($op) and allowed_path($path)) { $clean = escapeshellarg($path); if ($op === "touch") { exec("touch {$clean}"); } if ($op === "remove") { exec("rm {$clean}"); } } 

… Или еще лучше: избегайте помещения любых пользовательских данных непосредственно в команду exec ! Вы также можете попробовать другие экранирующие функции, такие как escapeshellcmd . Помните, что это ворота в вашу систему. Все, что пользователь, выполняющий процесс PHP, может делать, exec разрешено делать. Вот почему он намеренно отключен на виртуальном хостинге.

Как и во всех основных функциях PHP, используйте их в качестве модераторов. Обратите особое внимание на данные, которые вы разрешаете, и избегайте нефильтрованных пользовательских данных в exec . Но не избегайте функций, не понимая, почему вы избегаете их. Это не полезно для вас или людей, которые будут учиться у вас.