понедельник, августа 30

Zend Framework XML-конфиг и константы

В предыдущем посту я написал про то, как легко перейти с INI-конфигурации на XML-конфигурацию. В использовании оной есть как плюсы, так и минусы.

из плюсов, как минимум то, что не приходится писать кучу повторяемых "веток" вида "resources.frontController" - мы пишем простое XML-дерево.
из минусов:
1) чтение XML-конфигурации несколько дольше (по тестам, что нашёл - ~0,15 сек). но есть подозрение, что ещё быстрее, чем ini-файл будет подсовывание напрямую массива как конфигурации
2) При автоматическом форматировании XML в редакторах, значения с zf-константами форматируются "криво" - переносятся на новые строки.

Решением проблемы (2) мы и займёмся.
Для начала скажу, что для разработки я использую Eclipse, а для загрузки файлов на сервер - ant-скрипт, который делает предварительную сборку файлов перед загрузкой на сервер. В нём же производятся некоторые действия над файлами, одно из которых я приведу ниже.

Определим правило, что константы вместо "<zf:const zf:name="константа">" в xml-конфиге будем описывать как "%ZF.константа%". для замены содержимого в файле, воспользуемся task-ом replaceregexp, выглядящий следущим образом:

<replaceregexp flags="g">
 <!-- заменяем "%ZF.константа%" на "<zf:const zf:name="константа" />" -->
 <regexp pattern="%ZF.(.*)%" />
 <substitution expression="&lt;zf:const zf:name=&quot;\1&quot; /&gt;" />
 <fileset dir="${target}/application/configs" includes="**/*.xml" />
</replaceregexp>

собственно на этом всё. :)
Итого: на этапе разработки мы получаем удобный XML, без "лишних" тегов, а на сервере правильный xml-конфиг с понятными для ZF константами

Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

Zend Framework и XML конфиг вместо INI

Делается всё просто как на 1-2-3:

1) открываем файл public/index.php
2) после строки "require_once 'Zend/Application.php';" дописываем строку "require_once 'Zend/Config/Xml.php';"
3) вместо
$application = new Zend_Application(APPLICATION_ENV, APPLICATION_PATH . '/configs/application.ini');
пишем строки:
$cfg = new Zend_Config_Xml(APPLICATION_PATH . '/configs/application.xml', APPLICATION_ENV);
$application = new Zend_Application(APPLICATION_ENV, $cfg->toArray());
4) сохраняем изменения

да, и не забываем создать xml-файл конфигурации вместо ini-файла ;)


Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

суббота, августа 21

NAT & iptables в Linux (CentOS)

несколько часов убились мною и моим коллегой "по цеху" на поиск решения "да что за нафиг такой?" :)

преамбула:
на сервере используется скрипт iptables.sh, который описывает правила для iptables. дело нехитрое - поправил правила, запустил, проверил работу и, если всё тип-топ, то сохранил правила.
В скрипте описание довольно нехитрое: очистили все правила маршрутизации и воссоздали их по новой.
Всё казалось бы просто, до тех пор, пока не столкнулись с nat-маршрутизацией :)

правила сбрасывались следующими строчками в скрипте:
$IPTABLES -F
$IPTABLES -X
, где $IPTABLES - путь до приложения (IPTABLES="/sbin/iptables")

в том же скрипте когда-то была настройка на переброс порта с 80 на 8080, от которой по некоторым соображениям, было решено отказаться.
дело не хитрое - заремили нужную строку и выполнили скрипт.
и, как говорится, "скоро сказка сказывается, да не скоро дело делается" - НЕ ПАШЕТ.
снова смотрим скрипт - всё верно. сохраняем правила, перегружаем сервер на всякий, что должно как минимум сбросить нам все правила и реанимировать их из сохраняшки. ага, щаз...

в общем, пока суд да дело, было найдено решение - в блок сброса таблицы маршрутизации требуется дописать отдельное правило для сброса именно nat-маршрутов:
$IPTABLES -t nat -F

после чего, весь блок сброса приобретает вид:
$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F

ЗЫ: подумалось, что это ведь довольно неплохая задачка для вопроса на собеседовании :)


Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

суббота, августа 14

плюшки Windows 7: список "программы и компоненты"

В показываемом списке работает комбинация Ctrl+R, обновляющая список. удобно - не нужно закрывать и заново открывать, чтобы увидеть свежеустановленное ПО
Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

среда, августа 11

Firefox (NoScript) и IBM PartnerWorld = XSS скриптинг

В какой-то момент, понадобилось добраться до ПО, доступного по партнёрской программе.
Захожу на сайт IBM, авторизуюсь, перехожу в раздел PartnerWorld. Иду в раздел "поиск и загрузка ПО" и... "а с платформы говорят"... в общем, получаю ошибку 503.

Первая мысль - что-то не то с учетной записью. Позвонил в IBM - выяснили, что всё нормально.
Начинаю изыскания на своей стороне.

После непродолжительного анализа, выясняется, что серверов-то у IBM многа и при сёрфинге по сайту, мы "скачем" с одного на другой и в итоге получаем подозрение на XSS-атаку, которую успешно блокирует плагин NoScript.

Чтобы этого не возникало, достаточно в настройки NoScript в разделе XSS (Дополнительно>XSS) добавить правило "^https?://.+\.ibm\.com/*" и, хвала!, всё заработало!


Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

воскресенье, августа 1

декоратор Sitemesh и страница ошибок

в предыдущем посте я написал как сделать обработку ошибок через Springframework

В своих проектах я использую Sitemesh для задания шаблонов дизайна для различных страниц.
Для страницы с ошибкой порой требуется её обработка в стандартном шаблоне дизайна. Что делать? рисовать дизайн заново? или можно воспользоваться тем, что предоставляет нам Sitemesh?
Конечно же, предпочтительнее последний вариант.
на FAQ-странице есть указание, что это можно сделать, но там присутствует ошибка - указаны не все диспетчеры для обработки. В список диспетчеров требуется добавить ERROR:

<filter-mapping>
    <filter-name>sitemesh</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>ERROR</dispatcher>
    <dispatcher>FORWARD</dispatcher>
    <dispatcher>REQUEST</dispatcher>
</filter-mapping>


Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

показ страницы ошибки с использованием Spring MVC

При разработке под веб, на "боевых" серверах требуется прятать сообщения об ошибках (ну или хотя бы их как-то "облагораживать").
Стандартный путь - описание обрабатываемых ошибок в web.xml. например такой:
<error-page>
 <error-code>404</error-code>
 <location>/error.jsp</location>
</error-page>
<error-page>
 <exception-type>java.lang.Exception</exception-type>
 <location>/error.jsp</location>
</error-page>

А что делать, если в проекте используется Springframework и хотелось бы использовать его возможности?
Всё достаточно просто. Требуется написать контроллер, который будет обрабатывать урл например вида "/error.htm" и в web.xml вместо "/error.jsp" указать "/error.htm" - код и сообщение об ошибке по прежнему будут нам доступны в объекте request.

Зачем это нужно, спросите вы? Например это позволит автоматически сформировать сообщение администратору системы о возникшем сбое, или добавить логику для обработки возникшей ошибки.