Ars Longa, Vita Brevis » PHP

Обход плагина WP Hashcash

Vladimir — Mon, 26 Dec 2011 05:43:11 +0000

Не так страшен JavaScript, как его малюют…

WP Hashcash — очередной плагин WordPress для борьбы со спамом. Принцип работы основывается на том, что спам-боты не умеют исполнять JavaScript. Идея в том, что если пользователь открыл сайт из браузера, браузер выполнит некоторый хитрый код JavaScript, и реузльтат работы этого скрипта будет передан назад на сервер в качестве доказательства «человечности» комментатора.

Недостаток этого подхода заключается в том, что используемый JavaScript является довольно-таки простым; как следствие, его можно «понять» даже из PHP-скрипта.

Пример кода JavaScript, генерируемого плагином:

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

Итак:

В PHP нет ключевого слова var (строго говоря, оно там есть, только имеет другое назначение).
В PHP несколько другой синтаксис объявления массива
Идентификаторы в PHP начинаются с доллара
Операция сдвига выглядит как >>, а не >>>.
В PHP нет классов Array, String, но никто не мешает их написать

Наша задача состоит в преобразовании кода, приведённого выше, в нечто подобное:

Это достигается таким набором правил str_replace():

$x = array(
'wphc_data' => '$wphc_data',
'var $' => '$',
'var ' => '$',
'];' => ');',
'= [' => '= array(',
'new Array($wphc_data.length)' => 'array()',
'$wphc_data.length' => 'count($wphc_data)',
' i<' => ' $i<',
'[i]' => '[$i]',
'i++' => '$i++',
'>>>' => '>>',
'a[$i] =' => '$a[$i] =',
'String.' => '',
'eval' => '',
"a.join('')" => 'join("", $a)',
);

$s = str_replace(
array_keys($x),
array_values($x),
$s
);

При желании правила можно попытаться оптимизировать, но мне было лень — скрипт ломался на коленке за 10 минут.

Реализация функции fromCharCode:

function fromCharCode($a, $b, $c, $d)
{
return chr($a) . chr($b) . chr($c) . chr($d);
}

После замены результат нужно вычислить при помощи eval(). После чего получим такой результат:

function wphc_compute(){return 43448 * 43448 + 75878; } wphc_compute();

Как можно заметить, этот код является одновременно и PHP-кодом, и JavaScript-кодом.

Следующий шаг —

$s = str_replace('wphc_compute();', '', $s);
eval($s);
echo wphc_compute(), "\n";

Результатом выполнения будет число 1887804582.

Как видим, для обхода такой простой защиты не нужен даже интерпретатор JavaScript

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

SQLMon для Yii

Vladimir — Tue, 22 Nov 2011 15:02:18 +0000

Расширение для анализа производительности SQL-запросов для Yii

Одной из вещей, которых мне очень не хватало при разработке сайтов на Yii — нормального отображения всех запросов к базе данных, что дало бы возможность их последующего анализа.

Ситуацию частично исправило расширение под названием Yii DB profiler. Но остались некоторые неудобства:

Отображение запросов в порядке убывания времени выполнения — в принципе, это дело вкуса: при таком порядке сразу видны проблемные запросы. С другой стороны, лично мне более привычен хронологический порядок — так чётче прослеживается логика работы;
Prepared statements. Это просто здорово, но если повторять запрос в phpMyAdmin (например, если интересует план выполнения запроса), бывает очень муторно заменять все связанные значения. Например, для запросов вида

SELECT 't'."object_id" AS "t0_c0", 't'."ymd" AS "t0_c1", 't'."black" AS "t0_c2", 't'."brown" AS "t0_c3", 't'."yellow" AS "t0_c4",
't'."neutral" AS "t0_c5", 't'."white" AS "t0_c6", 't'."unknown" AS "t0_c7", 't'."error" AS "t0_c8", 'object'."object" AS "t1_c2",
'object'."id" AS "t1_c0"
FROM 'dnsbl_summary' 't'
LEFT OUTER JOIN 'objects' 'object' ON ('t'."object_id"='object'."id")
WHERE (((black > 0) OR (brown > 0)) AND
(((((((((ymd=:ycp0) AND (black>:ycp1)) AND (brown=:ycp2)) AND (yellow=:ycp3)) AND
(neutral>:ycp4)) AND (white>:ycp5)) AND (unknown=:ycp6)) AND (black>:ycp7)) AND
(error=:ycp8))) AND (object.enabled = 1)
LIMIT 50

заменять все :ycpXXX на их значения немного муторно. В общем случае здесь вряд ли можно что-то сделать — заполнители параметров могут быть любыми (и даже позиционными), поэтому тупое использование str_replace может наделать делов.

Лично мне список запросов нужен обычно только для двух вещей:

Оценка работы механизмов кэширования;
Оценка плана выполнения запроса, составленная оптимизатором.

Первое обычно не критично (зачастую достаточно посмотреть на количество запросов), а вот второе позволяет выявить многие будущие проблемы с производительностью заранее.

В результате, взяв за основу плагин Александра, я портировал SQLMon на Yii.

В результате получилось расширение, позволяющее получать планы выполнения запросов в реальном времени.

