Когда новости сами приходят

Сегодня получил письмо с приглашением присоединиться к сообществу Zend Framework, в котором общаются на моём родном русском языке. Отличная новость – русскоязычное сообщество, форум, раздел статей (правда на данный момент пустовато, но, как я понимаю, всё только начинается), полезные ссылки.

Очень приятно, что мой любимый Zend Framework начинает набирать обороты и становиться популярнее, следовательно, появятся примеры, статьи, уроки и жизнь разработчиков станет более лёгкой.

Ещё в сети можно найту Google Group: ru-zend-framework и конечно родной сайт Zend Framework.

Почему мне начинает нравится Zend Framework и PHP

  1. Мне нравиться PHP
  2. Мне очень нравиться PHP
  3. Мне нравиться то, как сделан Zend Development Environment и то, что Zend Development Environment прекрасно поддерживает Zend Framework с подсказками кода
  4. Мне нравиться то, что я всегда без проблем могу посмотреть в исходники Zend Framework и разобраться что к чему
  5. Мне нравиться Zend Framework потому что я могу продуктам с его использованием спокойно делать стандартный debug с Zend Development Environment, поставить Break point там где хочу и посмотреть как оно там всё происходит
  6. Мне нравиться, что я его могу тупо скачать как ZIP или TGZ, закинуть на сервер куда угодно, прописать в include_path и радостно пользоваться им как хочу
  7. Мне нравиться, про я могу использовать разные шаблоны запуска/создания проекта, именно такие, какие мне нравятся или кажутся нужными для проекта
  8. Мне нравиться, что PHP можно без проблем за несколько минут поставить почти на любую платформу, а значит там можно запустить Zend Framework

Zend Framework 1.0.0 – как бы я строил начальный каркас

Не знаю, на сколько я прав в этом вопросе, но я не думаю, что совершил много грубых ошибок в проектировании. Тех, кто далёк от архитектуры Model-View-Controller попрошу остановиться и ознакомиться где-либо с этой идеологией.

Итак, для установки Zend Framework 1.0.0 на сервер не нужно никаких особых шаманств с бубном. Всё что вам нужно, это соответствовать требованиям Zend Framework. Там нет ничего сложного – PHP 5.1.4 (рекомендуется 5.2.2), SPL и, возможно, некоторые extensions, если вы будете использовать определённые компоненты Zend Framework.

Структура каталогов для быстрого старта с Zend Framework о которой пойдёт речь далее.

Continue reading

Первые 8 часов с Zend Framework 1.0.0

Провёл с Zend Framework 1.0.0 около 8 часов. Результат: всё-таки я это дело запустил, подключился к базе, сделал 404 страницу, сделал форму регистрации. Подводных камней куча. Мануал по Zend Framework и примеры желают лучшего. По сравнения с Ruby on Rails стартовать реально сложно – примеры все написаны под разные версии до 1.0.0 и очень часто отличаются структурой.

Первое и самое лёгкое в процессе, это установка: всё просто – скопировал в папку, в include_path закинул и всё, можно пользоваться. Подробности – Introduction to Zend Framework, Installation.

Далее – контроллеры. С ними Quick Start прошёл тоже быстро. Фактически всё из Quick Start прошло без проблем, кроме 404 страницы. Всё сделал как они описали, но не заработало. Код я видимо взял из примера и у меня пробрался throwExceptions в режиме true, как только я понял что к чему, всё заработало. То, как устроена обработка 404ой ошибки с Zend_Controller_Plugin_ErrorHandler мне понравилось. Пока не разобрался с возможностью самому задавать правила роутинга, но это наверняка мелочь уже.

Что меня на данном этапе удивило – это то, что нет единой принятой структуры каталогов, как у Ruby on Rails. Конечно, в Quick Start есть пример, но всё это сделано руками и где-то в мануале, а на это статью не сразу натыкаешься. Я бы сказал не хватает Creating a weblog in 15 minutes – с Ruby on Rails я как-то проще начинал.

Итак, так как я уже разобрался с контроллерами и акшинами, я перешёл к конфигам. WOW! и никаких конфигов тоже небыло. Если надо – пожайлуста, делай сам, из массива, из .ini или из .xml. Где и как будет лежать – наши/ваши проблемы.

