Уже послезавтра (ну ладно, почти послезавтра) я буду делать доклад на очередной встрече харьковских QA - QAClub'е. И все было бы ничего, если б в анонсе встречи не были добавлены следующие строчки:

"Докладчики постараются рассказать на уровне, который будет доступен и для людей, только знакомящихся с темой безопасности web-приложений. Для понимания доклада про XSS (cross site scripting) знание JavaScript не обязательно".

После этого некоторые самые вкусные интересные вещи о XSS решил не рассказывать. Возможно, если доклад получится хорошим и будут желающие - будет вторая чать, более хардкорная, а пока планирую рассказать следующее:

  • Безопасность и Web - последние тредны о security в web'е.
  • JavaScript и HTML - пару слов об этом, браузерах и DOM, это необходимый минимум теории, который позволит понять остальное.
  • XSS – что это такое и с чем его едят? - наконец-то расскажу что означают буквы "XSS". 
  • XSS: тогда и сейчас - от 90-х до сегодня, экскурс в историю, основные тренды.
  • Делаем первые шаги - приступаем к практике, видео реальной XSS специально для QAClub(!).
  • Как это было у них? - истории взлома известных сайтов.
  • Что дальше? - пару слов об advanced техники xss.
  • Пару слов о защите

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

До встречи на QAClub 1 марта 2012г.


 

Продолжаю сравнивать различные python-библиотеки. На этот раз выбор пал на два тест-фреймворка: nose и pytest. Первый позиционирует себя как unit test framework, второй - как для модульных, так и для функциональных и других тестов. Но так, как грань между модульными, интеграционными и функциональными тестами достаточно тонкая, то ее часто не замечают. Поэтому, эти библиотеки можно использовать для всех вышеперечисленных тестов.

Краткое сравнение функциональности фреймворков (тут я выбрал наиболее важные для меня вещи):

  nose pytest
Репозиторий  https://github.com/nose-devs/nose https://bitbucket.org/hpk42/pytest/
Дата последнего изменения 15.02.2012 6.02.2012 
Последняя версия 1.1.3 2.2.3 
Лицензия   As is 
Документация  +, подробная, легко разобраться +, подробная, легко разобраться 
Запуск определенного набора тестов +
Генерация отчета в формате xUnit +
Настройка детализации отчетов  +  
Изменение стандартного наименования
+
Поддержка fixtures fixeures, setup* и *teardown методы +, parametrized tests 
Интеграция с django +, сторонний плагин +, сторонний плагин 
Соответствие PEP8  +
Расширяемость +, механизм плагинов +, механизм плагинов 
Интеграция с setuptools  +/- 

Минимальными требованиями к фреймворкам все более-менее понятно. В обоих есть необходимые фичи. А так как, в данный момент, мне сложно предположить что потребуется в будущем, то выбирать придется исходя из удобства использования, что является достаточно субъективным критерием.

Nose. Легко писать тесты, если до этого был опыт работы со стандартным модулем unittests или ТеstNG/nUnit в Java и .NET соответственно.

pytest. Мне показался более легким для начинающих. Может из-за более удобной для меня документации, но времени на то, чтоб написать тест для “hello world” приложения мне потребовалось меньше, чем при использовании nose.

Что буду использовать на текущем проекте - пока не решил. Скорее всего, главную роль сыграют плагины для интеграции с django и continius integration


RabbitMQ - одна из реализаций сервера для обмена сообщениями на базе протокола AMPQ(http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol, http://amqp.org/). Подробно описывать его работу, достоинства и недостатки я сейчас не буду. Цель этого поста - сравнить две библиотеки для работы с ним с помощью Python. На самом деле, этих библиотек значительно больше, краткий список их доступен на сайте RabbitMQ: http://www.rabbitmq.com/devtools.html#python-dev.

Сравнивал по принципу "нужно это, это и еще вооон то". Детальное описание фич на сайте - ниже только те, которые были критичные для меня.

Pika - Python AMQP Client Library - изначально разрабатывалась для работы с RabbitMQ и предоставляет собой реализацию протокола AMQP 0-9-1, в следствии чего, все примеры работы с RabbitMQ на Python в официальной документации написаны с использованием этой библиотеки.

Kombu известна тем, кто работал с OpenStack.

Небольшая сравнительная таблица с комментариями:


pika kombu
Репозиторий https://github.com/pika/pika https://github.com/ask/kombu
Дата последнего обновления 19.02.2012 21.02.2012
Последняя версия 0.9.6-pre0 2.1.0
Лицензия MPL 1.1 / GLP 2 BSD License / As is
Подход к написанию кода простой и понятный код явно прослеживается Publish–subscribe pattern
Поддержка SSL +(последняя версия из репозитория) +(последняя версия из репозитория)

Интеграция с Django из коробки
(есть документация и примеры)

- +
Асинхронная работа + +
Поддрежка Tornado/Twisted +/+ -/-
Кеширование из коробки - +
Поддержка разных транспортов для очереди сообщений ampq

amqplib
librabbitmq
pika
pika2
memory
redis
beanstalk
mongodb
couchdb
django (django models)

Документация +, примеры работы с RabbitMQ на сайте “кролика” +, примеры кода более сложные, чем “hello world”

 

В целом, после незначительного использования обоих библиотек (читать как “написал “hello world”” и чтения документации пришел к таким выводам:

 

  • для простых задач pika предпочтительнее, уровень вхождения ниже;
  • kombu имеет больше всевозможных настроек и легче поддается расширению;
  • производительность обоих библиотек на очереди до 100 сообщений была примерно одинакова.

 

 

Небольшой пример кода: https://github.com/e0ne/BlogSamples/tree/master/rabbitmq-sample

 

P.S. Хочется посмотреть еще celery и py-ampqlib, но пока до них руки не дошли.

P.S.S. Комментарии, замечания и дополнения приветствуются.

 


Еще один пост из серии "чтоб не забыть и знать где искать".

По умолчанию, RHEL 6.x и любой другой, основанный на нём (CentOS, Scientific Linux), кроме Fedora, дистрибутив в минимальной установки (в других не проверял) после запуска не поднимает доступные ему сетевые интерфейсы. Для их работоспособности необходимо сделать следующее:

# ifup eht0
# dhclient eth0

Первая команда включает сетевой интерфейс eth0, вторая - запускает DHCP Client. 

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

/etc/sysconfig/network-scripts/ifcfg-eth0

следующим образом:

ONBOOT="yes"
BOOTPROTO="dhcp"

Остальные параметры можно оставить без изменений.


 

Время от времени, при разработке очередного API, которое работает поверх HTTP или создается Socket-сервер после остановки и попытки запуска сервера получаю ошибку:

socket.error: [Errno 98] Address already in use

Проблема заключается в том, что при аварийном (Ctrl+Z) завершении сервера в операционной системе остается запущенным процесс, который слушает нужный мне порт. В разных ОС время жизни такого процесса разное: в RHEL это около двух минут, в Ubuntu - больше. 

Решение достаточно простое. Т.к. при нажатии клавиш Ctrl+Z процесс получает команду “keyboard interrupt”, то достаточно обработать нужное исключение и корректно завершить процесс:

 

 

Надеюсь теперь не буду забывать писать нужный try-except...

 

Пример кода на GitHub: https://github.com/e0ne/BlogSamples/tree/master/SocketError. Для его запуска необходимо наличие утановленного пакета SOAPPy.