Поддерживаются MySQL и SQLite, в планах поддержка PgSQL (там не всё просто, ибо Postgres выполняет запрос, что может привести к интересным последствиям при использовании INSERT/UPDATE/DELETE; как следствие, придётся использовать вложенные транзакции).

Вывод результатов осуществляется либо при помощи виджета:

$this->widget(
'ext.sqlmon.components.SQLMon'
array(
'explain' => true, // Показывать план выполнения запроса
'backtrace' => true, // Показывать трассу вызовов
'dsn' => true, // Показывать DSN соединения (может быть полезно при использовании нескольких БД)
'cssFile' => null, // Эстеты могут задать свой файл стилей
)
);

Либо при помощи Log Route:

return array(
'components' => array(
'log' => array(
'routes' => array(
array(
'class' => 'ext.sqlmon.components.SQLMonLogRoute',
'showExplain' => true, // Показывать план выполнения
'showDsn' => true, // Показывать DSN соединения
'showBacktrace' => true, // Показывать трассу вызовов
),
array(
'class' => 'ext.sqlmon.components.SQLMonFileLogRoute',
'logFile' => 'sqlmon.log',
'showExplain' => true, // Показывать план выполнения
'showDsn' => true, // Показывать DSN соединения
'showBacktrace' => true, // Показывать трассу вызовов
),
),
)
),
);

SQLMonLogRoute наследуется от CWebLogRoute, но, как и CProfileLogRoute, отказывается выдавать данные для AJAX-запросов.

SQLMonFileLogRoute наследуется от CFileLogRoute и, как следствие, воспринимает все параметры конфигурации последнего.

Для того, чтобы протоколирование нормально работало, сообщения от SQLMon попадают в общий протокол и, как следствие, видны при использовании CWebLogRoute (в этом случае выдаётся минимум информации).

Результаты работы выглядят примерно так (пример приведён для SQLite):

Реализовано всё через собственный класс PDO, поэтому для использования SQLMon нужно в файл конфигурации добавить такие строки:

return array(
'import' => array(
'ext.sqlmon.components.*',
),

'components' => array(
'db' => array(
// ...
'pdoClass' => 'SQLMonPDO',
),
),
);

Реализация просмотра выполнения плана выполнения запроса осуществляется при помощи класса-наследника от PDOStatement и переопределения метода PDO::prepare().

Планы на будущее:

поддержка PostgreSQL;
возможность расширения классов SQLMonPDO и SQLMonPDOStatement (возможно, придётся позаимствовать некоторые идеи из Kohana);
наследование SQLMon_Explainer_Base от CComponent, что даст дополнительные плюшки для расширяемости;
более красивая реализация функции SQLMon::arr2pre(), что позволит рисовать красивые ASCII-таблички;
возможная поддержка FireBug;
протоколирование в HTML-файл;
информация профайлера MySQL (нужность пока под большим вопросом);
рефакторинг, написание документации

SQLMon 0.1 for Yii — скачать бесплатно без регистрации без смс

Преобразование ошибок в PHP в исключения

Vladimir — Wed, 17 Aug 2011 21:13:06 +0000

Механизм трансляции ошибок в исключения с целью последующей обработки

Навеяно этим сообщением на форуме.

Дано:

фреймворк перехватывает все возникающие ошибки (которые разрешены текущим значением error_reporting()) и аварийно завершает работу скрипта (в целях отладки/безопасности/нужное подчеркнуть);
имеется код, вызывающий PHP-функцию, которая может сгенерировать предупреждение (в оригинальном сообщении это mkdir() — кидает E_WARNING, если не удаётся создать каталог)
местные стандарты кодирования запрещают использование оператора @ (довольно распространённая практика).

Требуется обработать возникшую ошибку без авоста скрипта.

Сначала рассмотрим предложенные варианты решений и наведём критику (как же без этого).

Способ 1:

В PHP существуют специальные функции (is_dir, is_writable, …), в зависимости от возвращаемого значения которых вы можете генерировать соответствующее сообщение.

Идея в том, чтобы проверять все возможные ошибочные ситуации до вызова проблемной функции. С одной стороны по-хорошему так и надо поступать. С другой стороны, всего не предусмотришь — а если создавать обёртку для каждой проблемной функции, код может очень сильно раздуться. К тому же следует помнить, что проверка на возможные ошибки с последующим вызовом функции — операция неатомарная. Иными словами, требуемый каталог может быть создан другим скриптом в следующее мгновение после того, как проверка на существование создаваемого каталога вернула отрицательный результат. Для каталогов это, возможно, не очень актуально, но для операция с сокетами — самое то.

Способ 2: изменение error_reporting.

Что-то типа:

$level=error_reporting();
error_reporting($level | ~E_WARNING | ~E_ERROR);

if(!is_dir($path) && false===mkdir($path))
throw new CException(Yii::t('myapp','Can not create path "{path}"',array('{path}'=>$path)));

error_reporing($level);

Убирать E_ERROR всё же не стоит.
Опять же, создание обёртки для каждой проблемной функции раздует код. К тому же вызов error_reporting() — не самая быстрая операция (по крайней мере раньше было именно так).

Способ 3:

Мы в текущем проекте столкнулись с приблизительно такой же проблемой: Memcache генерит PHP-ошибки, а не исключения, которые хотя бы через try/catch можно было отловить.
Пришлось изобретать свой хэндлер и «оборачивать» все обращения к мемкешу предвалительно нашим «молчаливым» хэндлером:

