Задумал я на базе этого блога сделать себе OpenID. OpenID — это способ идентифицировать и аутентифицировать себя на многих web-сервисах с помощью одной учетной записи. Фактически это означает, что получив один раз OpenID, можно больше не регистрироваться на сотне сайтов только ради того, чтобы читать приватные записи или писать комментарии. Конечно, эти сотни сайтов должны поддерживать OpenID. Получить OpenID можно во многих местах абсолютно бесплатно, например в том же LJ. Или настроить OpenID provider у себя в standalone блоге.
Вообще, я много лет жил без OpenID и прожил бы еще столько же, но недавно мой хороший друг уехал далеко-далеко и стал описывать свое новое житье в LJ. А так как он слегка страдает паранойей, все его записи доступны только «для друзей». Конечно, можно было завести технический аккаунт в LJ, единственной целью которого было бы предоставление доступа к приватным записям, но это совсем не комильфо.
В целом задача выглядела очень простой. Для WordPress (а этот блог работает именно на нем, если вдруг кто не понял) есть специальный плагин, который так и называется — OpenID, он предоставляет функционал как потребителя OpenID (для тех же комментариев), так и провайдера. Однако после установки плагин не заработал, так что пришлось засучить рукава и выяснять почему. Для тестирования в качестве потребителя OpenID использовался все тот же LJ.
Первое, что нагуглилось сразу — текущая версия OpenID 3.3.2 не работает с PHP 5.3, а именно его я использую по ряду причин. Патчик, исправляющий проблему, очень простой и действительно рабочий. Кроме того автор патча утверждает, что обратная совместимость не ломается, так что есть надежда, что в новой версии плагина эта проблема будет исправлена. Однако в Subversion репозитории проекта этого патча почему-то нет. На всякий случай я напомнил автору OpenID об этой проблеме.
Вторая проблема была связана с тем, что при авторизации возникал переход по адресу вида http://blog.name/index.php/openid/server…, который заканчивался ошибкой 404. Эта проблема также известна, и даже есть кривая заплатка. Чтобы понять ее причину и, главное, найти правильное решение, нужно сделать шаг в сторону и выяснить, как устроены постоянные ссылки в WP.
Постоянные ссылки на записи не меняются со временем и могут быть использованы на внешних ресурсах. По умолчанию WP генерирует постоянные ссылки вида http://blog.name/?p=123. Они не очень красиво выглядят, так как содержат в себе CGI параметры. «Красивые» ссылки вида http://blog.name/raznoe/kak-ya-provel-leto возможны при наличии mod_rewrite в Apache или соответствующих правил в конфигах lighttpd или nginx. Есть еще одна возможность, из-за которой собственно все и не работает — так называемые «почти красивые ссылки», или PATHINFO permalinks. Ссылки такого типа выглядят как http://blog.name/index.php/raznoe/kak-ya-provel-leto.
Метод PATHINFO (точнее даже PATH_INFO) работает только в Apache и использует одну его интересную особенность: по умолчанию URI вида /path/script.cgi/another/path, при наличии скрипта path/script.cgi, приводят к вызову обработчика этого скрипта, при этом устанавливается специальная переменная окружения PATH_INFO со значением равным /another/path.
У меня Apache нет, вместо него стоят nginx и php-fpm. В конфиге nginx присутствуют строчки, эмулирующие поведение mod_rewrite:
if (!-e $request_filename) {
rewrite . /index.php last;
}
Вообще говоря, господин Сысоев всячески порицает (см. самый низ страницы) подобные конфиги, однако рекомендуемая им директива try_files присутствует только в nginx 0.7.x, тогда как у меня в Debian Lenny nginx версии 0.6.x, и менять его пока желания нет.
С nginx и его rewrite отдельная очень интересная история. Если зайти на страницу конфигурирования WP в раздел постоянных ссылок, то можно увидеть такую картинку:
Как видно, в качестве альтернативы «некрасивым» ссылкам WP предлагает использовать PATHINFO, которое не работает в nginx! Происходит это из-за того, что WP проверяет имя сервера, и если оно не Apache, или если Apache, но не загружен модуль mod_rewrite, то для постоянных ссылок по умолчанию включается режим PATHINFO. Справедливости ради надо отметить, что на самом деле правила rewrite для nginx, приведенные выше, все-таки заставляют схему с PATHINFO работать. Видимо, WP внутри себя как-то решает эту проблему. Но вот его плагины, в частности OpenID — нет, из-за чего собственно весь сыр-бор.
Так вот, оказывается, существует специальный плагин nginx Compatibility, который, во-первых, сообщает WP, что mod_rewrite как будто бы присутствует, а во-вторых, чинит какую-то проблему с FastCGI PHP SAPI, которая нас сейчас не интересует.
После активации плагина страница настроек стала выглядеть правильно:
По умолчанию предлагаются красивые mod_rewrite постоянные ссылки.
Но вернемся к OpenID. Проблема с ним заключена в нескольких строчках кода в файле common.php:
if ($wp_rewrite->using_permalinks()) {
$url .= 'index.php/openid/' . $service;
} else {
$url .= '?openid=' . $service;
}
Автор неявно полагает, что если включены красивые постоянные ссылки, то механизм PATHINFO точно должен работать. Как было показано выше, это верно только для Apache. Таким образом если у вас не Apache (а у меня не Apache), и вы используете красивые постоянные ссылки (а я их использую), то плагин OpenID у вас работать не будет. Замечу, что без использования красивых постоянных ссылок все работает.
Горячие головы предлагают выкинуть совсем строчки, добавляющие index.php в URI, но не думаю, что автор на это согласится, все же он эти строки не зря добавил.
Чтобы найти правильный путь, нужно поставить еще один плагин — AskApache RewriteRules Viewer. Он показывает всю внутреннюю кухню постоянных ссылок:
Видно, что свойство using_permalinks, на которое опирается OpenID, действительно истинно, но свойство using_index_permalinks, которое на самом деле показывает, что работает PATHINFO, ложно. Таким образом правильным решением будет замена в вышеприведенном куске кода using_permalinks на using_index_permalinks. После того, как это было сделано, плагин успешно заработал, а соответствующий патч был отправлен автору.
Ну и вставил немного русского перевода. Русский перевод хорошо бы сделать полностью и отослать автору, там работы-то на пару часов.
нотацию. Пригодится для рассказывания всяческой околонаучной фигни.