Конфиг есть, пора бы и за базой поработать. Обилие возможностей для работы казалось бы не может не радовать. Zend_Db_Select, Zend_Db_Table, Zend_Db_Table_Row. Осилил я Zend_Db_Table и Zend_Db_Table_Row. Часа 3 потратил на то, чтобы загрузить модели, ну или то, что в Zend Framework называется моделью. Оказывается, не смотря на то что в структуре примера есть папка application/models у меня их автоматом не грузит. Как их грузить я вообще не нашёл, поэтому тупо сделал им require_once и всё вроде заработало.
Пока не нашёл способа, куда вводить их моделям валидацию, как в Ruby on Rails, видимо, в Zend Framework всё реализовано по другому. Особо хакать исходники времени небыло, я оставил всё как есть. Потом меня приятно удивил метод save – в случае ошибки, он падает с Exception. Я ожидал что он элементарно будет возвращать true/false и всё. Ладно – обошли это проблему пока, и особых решений этой проблемы я пока не видел, зато видел где-то в их wiki много try { […] } catch { […] } при работе с их моделями.

Скажу честно – впечатления пока никакие. Я ожидал намного больше и со стороны документации и со стороны примеров. да и со стороны самого Zend Framework 1.0.0 я ожидал куда более простую систему, чем увидел. Может это и не верное первое впечатление, но именно оно отталкивает меня от использование Zend Framework в работе и заставляет меня использовать личные разработки.

SimpleActiveRecord 0.0.2

Сегодня я запустил в свет SimpleActiveRecord 0.0.2.

Что нового?

  • Ввёл тесты для магических методов, которые естественно, он завалил, и их я тут-же поправил.
  • Плюс ко всему добавилась проверка на то, NULL или не NULL значение поля по умолчанию если оно пустое должно быть. Теперь, если сделать unset(); для поля и у него NULL = YES в структуре базы – оно после сохранения станет NULL а не пустой строкой. Присвоение значения по умолчанию при unset();
  • Разделил тесты между простыми методами и методами создания записей в базе.
  • Заложил возможность на проверку типов данных. Уже сейчас он проверяет значение поля типа SET на соответсвие сета.

Что для меня важного в этом классе?

  • Он сам узнаёт название таблицы в конструкторе.
  • Сам подгружает имена полей, их типы и значения по умолчанию.
  • Я приучаю себя всегда документировать код.

Маленький кусочек OpenSource

Так как каждый из нас, программистов, постоянно экспериментирует и старается развивать себя и свои возможности и знания, я регулярно пересматриваю разные чужие OpenSource решения, пишу какие-то свои маленькие скрипты, библиотечки, классы, которые иногда даже не выходят за пределы localhost или превращаются в коммерческие продукты dip.:studio – их выкладывать на обзор всей публики не целесообразно, но чем-то поделиться хочется.

Так вот, в свободное время, дома, я начал писать маленький простенький ActiveRecord. Пока могу показать только версию SimpleActiveRecord 0.0.1. В пакет входит сам класс, быстро сгенерированная документация на phpDoc (там есть примеры использования), маленький набор тестов Unit Тестов на phpUnit. Всё это чудо рассчитано на PHP 5.2.3.

Я не буду утверждать, что это супер-оригинальное или гениальное решение, просто это мой взгляд на быстрою и простую реализацию ActiveRecord в версии 0.0.1. Если у кого либо есть конструктивные комментарии – пишите (модерация включена, пересматриваю регулярно раза 2 в день).

Как, бывает, хранят пароли

Я, пока, опущу ту вкусную часть, как при помощи SQL-Injection можно получить пароли пользователей, но желающие могут самостоятельно прочесть IV раздел мануала о Безопастности SQL Injection . И расскажу о самой неприятной (ок, не всем не приятной) привычке – открытых паролях и том как их хранят в других случаях.

Итак, первый и самый простой случай, когда пароли хранятся в таблице (название не имеет значения, но очень часто это бывает таблица users, admins или members, возможны разные префиксы), в поле password (обычно нужные поля очень легко узнать по форме регистрации или логина). Оно очень приятно, когда у сайта есть уязвимость ввиде SQL-Injection – вытянуть пароль и логин нужного вам пользователя не составит никакого труда. Время, нужно на поиск, занимает от 10 минут до нескольких часов – всё зависит от мастерства и фортуны (но не стоит исключать человеческий фактор). Кстати, если базу уводят (физический дамп с сервера), создателям скажут “спасибо”. Такие разработчики обычто оставляют незащищённый phpMyAdmin на сервере в легко доступном месте, а иногда оставляют SQL-Injection в скрипте логина в CMS. Вы конечно скажете – бред, не может быть, но всё-же такие случаи встречаются в моей практике и не раз.