function mcSilenceErrorHandler($errno, $errstr, $errfile, $errline)
{
QLogger::log('memcache_errors', $errstr . ' at (' . $errfile . ':' . $errline . ')');
return true;
}

В самом коде используется так, что перед потенциально «опасными» обращениями к мемкешу, мы выставляем свой «молчаливый» хэндлер, а потом возвращаем старый – Yii’шный – хэндлер.

public function flush()
{
$result = false;

$old_handler = set_error_handler('mcSilenceErrorHandler');
$result = $this->_cache->flush();
set_error_handler($old_handler);

return $result;
}

Решение à la Способ №2, обладающее практически теми же недостатками.

Ну а теперь собственно предлагаемое решение.

Как известно, PHP позволяет пользователю установить собственные обработчики для обработки ошибок и необработанных исключительных ситуаций. Решение же состоит в том, чтобы из обработчика ошибок кинуть исключение. Исключение либо будет перехвачено в блоке try/catch где-то в коде, либо не будет обработано пользовательским кодом и будет перехвачено в обработчике необработанных исключений (что приведёт к аварийному завершению скрипта).

Код будет выглядеть примерно так:

После такого можно писать:

try {
mkdir($dir);
}
catch (ErrorException $e) {
echo 'Всё плохо при создании каталога: ', $e;
}

Так как тема взята с форума Yii, рассмотрим, как интегрировать всё это безобразие с Yii:

class MyWebApplication extends CWebApplication
{
public function __construct($config=null)
{
parent::__construct($config);
register_shutdown_function(array($this, 'shutdown'));
if (YII_ENABLE_EXCEPTION_HANDLER && !YII_ENABLE_ERROR_HANDLER) {
set_error_handler(array($this, 'myErrorHandler'));
}
}

public function shutdown()
{
if (YII_ENABLE_EXCEPTION_HANDLER && ($error = error_get_last()) && in_array($error['type'], array(E_PARSE, E_ERROR, E_USER_ERROR))) {
$this->handleException(new ErrorException($error['message'], $error['type'], 0, $error['file'], $error['line']));
die();
}
}

public function myErrorHandler($code, $error, $file = null, $line = null)
{
if (error_reporting() & $code) {
throw new ErrorException($error, $code, 0, $file, $line);
}

return true;
}
}

Использование:

define('YII_ENABLE_ERROR_HANDLER', false);
define('YII_ENABLE_EXCEPTION_HANDLER', true);

require_once 'protected/components/MyWebApplication.php';
Yii::createApplication('MyWebApplication', $config)->run();

Перехват фатальных ошибок в Yii

Vladimir — Sun, 07 Aug 2011 08:06:17 +0000

Облегчаем жизнь разработчику

Как и Kohana, Yii помогает разработчику, отлавливая неперехваченные исключения и ошибки в коде. Как и в Kohana, реализуется это одинаково — через функции PHP set_exception_handler() и set_error_handler(). Но, в отличие от Kohana, Yii не умеет перехватывать фатальные ошибки (E_ERROR в терминах PHP).

Как следствие, если приложение сгенерирует фатальную ошибку (например, вызов несуществующей функции), у разработчика все шансы об этом не узнать (например, на production-сервере с display_errors установленным Off). Конечно, если приложение хорошо протестировано шансы возникновения такой ситуации близки к нулю, но если приложение позволяет пользователю устанавливать какие-либо свои дополнения, то лучше узнавать о проблемах прежде, чем начальник получит кучу гневных писем

Причина, по которой Yii не может обработать фатальные ошибки заключается в том, что PHP принципиально не вызывает функции, установленные set_error_handler(), при возникновении ошибок типа E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING.

Тем не менее, Kohana умеет перехватывать E_ERROR, поэтому было бы неплохо добавить такую поддержку и в Yii.

Вся магия заключается в том, что функции, зарегистрированные при помощи register_shutdown_function() вызываются даже в случае E_ERROR. А определить наличие ошибки можно при помощи функции error_get_last().

У меня получился такой код:

class MyWebApplication extends CWebApplication
{
public function __construct($config=null)
{
parent::__construct($config);
register_shutdown_function(array($this, 'shutdown'));
}

public function shutdown()
{
if (YII_ENABLE_ERROR_HANDLER && ($error = error_get_last())) {
$this->handleError($error['type'], $error['message'], $error['file'], $error['line']);
die();
}
}
}

Пользоваться так:

require_once 'protected/components/MyWebApplication.php';
Yii::createApplication('MyWebApplication', $config)->run();

Вложенные транзакции в PDO

Vladimir — Sat, 06 Aug 2011 07:21:34 +0000

Использование вложенных транзакций в MySQL и PostgreSQL с PDO

В PDO есть такая особенность: отсутствие поддержки вложенных транзакций.

Вложенные транзакции бывают весьма полезны: например, у нас есть два сервиса, которые могут взаимодействовать между собой. Сервис А начинает транзакцию, что-то делает, затем вызывает сервис Б, затем подтверждает транзакцию.

Может так случиться, что сервисы А и Б разрабатываются разными людьми и разработчик сервиса Б может не знать, что сервис А уже начал выполнение транзакции. Как следствие, при использовании PDO как только сервис Б попытается начать транзакцию, PDO выбросит исключение, предупреждающее о наличии активной транзакции.

