goodguy о разработке   python, zope, php, sqlite, postgresql, mysql и прочее с чем сталкиваюсь

Интересная заметка на habrahabr про то как минимальными усилиями сделать из обычной админской панели django красивый и удобный интерфейс.

Недавно потребовалось быстро развернуть более-менее универсальный магазин для нашего нового проекта торговли велотоварами. PHP-системы мне как-то не нравились и из симпатии к python начал было писать проект на django, но вскоре понял, что скорее всего получается велосипед, и начал искать что-то готовое. Оно пришло в виде Satchmo, весьма универсального и накручиваемого решения для электронной торговли. Что понравилось – немало настроек, в которых поначалу можно запутаться. Есть тонкости в адаптации под себя, но они описаны в документации (один отсутствующий момент – это как обновлять sitemaps, пришлось додумывать и доделывать самома). Но главное, магазин развернулся из коробки и через пару часов в нём уже можно было добавлять товары. А вот допиливания мелочей происходят уже по ходу, и зачастую незаметно для посетителей

Python опять обрадовал меня наличием готовых модулей для всего и вся. На этот раз повезло быстро разобраться с чтением конфигурации из XML файла – для этого идеально подошёл модуль xmlobjects и простая конструкция вида:

import xmlobjects
import psycopg2

xml = """

   user
password
   dbname

"""

conf = xmlobjects.fromstring(xml)
conn = psycopg2.connect('dbname=%s user=%s password=%s' % (
    conf.db.dbname, conf.db.user, conf.db.password))

В модуле pecl_http есть очень удобный, но при этом не всегда хорошо задокументированный класс HTTPRequest. Одной из проблем, с которой я столкнулся при работе с ним, это то, что в случае ошибок при HTTP-соединениях, выбрасывались исключения с текстами:


(HttpInvalidParamException) Empty or too short HTTP message: ''


Понятное дело, для отладки они не подходят. Но, если вывести исключение полностью, то обычно там как-раз и были подробности проблемы:


exception 'HttpInvalidParamException' with message 'Empty or too short HTTP message: ''' in example.php:189 inner exception 'HttpRequestException' with message 'Timeout was reached; Operation timed out after 10000 milliseconds with 0 bytes received (https://example.ru/)' in example.php:160


Видно, что самое важное содержится в сообщении от inner exception. И его, оказывается, легко поймать, если поставить дополнительный блок catch на HTTPException, например:

try {
    $request->send();
} catch (HttpException $ex) {
    if (isset($ex->innerException)){
        echo $ex->innerException->getMessage();
        exit;
    } else {
        echo $ex;
        exit;
    }
}

Информация получена отсюда.

Очередной случай из жизни натолкнул меня на мысль расписать, как из PHP создать подписанный по стандарту SOAP Message Security SOAP-запрос по SSL-соединению. Насколько я понимаю, стандарт этот не единственный, но используется достаточно широко и базируется на различных XML-стандартах W3C.

Сама суть механизма подписи хорошо описана в этой статье, из которой и я почерпнул для себя несколько полезных моментов, на которых возник ступор поначалу. Но предлагаемый мной вариант имеет одно важное дополнение: он добавляет в SOAP-сообщение ещё и информацию о сертификате, с помощью которого была сделана подпись. Кстати, меня удивила логика одной системы, для которой это делалось (кстати, написанной на Microsoft’овских компонентах): помимо сертификата в SSL-соединении они ещё проверяли сертификат и в самом запросе, хотя могли бы и воспользоваться данными HTTPS и тем самым получить ещё дополнительную проверку того, что соединение открыто тем самым агентом, который подписывал запрос.

Основным моментом в подписи является то, что собираются хэши (дайджесты) узлов с данными, которые будут подписаны (при этом узлы приводятся в канонический вид с помощью утилиты xmllint из комплекта libxml2). После чего собранные внутри одной «обёртки» дайджесты подписываются ключом сертификата, тем самым гарантируя, что если подпись верна, то данные в этих узлах не были изменены во время передачи запроса.

Класс так-же переписывает механизм HTTP-запроса к удалённому серверу, т.к. даже с помощью stream_context PHP не позволяет использовать совместно с SOAP сертификаты в формате PKCS12. В итоге используется HTTPRequest, результат которого уже транслируется далее в обработку.

• Собственно сам класс: SignedSoapClient.zip

Вроде бы простой вопрос, сколько рядов было затронуто SQL-операцией UPDATE, но и здесь притаился подводный камень (о котором, правда честно предупреждают в документации). В MySQL в это число могут не попадать записи, у которых данные не потребовалось изменять. А значит, если REPLACE не подходит, то нужно проводить дополнительные проверки на тему того, сколько же данных вы обновили. Я споткнулся об этом в функции mysql_affected_rows в PHP. Там-же можно найти один из вариантов решения – использовать mysql_info, но в этом случае нужно парсить строку с ответом. Ну а дальше в вариантах SELECT‘ы и т.п.

Вот, что и требовалось доказать – стоило перестать лениться и откладывать «на потом», как за вечер бот из предыдущего поста научился понимать Atom (в необходимой мере) и постить в Blogger (благодаря чему обновляется ещё одно зеркало зеркало моего блога). А всё благодаря более-менее продуманной архитектуре, да удобству python и Twisted в качестве средства разработки. И зачем люди ещё пишут на PHP сложные системы…

Кстати, у Blogger’а выяснилась пара забавных моментов. Первый – это то, он строго следует спецификациям Atom при создании и редактировании сообщений. Но при этом, если отправлять ему содержимое поста с типом xhtml, завернутое в <div xmlns="http://www.w3.org/1999/xhtml">...</div>, то назад он возвращает содержимое завёрнутое как html, но при этом сохраняет этот самый div. Логика загадочна для меня.

Второй момент ещё более непонятный: по ходу тестирования я делал пачки постингов в блог. В какой-то момент получилось так, что пост проходит, возвращается назад с присвоенным id и т.п., а в блоге не появляется. Никаких намёков на то, почему так, нет. Буду пробовать дальше

Дополнение: всё оказалось очень просто. Из-за кучи постингов во время тестов blogger включил для моего аккаунта требование вводить captcha перед каждым постом. По сути можно было написать в блог только через веб-форму. Налицо явная недоработка API, так как ошибку внятную можно было и вернуть.