что-то мне кажется, что это то же самое, что писать гостевую книгу на объектах с использованием каких-нибудь крутых фреймворков типа CakePHP - ненужно и глупо...
или если мы пользуемся ZF, то авторизацию иначе как через Zend_Auth не провести? о_О
Именно ZF и помогает не писать каждый раз одно и то же с кучами проверок и фильтров. Первый раз как увидел ZF_Auth, тоже решил. что наворочено и не нужно. А когда попробовал в деле - все оказалось быстро, ясно и приятно. Вот вам и выигрыш.
ZF это комплекс компонент, которые в сумме облегчают разарботку сайта. Не совсем правильно оценивать и гнобить данный фреймворк по конкретному примеру.
Поддержу den_rad, статья предназначена в первую очередь для знакомства с данным классом.
Сейчас потихоньку начинаем использовать ZF. Но используем в первую очередь ядро, контроллеры и настройки ... все остальное самописное легко интегрируем с системой. Но постепенно будем переходить полностью на средства ZF, имхо, так будет более правильно для организации проектов на ZF. Тем более что идет слух, что поддержка ZF может появится в самом php.
ZF мне понравился как раз тем, что в нем предусмотрено все, что необходимо и при этом сохранена гибкость благодаря грамотной ОО-реализации. Zend_Auth на учебном примере действительно смотрится как реактивный двигатель на велосипеде, но не нужно забывать, что это не реальная задача, а просто иллюстрация. В ней основное внимание уделено не прикладному предназначению программного продукта, а технологии его реализации. Чтобы можно было вникнуть в эту технологию, не отвлекаясь на предметную область какого-то частного случая. Факт, что ZF расчитан на программы более высокого уровня сложности, чем приведенная в примере. Несложные и автономно-работающие скрипты (мэйл-форма, например, или минимальная по функциям книга гостевая) не слишком выйграет от его применения.
Но я по своему опыту могу сказать, что все проиллюстрированный здесь и оставшиеся за кадром фичи на реальных задачах найдут свое применение. А благодаря тому, что фреймворк развивается как единое целое, а не набор отдельных компонент, это здорово облегчит задачу сохранения грамотной (и унифицированной) структуры приложения на его основе.
Очень приятно читать документацию и находить в ней довольно толковые решения многих задач, аналоги которых относительно недавно писал сам :)
После беглого просмотра этой и предшествующей статьей окончательно пропадает желание ближе знакомиться как с этим фрэймвоком в частности так и с самим PHP.
Спасибо!
Боюсь не совсем корректно выразился. Отрицательный бал статье я не ставил, наооборот, я благодарен автору, за сэкономленное время. В качестве фрэймворка для изучения я для себя уже выбрал джанго(www.djangoproject.com), в котором,к слову, та же система авторизации - стандартный плагин. Но нет нет да и посматриваю не ошибся ли в выборе, не появилось ли чего лучшего, как схожие задачи решаются в других фрэймвоках. И как раз просматривая такие обзоры с примерами и убеждаюсь насколько правильно я сделал свой выбор) По ПХП - это моё частное неофициально ощущение (надеюсь имею на него право?) Обосновывал я его тут:
http://recoilme.livejournal.com/1797.html
Я сам давно присматриваюсь в Django, да вот только руки никак не дойдут... Я бы посоветовал вам посмотреть на Symfony. Этот framework из той же серии, что и Django (Ruby on Rails). Возможно в нем вы найдете для себя что-нибудь интересное.
Давно думал как переделать свой тяп-ляп движок, и вот под руку попался Zend FW, классная штука уже начал думать как на основание его создать новый двигатель, огромное спасибо автору перевода, буду рад видеть продолжение!
Как я понял, в данном примере авторизационная информация храниться в течении сессии, то есть пока броузер не закрыт. А что надо делать, что бы запомнить пользователя на какое-то время? Есть соответствующие механизмы в Zend_Auth, или надо руками делать?
Если речь идёт о таймауте сессии - это делается через стандартные настройки РНР. Если же нужна ситуация, когда надо закрыть сессию юзера по истечению какого-то времени (довольно странная ситуация) - это можно легко добавить в preDispatch() контроллера, который будет проверять когда юзер залогинился (это время придется сохранить в сессии) и не пора ли его разлогинить.
Вот интересно какие есть плюсы у zend framework по отношению к symfony?
Кто-нибудь использовал один и другой framework в работе?
Symfony уже года 2 как из бэтты вышел, а zend framework из бэтты вышел буквально месяц назад.
Мне в symfony очень понравился генератор CRUD-приложений - это сильно экономит время. Есть такой в zend framework?
Не совсем по теме, но довольно важный нюанс: поле для хранения пароля в MySQL нужно создавать как VARCHAR BINARY, а не просто VARCHAR. Иначе пароль получается case insensitive, и стойкость пароля падает на порядок.
Хранить нужно хеш пароля, потому что:
1. зачем вам знать пароль пользователя, может у него на почте такой же
2. кто-нибудь может спереть базу
3. база кроме вас доступна еще и хостеру
Хеш нужно сделать понадежней, желательно нестандартным алгоритмом, иначе пароли пожно подобрать перебором (не обязательно совсем новый алгоритм, можно просто чуть поменять результат стандартного).
В случае хранения хеша необходимость BINARY отпадает.
Вариант pass_md5 мне совсем не нравиться, особенно если храниться действительно md5, это же подсказка злоумышленнику, а вот pass_hash гораздо лучше, нужно внедрить в свою практику, спасиб.
Security through obscurity - это не очень хорошая идея, особенно если без неё можно обойтись. И уж точно на неё нельзя полагаться как на один из основных механизмов обеспечения безопасности.
Так что пытаться скрывать алгоритм хеширования смысла мало. Все основные виды хешей обычно визуально определяются, и названием поля алгорим не скроешь. Что касается изменения результата стандартного алгоритма ручками, то обычно это тоже не спасает: дело в том, что в большинстве случаев когда хакер получает доступ к базе, он так же получает и возможность как минимум читать файлы на сервере, в том числе и файл с кодом вычисления и изменения хеша пароля.
Используйте стойкие алгоритмы хеширования, плюс проверяйте пароль за стойкость (либо перед хешированием, и отказывайтесь принимать от юзера слабые пароли, либо после хеширования - запустив john и требуя чтобы юзеры меняли пароли, которые john смог быстро подобрать).
Zend_Auth по-умолчанию использует PHP сессии для хранения авторизационных данных. Т.е. его можно использовать совместно с Zend_Session, но не обязательно. Подробности здесь: http://framework.zend.com/manual/ru/zend…
Если у меня есть административная часть сайта (CMS), и система авторизации на сайте (назовем "личный кабинет") — как Zend_Auth будет различать два разных типа пользователей? (Работаю на ZF второй месяц %-]).
Пока думаю что в сессии Zend_Auth хранить ключ `is_admin` или что-то подобное.
совместное использование с PHPDoctrine (о том, как при использовании доктрины создать аналог Zend_Auth_Adapter_DbTable, чтоб не создавать новый конект для Zend_Db_Table, а использовать конект и классы доктрины): http://www.framework.zend.com/wiki/display/ZFPROP/Zend_Auth_Adapter_Doctrine_Table
Введение в Zend_Auth