Тем не менее, такие СУБД как MySQL и PostgreSQL поддерживают вложенные транзакции (о чём PDO не знает). Поэтому было бы неплохо добавить поддержку вложенных транзакций для данных СУБД в PDO.

Ниже приведена очень простая реализация поддержки вложенных транзакций в PDO:

class MyPDO extends PDO
{
protected static $_supported_drivers = array(
'mysql' => true,
'pgsql' => true,
);

protected $_nest_level = 0;

protected function nestedTransactionsSupported()
{
return !empty(self::$_supported_drivers[$this->getAttribute(PDO::ATTR_DRIVER_NAME)]);
}

public function beginTransaction()
{
if (!$this->_nest_level || !$this->nestedTransactionsSupported()) {
parent::beginTransaction();
}
else {
$this->exec("SAVEPOINT LEVEL{$this->_nest_level}");
}

++$this->_nest_level;
}

public function commit()
{
--$this->_nest_level;

if (!$this->_nest_level || !$this->nestedTransactionsSupported()) {
parent::commit();
}
else {
$this->exec("RELEASE SAVEPOINT LEVEL{$this->_nest_level}");
}
}

public function rollBack()
{
--$this->_nest_level;

if (!$this->_nest_level || !$this->nestedTransactionsSupported()) {
parent::rollBack();
}
else {
$this->exec("ROLLBACK TO SAVEPOINT LEVEL{$this->_nest_level}");
}
}
}

Подводные камни: в MySQL есть такое понятие как неявное подтверждение транзакции (implicit commit). На практике это ломает уровень вложенности транзакций, поддерживаемый данной реализацией. С другой стороны, в web-приложениях редко возникает необходимость использования транзакций (тем более вложенных) там, где присутствуют операторы, вызывающие неявное подтверждение транзакции.

Ставим спам в комментариях на службу людям

Vladimir — Sat, 06 Aug 2011 04:48:20 +0000

Автоматическое отправление автоматического спама на Stop Forum Spam

Я давно получаю по несколько тысяч спам-комментариев в день (не то, что мне он мешает — система его отсеивает полностью автоматически) и, как следствие, давно думаю о том, как заставить этот спам служить людям.

Начиналось всё созданием чёрных списков типа DNSBL (сюда попадали IP-адреса спамеров) и URIBL (а сюда — рекламируемые домены), но на раскрутку очередного чёрного списка (а также на его поддержание) банально не было ни сил, ни времени.

Закончилось всё тем, что я прекратил заниматься велосипедостроительством, зарегистрировался на Stop Forum Spam и теперь отсылаю весь полученный спам туда. Хотя я не во всём согласен с SFS, положительным моментом является то, что списки спамеров мониторятся Spamhaus (пример 1, пример 2). Хотя Spamhaus о себе тоже много думает (блокировать почту на основании того, что с данного IP-адреса идёт форумный спам — бред), тем не менее, у Spamhaus больше шансов прикрыть спамера, чем у простого блоггера.

На этом лирическое отступление закончено, далее идёт рассказ о том, как автоматически сообщать об автоматическом спаме в Stop Forum Spam, ибо чем больше отчетов они получат, тем быстрее спамер будет остановлен.

Идея, на которой строится реализация метода, абсолютно не нова, но эффективна.

Шаг первый. Регистрация на SFS и получение API-ключа.

Шаг второй. Создаём в каталоге с файлами WordPress такой простенький файл (например, wp-comments-post2.php):

require_once dirname(__FILE__) . 'wp-comments-post2.php';

Шаг третий. Добавляем в comments.php используемой темы липовую форму комментариев. Например, такую:

<div style="display: none; left: -10000px; top: -10000px;">
<p><strong>Пожалуйста, не используйте данную форму комментирования — она исключительно для спамеров.</strong></p>
<form method="post" action="/wp-comments-post.php">
<p class="comment-form-author"><label>Имя</label> <input type="text" size="30" value="" name="author"/></p>
<p class="comment-form-email"><label>E-mail</label> <input type="text" size="30" value="" name="email"/></p>
<p class="comment-form-url"><label>Сайт</label><input type="text" size="30" value="" name="url"/></p>
<p class="comment-form-comment"><label>Комментарий</label><textarea rows="8" cols="45" name="comment"></textarea></p>
<p class="form-submit">
<input type="submit" value="Отправить комментарий" id="submit" name="submit"/>
<input type="hidden" id="comment_post_ID" value="" name="comment_post_ID"/>
<input type="hidden" value="0" id="comment_parent" name="comment_parent"/>
</p>
</form>
</div>

Шаг четвёртый. Меняем нормальную форму комментирования. Всё, что требуется — изменить action формы комментирования с /wp-comments-post.php на /wp-comments-post2.php.

Если для создания формы комментирования используется новомодная функция comment_form() изменить action можно так:

ob_start();
comment_form();
$s = ob_get_clean();
$s = str_replace('/wp-comments-post.php', '/wp-comments-post2.php', $s);
echo $s;
?>

Шаг пятый. Добавляем кусок кода в файл functions.php используемой темы:

Вместо API-ключ Stop Forum Spam подставляем свой API-ключ.

