Записи с меткой «патчи»

Administrivia

29.12.2010

Теперь можно оставлять комментарии, пользуясь своим аккаунтом Facebook или Twitter. Как всегда, не обошлось без доработки плагинов напильником.

, , , ,

ЭВМ/ OpenID consumer для WordPress

22.12.2010

Надеюсь, вы уже успели насладиться ими. Расскажу, как непросто было их сделать.

Как вы, наверное, заметили, комментарии тут сделаны на базе аутентификации через OpenID aka OpenID consumer. Эта функциональность входит все в тот же плагин OpenID, о котором я уже писал, нужно только поставить соответствующие галочки в настройках. Однако после этого начинается самое интересное.

Во-первых, стандартная форма для комментариев, предлагаемая этим плагином, страшна, как смертный грех. Кроме того, она предполагает вбивание вручную полностью OpenID идентификаторов, которые у некоторых провайдеров могут быть довольно длинными. Для решения этой проблемы служит другой плагин: Comments with OpenID. У него есть красивые иконки для большинства известных OpenID провайдеров, нажимая на которые, можно получить заготовку идентификатора, в которую остается только вбить имя пользователя. Плагин пришлось форкнуть и поправить из-за LiveJournal. Эти орлы сломали у себя OpenID, хотели запретить OpenID аутентификацию только для переименованных аккаунтов, а в результате поломали для всех. Поэтому я удалил их иконку, пока не починят. Еще я заменил шаблон OpenID идентификатора для Google, чтобы получалась красивая ссылка на профиль.

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

Например, Google не отдает свойство namePerson, а отдает два отдельных поля namePerson/first и namePerson/last. А mail.ru так вообще нарушает спецификацию и не передает необходимый параметр openid.ns.sreg. По этому поводу я, кстати, написал им в техподдержку; на результат, правда, особо не надеюсь. В общем, все эти мелочи я поправил опять-таки в своем форке плагина openid. Самые приличные комиты послал автору, надеюсь, включит в очередную версию, а остальной трэш типа заплатки для mail.ru поместил в отдельную ветку wip (work in progress).

Кроме того, я добавил в плагин возможность требовать обязательного наличия OpenID. Нужно поставить новую галочку в настройках «Require OpenID authentication».

Ну и вставил немного русского перевода. Русский перевод хорошо бы сделать полностью и отослать автору, там работы-то на пару часов.

В общем, как это обычно бывает, объединение якобы открытых систем на базе якобы открытых протоколов оказалось делом хлопотным.

, , ,

ЭВМ/ Социальное программирование

16.12.2010

Можете меня поздравить, я теперь социальный хакер. Отправил свой первый запрос на пулл (ну и лексика, хосподи помилуй) на гитхабе. Все про тот же OpenID, будь он неладен. PHP’шные фиксы автор, кстати, таки добавил уже. Точнее, они, похоже, сами добавились вместе с обновлением библиотеки openid.

, ,

OpenBSD/ cd(4) hotplug

19.03.2010

Недавно возникла задача научить любимую жену пользоваться моим лаптопом с OpenBSD. OpenBSD — система аскетичная и весьма недоверчиво относится к женщинам. Для снижения недоверчивасти был настроен графический вход через xdm(1), сделаны красивые ярлыки на браузер и прочие полезные программы, настроен hotplugd(8) для автомонтирования USB-флешек. Осталась только одна проблема — компакт-диски, в OpenBSD до сих пор нету их автоматического монтирования и размонтирования.

Нету, значит нужно сделать. Первоначальная идея была очень простой: пусть драйвер cd(4) каждые несколько секунд посылает в привод SCSI команду Test Unit Ready. Если диск есть, команда отработает нормально, если диска нет — вернется с ошибкой. Идея оказалась вполне рабочей. Но коллеги по цеху сказали, что метод так себе. Более того, они высказали опасения, что на некоторых старых машинах это может привести к неожиданным результатам. Например Miod вспомнил, что у него есть дисковод, который открывает лоток при получении команды TUR.

Тогда я еще почитал описание SCSI команд и нашел то, что мне нужно. Команда Get Event/Status Notification позволяет узнать, какие события происходили с дисководом, в частности был ли вставлен новый диск или нажата кнопка выемки диска. Новая версия патча заработала отлично и в целом возражений не встретила. Но и явного одобрения тоже, поэтому в OpenBSD 4.7 этой возможности не будет. Думаю, к 4.8 я ее протолкну, если не лень будет. А пока любители пересобрать ядро могут поиграться с патчем.

Понятно, что к патчу должно прилагаться правильное содержимое /etc/hotplug. Например такое.

attach:

#!/bin/sh

DEVCLASS=$1
DEVNAME=$2

case $DEVCLASS in
2)
	# disk
	case $DEVNAME in
	cd*)
		mount -o nodev,nosuid /dev/${DEVNAME}a /mnt/cdrom
		test -d /mnt/cdrom/VIDEO_TS && umount /mnt/cdrom
		;;
	sd*)
		mount -o nodev,nosuid /dev/${DEVNAME}i /mnt/flash
		;;
	esac
esac

detach:

#!/bin/sh

DEVCLASS=$1
DEVNAME=$2

case $DEVCLASS in
2)
	# disk
	case $DEVNAME in
	cd*)
		umount -f /mnt/cdrom
		eject /dev/${DEVNAME}c
		;;
	esac
esac
,

ЭВМ/ OpenID

18.03.2010

Задумал я на базе этого блога сделать себе 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. После того, как это было сделано, плагин успешно заработал, а соответствующий патч был отправлен автору.

, , , ,