Более сложный вариан для взломщиков – когда пароли хешируют. Обычно, встречаются варианты когда пароль просто хеширую при помощи md5 или других функций. Хотя тут, народ исхитрился иметь небольшие базы готовых хешей. Значит и тут пароли могут пострадать – вопрос размера базы хешей и то, какой это хеш. Конечно, все пароли не раскроют. Часто в базе – словари, фразы, а всякие “kld8jSkhYakKd772” там наврятли будут – всё зависит от размера базы, вашей удачи и, иногда, от теории вероятности (про коллизию не забываем, да).

Итак, в резюме, получается, что с паролями излишняя параноидальность вам/нам не помешает. Если вы поманипулируете с паролями пользователей (да и администраторов) – вам это не повредит ни в коем случае. Сделать пару SALT, докинуть чего из “логина”, добавить битовую операцию, потом сделать base64 енкодинг и только потом хеш – это наверняка затруднит восстановление ворованного пароля.

А что вы посоветуете?

Что я знаю о register_globals

Постоянно сталкиваюсь с серверами, где по умолчанию register_globals = On. Да, мне ничто не мешает взять .htaccess и отключить: php_value register_globals Off или написать письмо администратору сервера. Однако, иногда и сам забываешь о той угрозе, которую несёт в себе register_globals = On.

Для того, что-бы воспользоваться чем-то, что даёт вам register_globals = On, нужно либо иметь на руках исходники скрипта, либо быть очень счастливым с…м сыном (ну ещё есть шанс, что ошибки, выбрасываемые PHP вам помогут). Естественно, речь идёт о Global Scope.

На днях я перебирал один маленький сайтик, где PHP используется только для того, что бы можно было удобно и быстро подключить хедер и футер, меню и для страниц легко менять тайтл и мета данные. Такой классический сайт из учебника, плюс несколько наворотов, которые позволяют кешировать сайт на стороне клиента так, как будто это статически HTML. Теоретически, если отключить expose_php и сделать ServerSignature Off, а ServerTokens Prod мало кто догадается, что это PHP.
И нашёл я там одну переменную, которая отвечала за подключение отдельного CSS для страницы. Она была задекларированна не во всех файлах, а толxко там, где требовался дополнительный CSS файл. Именно в тех файлах, где эта переменная не была установлена, её можно было установить при помощи GET, POST или COOKIE (ведь мы помним о variables_order). Плюс никакой фильтрации. Идеальное место для XSS type1 атаки. Но для такой атаки имя переменной нужно знать.

Есть ещё такой стиль программирования, когда массивы никто не декларирует, а сразу к ним обращается. Я имею ввиду, что некоторые программисты не пользуются таким выражением: $arr = array ();, а сразу выполнят присваивание: $arr[] = ‘some value’;. Опять же через GET, POST или COOKIE в таком случае можно передать первые ключи для массива $arr. И тогда сколько таких переменных есть у них, которые можно поменять, зная их имена?

Вроде и нет ничего страшного, действует только на Global Scope, надо знать название переменной, но вы не можете гарантировать, что копия сайта е попала в руки мальчишам-плохишам. Так, однажды, получив исходники одной CMS, можно досконально изучить её код, найти уязвимые места, а потом вскрыть этак сайтов 10-15 с одной и той-же ошибкой. Именно так однажды случилось с CMS моего знакомого: CMS решал, человек залоглен или нет, опираясь на онду переменную $admin_id. Стоило сделать запрос admin.php?admin_id=1 и коробочка раскрылась и даже не смотря на то, что этот $admin_id должен был придти из сессии – н там не был установлен (я взял новую сессию) и скрипт пощитал, что всё впорядке и можно пользоваться.

Короткое резюме: пишите свои проекты с учётом register_globals = Off; если вы уверены, что вами написанный проект отлично работает с register_globals = Off, а на сервере register_globals = On – отключите register_globals, так как в редких случаях это может вызвать неадекватное поведения вашего проекта; если вам приходиться работать со скриптами, которые требуют register_globals = On (только в том случае, если это необходимо), будьте предельно бдительны, не сделайте глупых ошибок, связанных со свойством register_globals = On, а также проведите аудит скрипта на возможные ошибки – вы последний, кто его редактировал и все бочки посыпятся на вас.