Вместо возни с cURL можно использовать API-функцию WordPress wp_remote_post().

Шаг шестой. Радуемся жизни

php: symbol zlibVersion, version libmysqlclient_16 not defined in in file libmysqlclient.so.16 with link time reference

Vladimir — Mon, 30 May 2011 16:13:54 +0000

Быстрое исправление 'relocation error'

Не везёт мне с PHP на CentOS…

Ситуация: имеется сервер на CentOS с установленной CPanel. PHP в случайные моменты времени завершается с ошибкой вида

php: relocation error: php: symbol zlibVersion, version libmysqlclient_16 not defined in in file libmysqlclient.so.16 with link time reference

Вместо zlibVersion может быть другое имя, например crc32.

Из-за CPanel/WHM возможности ограничены опциями, предоставляемыми EasyApache — обновить MySQL/PHP штатными средствами (например, через yum) не представляется возможным из-за риска сломать CPanel.

Текст ошибки явно указывает на проблему с версией библиотеки, поэтому в первую очередь нужно выянить, где на сервере находится libmysqlclient. В моём случае это /usr/lib64 и /usr/lib64/mysql.

Затем смотрим, какую из библиотек использует php:

$ ldd `which php` | grep libmysqlclient
libmysqlclient.so.16 => /usr/lib64/mysql/libmysqlclient.so.16 (0x00000034c6000000)
$ ls -la `/usr/lib64/mysql/libmysqlclient.so.16`
lrwxrwxrwx 1 root root 27 May 29 00:08 /usr/lib64/mysql/libmysqlclient.so.16 -> libmysqlclient.so.16.0.0*

Но libmysqlclient.so.16.0.0 существует и в /usr/lib64, и в /usr/lib64/mysql, поэтому посмотрим, где нужный символ есть:

$ nm /usr/lib64/mysql/mysql/libmysqlclient.so.16.0.0 | grep zlibVersion
nm: libmysqlclient.so.16.0.0: no symbols
$ nm /usr/lib64/mysql/libmysqlclient.so.16.0.0 | grep zlibVersion
00000034c60d64b0 T zlibVersion

Меняем символьную ссылку на нужный файл:

rm -f /usr/lib64/mysql/libmysqlclient.so.16
cd /usr/lib64/mysql
ln -s ../libmysqlclient.so.16.0.0 libmysqlclient.so.16

После чего ошибка исчезает.

KSES в WordPress: можно ли проще?

Vladimir — Thu, 10 Feb 2011 06:07:09 +0000

Регулярные выражения против DOM XML

Вчера мне довелось разбираться с тем, как работает KSES в WordPress.

KSES (рекурсивный акроним от KSES Strips Evil Scripts) — подсистема в WordPress (изначально написанная Ulf Harnhammar), предназначенная для проверки и очистки текста, введённого пользователем: она позволяет задать список допустимых тэгов, стилей и протоколов и на основе этих параметров убрать из текста пользователя всё, что им не соответствует.

KSES является довольно стабильной подсистемой; что немаловажно, KSES работает. Работает — не трогай, а то сломаешь…

Лично мне в KSES не нравится использование регулярных выражений. Одна из причин — теория разработки компиляторов. Известно, что HTML — это грамматика второго типа в иерархии Хомского (контекстно-свободная грамматика), а регулярные выражения — грамматика третьего типа (регулярная грамматика). Грамматика второго типа является более сложной, нежели грамматика третьего типа. Как следствие, описать более простой грамматикой то, что соответствует более сложной, очень трудно (вряд ли возможно на 100%, но это моё мнение).

Что плохо, среди тестов WordPress я не нашёл тестов для KSES. Что может означать, что, вероятно, никто из разработчиков не строил и не проверял граф путей в KSES; как следствие, не гарантии, что при граничных условиях всё будет работать нормально.

Другая причина, по которой я не люблю регулярные выражения — это скорость: особой производительностью они не отличаются. Хотя с другой стороны, объёмы проверяемого текста не так велики, чтобы KSES оказывал существенное влияние на производительность.

Каковы альтернативы? Обзор.

На мой взгляд, самая удобная альтернатива — использование DOM XML и работа с полученным деревом. Тем более, что в PHP есть соответствующая поддержка. А парсер на C в любом случае быстрее парсера на PHP.

Парсер DOM XML в PHP позволяет работать даже с некорректным HTML. Что означает, что он берёт на себя решение проблемы с неправильно закрытыми или незакрытыми тэгами. Парсер понимает HTML entities и преобразует их в нормальный текст. Что означает, что не нужно возиться с разными форматами записи entities и переводить их к одному виду (чему в KSES уделено не мало кода). И так далее.

Для проверки некоторых идей я написал небольшой класс, который делает почти то же самое, что и KSES, только иначе Я ни в коем случае не рассматриваю его как замену KSES.

class Xex
{
private $protocols = array();
private $tags = array();
private $css = array();

private $strip_comments = true;
private $strip_script_text = true;
private $strip_style_text = true;

private $script_text = true;
private $style_text = true;

private $trim_text = false;

public function __construct(array $tags = null, array $protocols = null, array $css = null)
{
if (null !== $tags) $this->tags = $tags;
if (null !== $protocols) $this->protocols = array_combine($protocols, $protocols);
if (null !== $css) $this->css = array_combine($css, $css);
}

protected function checkProtocols($str)
{
$s = str_replace(array("\r", "\n", "\t", ""), '', $str);
$s = explode(':', $s, 2);

// See http://tools.ietf.org/html/rfc3986#section-3.1
if (preg_match('/^[a-z][a-z0-9+.-]*$/', $s[0]) && !isset($this->protocols[$s[0]])) {
return '';
}

return $str;
}

protected function sanitizeCss($css)
{
$css = str_replace(array("\n","\r","\t"), '', $css);

if (preg_match('![\\(&=}]|/\\*!', $css)) {
return '';
}

$arr = explode(';', trim($css));

$css = '';
foreach ($arr as $x) {
$x = trim($x);
if ($x) {
$found = false;
if (false === strpos($x, ':')) {
$found = true;
}
else {
$parts = explode(':', $x, 2);
if (isset($this->css[rtrim($parts[0])])) {
$found = true;
}
}

if ($found) {
$css .= $x . ';';
}
}
}

return $css;
}

protected function parseDOM(DOMNode $el, DOMNode $new)
{
switch ($el->nodeType) {
case XML_ELEMENT_NODE:
$prefix = $el->prefix ? ($el->prefix . ':') : '';
$tag = $prefix . $el->tagName;

if (isset($this->tags[$tag])) {
$n = $new->appendChild($el->cloneNode(false));
if ($el->hasAttributes()) {
$attrs = $this->tags[$tag];
foreach ($el->attributes as $a) {
if (!isset($attrs[$a->name])) {
$n->removeAttribute($a->name);
}
elseif ('style' == $a->name) {
$css = $this->sanitizeCss($a->value);
if ($css != $a->value) {
$n->setAttribute($a->name, $css);
}
}
elseif (in_array($a->name, array('xmlns', 'profile', 'href', 'src', 'cite', 'classid', 'codebase', 'data', 'usemap', 'longdesc', 'action'))) {
$s = $this->checkProtocols($a->value);
if ($s != $a->value) {
$n->setAttribute($a->name, $s);
}
}
}
}
}
else {
if ($tag == 'script' && $this->strip_script_text || $tag == 'style' && $this->strip_style_text) {
return;
}

$n = $new;
}

if ($el->hasChildNodes()) {
foreach ($el->childNodes as $e) {
$this->parseDOM($e, $n);
}
}

return;

case XML_TEXT_NODE:
if (!$this->trim_text) {
$new->appendChild($el->cloneNode(true));
}
else {
$new->appendChild(new DOMText(trim($el->wholeText)));
}

return;

case XML_CDATA_SECTION_NODE:
$new->appendChild($el->cloneNode(true));
return;

case XML_COMMENT_NODE:
$parent = $el->parentNode;
if ($parent && $parent->tagName) {
$prefix = $parent->prefix ? ($parent->prefix . ':') : '';
$tag = $prefix . $parent->tagName;

if ('style' == $tag && $this->style_text || 'script' == $tag && $this->script_text) {
$new->appendChild(new DOMText($el->data));
return;
}
}

if (!$this->strip_comments) {
$new->appendChild($el->cloneNode(true));
}

return;

default:
break;
}
}

public function sanitize($s)
{
$dom = new DOMDocument();
$dom->recover = true;
$dom->strictErrorChecking = false;
$dom->substituteEntities = true;
$dom->resolveExternals = false;
$dom->formatOutput = false;

$old = libxml_use_internal_errors(true);

$s = str_replace(chr(0), '', $s);
$s = preg_replace('!<([^a-z\\?\\!/])!i', '<$1', $s);
$s = preg_replace('!<((?:[\\?\\!/]\\s*)?[a-z][^>]*)(?=<)!i', '<$1', $s);
@$dom->loadHTML($s);
libxml_use_internal_errors($old);

$new = $dom->createDocumentFragment();
$new->appendChild(new DOMElement('wrap'));
$this->parseDOM($dom->documentElement, $new->firstChild);
$dom->replaceChild($new, $dom->documentElement);
$s = $dom->saveXML($dom->documentElement, LIBXML_NOEMPTYTAG);

return substr($s, strpos($s, '') + 6, -7);
}
}
?>

Менее 200 строк против почти полутора тысяч.

На 45-килобайтном документе DOM быстрее KSES от 5 до 9 раз.
На 90-килобайтном документе DOM быстрее KSES от 6 до 9 раз.
На 180-килобайтном документе DOM быстрее KSES от 9 до 10 раз.

Производительность зависит от количества тэгов и стилей (разбор стилей реализован практически одинаково). Например, на домашней странице Google XEX может опережать KSES в 25 раз; если же соединить домашнюю страницу Google саму с собой 4 раза, разница во времени сокращается.

На домашней странице WordPress разница в 7 раз.

На этой странице разница в 4 раза.

Всё-таки KSES очень медленный…

Автоматическая проверка репутации IP-адреса

Vladimir — Thu, 03 Feb 2011 02:51:44 +0000

На примере SendMail, Reputation Authority, SenderBase и SenderScore

Репутация IP-адреса — одна из очень важных составляющих, используемых для борьбы с почтовым спамом.

Письма приходят с IP-адресов, а репутация этих адресов может сказать, является ли данный адрес ответственным за рассылку спама или нет. По некоторым данным проверка репутации IP-адресов позволяет остановить порядка 80% спама.

Как следствие, компании, занимающиеся массовой рассылкой электронных писем, должны заботиться о поддержании хорошей репутации адресов своих почтовых серверов.

Очень часто для отправки писем используется множество адресов — в частности из-за того, что крупные почтовые сервисы (GMail, Yahoo!, Hotmail, AOL, ….) имеют различные ограничения на количество сообщений, принимаемых с одного адреса, а также на скорость отправки почтовых сообщений. Например, компания, которую мы консультируем, рассылает более 100,000,000 писем в месяц, для чего используется не один десяток IP-адресов.

Естественно, что ручная проверка сотен адресов в десятке различных сервисов — занятие неблагодарное и утомительное. Но, к счастью, всё автоматизируется, что будет рассмотрено на примере PHP.

Очень часто для извлечения данных из web-страницы (data scraping) используются регулярные выражения. Но это вчерашний день К тому же не всегда просто составить эффективное регулярное выражение, которое сразу выберет все необходимые данные — с большой вероятностью могут потребоваться несколько выражений и доводка результата напильником.

Простая и достойная альтернатива регулярным выражениям — XPath. Тем более, что построить нужный XPath можно при помощи FireBug (он позволяет скопировать адрес выделенного элемента как XPath).

Рассмотрим на примере SenderScore. Репутация проверяется по ссылке вида https://senderscore.org/lookup.php?lookup=1.1.1.1, где вместо 1.1.1.1 задаётся IP-адрес.

Как видно на скриншоте, FireBug показывает XPath требуемого элемента. Но при знании XPath можно использовать и более простое выражение.

Как это выглядит на PHP:

$oldSetting = libxml_use_internal_errors(true);
libxml_clear_errors();
$html = new DOMDocument();
$html->loadHtmlFile('https://senderscore.org/lookup.php?lookup=1.1.1.1');

$xpath = new DOMXPath($html);
echo 'Sender Score: ', $xpath->query('//div[@id="senderscore_number"]')->item(0)->nodeValue, "\n";

libxml_clear_errors();
libxml_use_internal_errors($oldSetting);
?>

XPath для других сервисов

Reputation Authority

http://reputationauthority.org/lookup.php?ip=1.1.1.1

Поиск ведётся относительно вершины //div[@class="LookupIP-content"]/table[2]/tr[4]/td

Reputation Score: .//table/tr[2]/td[2]
Clean emails: .//table[2]/tr[2]/td[2]
Viruses: .//table[2]/tr[3]/td[2]
Spam: .//table[2]/tr[4]/td[2]
Malformed Emails: .//table[2]/tr[5]/td[2]
Suspicious Emails: .//table[2]/tr[6]/td[2]
Good Users: .//table[2]/tr[8]/td[2]
Bad Users: .//table[2]/tr[9]/td[2]

SenderBase

http://www.senderbase.org/senderbase_queries/rep_lookup?search_name=1.1.1.1&action%3ASearch=Search

При запросе страницы User-Agent должен быть похожим на нормальный браузер.

Email Reputation //div[@id="tab1body"]//span[1]/text()
Web Reptation //div[@id="tab2body"]//span[1]/text()

SendMail

http://sendmail.com/sm/resources/tools/ip_reputation/ip_reputation_results/index.shtml?IP=1.1.1.1&search.x=1&search.y=1&search=Submit

При запросе страницы Referer должен указывать на http://sendmail.com/sm/resources/tools/ip_reputation/.

Поиск ведётся относительно вершины //dev[@id="content"]/table[@class="ip_reputation"]

IP Reputation Class: .//tr[4]/td[2]/text()
Volume (может отсутствовать) .//tr[5]/td[2]
Weighted Risk .//tr[6]/td[2] (если Volume отсутствует, то .//tr[5]/td[2])
Spam Ratio (может отсутствовать) .//tr[7]/td[2]
Valid Bulk Ratio (может отсутствовать) .//tr[8]/td[2]

Либо можно использовать проверку текста:

Volume .//tr/td[1][normalize-space()="Volume"]/following-sibling::td[1]
Weighted Risk .//tr/td[1][normalize-space()="Weighted Risk"]/following-sibling::td[1]
Spam Ratio .//tr/td[1][normalize-space()="Spam Ratio"]/following-sibling::td[1]
Valid Bulk Ratio .//tr/td[1][normalize-space()="Valid Bulk Ratio"]/following-sibling::td[1]

WordPress: кэширование средствами nginx

Vladimir — Fri, 10 Dec 2010 12:08:15 +0000

Уменьшение потребления ресурсов во много раз

Много было сказано про кэширование в WordPress… Сегодня я хочу рассказать о действительно эффективном методе, позволяющем сильно снизить нагрузку.

Метод основан на использовании кэша FastCGI web-сервера nginx.

Идея состоит в генерации статических страниц и отдачи их пользователям, не имеющим cookie комментатора. Зарегистрированным пользователям, а также комментаторам всегда отдаётся свежая страница. Так как читателей, ни разу не оставлявших комментарий, как правило, гораздо больше, чем комментаторов, то подобный использование кэша позволяет значительно снизить нагрузку на WordPress/PHP. Знакомые с принципом работы WP Super Cache заметят, что WPSC использует тот же принцип работы.

В чем же преимущество перекладывания работы на Web-сервер (nginx)?

PHP — интерпретируемый язык. Как следствие, аналогичный код на компилируемом языке будет во много раз быстрее.
WordPress во многом bloatware От момента начала загрузки страницы до окончания выполнения стадии init выполняется очень много «лишнего» кода.
В зависимости от нагрузки на сервер от запроса страницы до выполнения PHP-кода может пройти некоторое время: всё зависит от загруженности PHP (если все дочерние процессы PHP заняты обработкой запроса, новому запросу придётся ждать освобождения одного из процессов. Если за приемлемое время ни один процесс не освободился, пользователь видит сообщение о печально знаменитой ошибке 504).
Когда обслуживанием кэша занимается web-сервер, шансы на возникновение подобной ситуации

Теперь переходим от теории к практике.

fastcgi_cache_path /var/lib/nginx/myblog levels=2 keys_zone=myblog:10m max_size=512m inactive=20m;
server {
server_name example.com;
root /path/to/blog;
index index.php;
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
set $do_not_cache 1;
}
fastcgi_cache_bypass $do_not_cache;
fastcgi_no_cache $do_not_cache;
fastcgi_pass_header Cookie;
fastcgi_cache myblog;
fastcgi_cache_key $request_method|$host|$request_uri;
fastcgi_cache_valid 301 8h;
fastcgi_cache_valid 404 1h;
fastcgi_cache_valid 200 15m;
if ($http_user_agent !~ FeedBurner) {
# Здесь идут перенаправления для FeedBurner
}
error_page 404 = @wordpress;
log_not_found off;
location ^~ /files/ {
rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
}
location ~ ^/(wp-admin/.*\.php|wp-login\.php|wp-register\.php|(feed|comment/feed)(/.*)?)$ {
try_files $uri @wordpress;
set $do_not_cache 1;
fastcgi_cache_bypass 1;
fastcgi_no_cache 1;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_index index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location @wordpress {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME /index.php;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_index index.php;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
try_files $uri @wordpress;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ^~ /blogs.dir/ {
internal;
root /path/to/blog/wp-content/;
}
}

Документация по использованию FastCGI в nginx приведена здесь, поэтому я не буду подробно останавливаться на том, что конкретно каждая директива делает.

Основная магия происходит в строка 8—10: здесь определяются условия, при которых отдаётся свежая страница. В данном случае проверяется наличие авторизационных cookie и cookie комментатора. Важно, чтобы в случае отказа от кэширования переменная $do_not_cache устанавливалась в 1.

Строка 16 задаёт ключ, по которому страница доступна в кэше. В ключе присутствует $request_method, чтобы различать запросы GET и HEAD (для HEAD данные не возвращаются, только заголовки).

Строки 17—19 задают время жизни кэша в зависимости от кода ответа. Чем больше время жизни, тем реже будет обновляться информация для незарегистрированных пользователей.

В строке 32 задаётся маска для страниц, которые не должны кэшироваться (например, админка, страницы логина и регистрации, фиды).

Так как содержимое страницы может отличаться в зависимости от cookie пользователя, в строках 49 и 59 для закэшированных страниц принудительно выставляется заголовок Vary: Cache. Если используются другие правила (например, фильтрация по User-Agent), нужно добавлять соответствующее правило.

Строки 21—23: подробнее описано в статье «Перенаправление RSS в WordPress на FeedBurner для nginx»

Строки 28—30, 63—66 подробнее описаны в статье «WordPress MultiSite, nginx и X-Accel-Redirect»

Вроде бы ничего не забыл. Теперь о том, какую производительность мы получаем:

$ ab -n 10000 -c 100 http://blog.sjinks.pro/
Server Software: nginx
Server Hostname: blog.sjinks.pro
Server Port: 80

Document Path: /
Document Length: 50294 bytes

Concurrency Level: 100
Time taken for tests: 46.925 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 504940000 bytes
HTML transferred: 502940000 bytes
Requests per second: 213.10 [#/sec] (mean)
Time per request: 469.254 [ms] (mean)
Time per request: 4.693 [ms] (mean, across all concurrent requests)
Transfer rate: 10508.28 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 16 94 76.9 94 3125
Processing: 118 373 81.7 360 1334
Waiting: 17 69 38.5 57 422
Total: 156 467 105.0 445 3535

Percentage of the requests served within a certain time (ms)
50% 445
66% 454
75% 471
80% 494
90% 541
95% 589
98% 655
99% 768
100% 3535 (longest request)

Сервер зафлудили 10,000 запросами в 100 параллельных потоков. Сервер выдал практически полгигабайта за 47 секунд; в среднем сервер обрабатывал 213 запросов в секунду, при этом 99% запросов были обработаны за 768 мс (при том, что на сервере несколько сайтов в Alexa Top 100,000)! Нагрузка на сервер была минимальной (изменений Load Average замечено не было).

UPDATE: есть один небольшой нюанс: CAPTCHA. Если вы их используете, убедитесь, что они работают. Дело в том, что страница со статьёй будет отдаваться непосредственно из кэша nginx, PHP загружаться не будет. Поэтому если CAPTCHA полагается на использование сессии, она может работать неправильно. Здесь всё зависит от используемого плагина.