Pull to refresh

Comments 34

что-то мне кажется, что это то же самое, что писать гостевую книгу на объектах с использованием каких-нибудь крутых фреймворков типа CakePHP - ненужно и глупо...
или если мы пользуемся ZF, то авторизацию иначе как через Zend_Auth не провести? о_О
Вот в том числе и из-за людей с Вашей точкой зрения иногда приходиться плеваться от взгляда на код.
не стоит говорить раньше времени :)
и фраз на ветер пускать тоже
Смысл статьи - не доказать, как сделать авторизацию лучше всего в мире, а как это сделать с применением ZF. По-моему, все достаточно понятно.
как обычно получается в итоге - нагромоздили столько, что и на голову не налазит

никаких претензий к автору и переводчику, но такие вот примеры как раз и показывают, как излишне тяжёлым может быть ООП код в интерпретируемых языках.

из-за какой-то мелочи подгружается куча классов (для функций которых приходится выделять память), и непонятно, в чём выигрыш собственно?
А как еще можно на примерах разобрать подобный фреймворк-тяжеловес? Не писать же статью "Создаем социальную полный аналог Хабра на Zend Framework"
Именно ZF и помогает не писать каждый раз одно и то же с кучами проверок и фильтров. Первый раз как увидел ZF_Auth, тоже решил. что наворочено и не нужно. А когда попробовал в деле - все оказалось быстро, ясно и приятно. Вот вам и выигрыш.
ZF это комплекс компонент, которые в сумме облегчают разарботку сайта. Не совсем правильно оценивать и гнобить данный фреймворк по конкретному примеру.

Поддержу den_rad, статья предназначена в первую очередь для знакомства с данным классом.

Сейчас потихоньку начинаем использовать ZF. Но используем в первую очередь ядро, контроллеры и настройки ... все остальное самописное легко интегрируем с системой. Но постепенно будем переходить полностью на средства ZF, имхо, так будет более правильно для организации проектов на ZF. Тем более что идет слух, что поддержка ZF может появится в самом php.
ZF мне понравился как раз тем, что в нем предусмотрено все, что необходимо и при этом сохранена гибкость благодаря грамотной ОО-реализации. Zend_Auth на учебном примере действительно смотрится как реактивный двигатель на велосипеде, но не нужно забывать, что это не реальная задача, а просто иллюстрация. В ней основное внимание уделено не прикладному предназначению программного продукта, а технологии его реализации. Чтобы можно было вникнуть в эту технологию, не отвлекаясь на предметную область какого-то частного случая. Факт, что ZF расчитан на программы более высокого уровня сложности, чем приведенная в примере. Несложные и автономно-работающие скрипты (мэйл-форма, например, или минимальная по функциям книга гостевая) не слишком выйграет от его применения.
Но я по своему опыту могу сказать, что все проиллюстрированный здесь и оставшиеся за кадром фичи на реальных задачах найдут свое применение. А благодаря тому, что фреймворк развивается как единое целое, а не набор отдельных компонент, это здорово облегчит задачу сохранения грамотной (и унифицированной) структуры приложения на его основе.

Очень приятно читать документацию и находить в ней довольно толковые решения многих задач, аналоги которых относительно недавно писал сам :)
Хорошо в таких статьях класть в прицеп архив с рабочим примером.
После беглого просмотра этой и предшествующей статьей окончательно пропадает желание ближе знакомиться как с этим фрэймвоком в частности так и с самим PHP.
Спасибо!
Хм, выражаете благодарность и ставите отрицительный балл статье. Интересный вы человек.

P.S. Чем конкретно вас неустроили как PHP в общем и целом, так и конкретные framework'и в частности?
Боюсь не совсем корректно выразился. Отрицательный бал статье я не ставил, наооборот, я благодарен автору, за сэкономленное время. В качестве фрэймворка для изучения я для себя уже выбрал джанго(www.djangoproject.com), в котором,к слову, та же система авторизации - стандартный плагин. Но нет нет да и посматриваю не ошибся ли в выборе, не появилось ли чего лучшего, как схожие задачи решаются в других фрэймвоках. И как раз просматривая такие обзоры с примерами и убеждаюсь насколько правильно я сделал свой выбор) По ПХП - это моё частное неофициально ощущение (надеюсь имею на него право?) Обосновывал я его тут:
http://recoilme.livejournal.com/1797.html
Имеете, никто у вас его и не отнимает ;).

Я сам давно присматриваюсь в Django, да вот только руки никак не дойдут... Я бы посоветовал вам посмотреть на Symfony. Этот framework из той же серии, что и Django (Ruby on Rails). Возможно в нем вы найдете для себя что-нибудь интересное.
Спасибо за статью. Почему-то на framework.zend.com не было перевода этого компонента, хотя тема очень нужная.
Давно думал как переделать свой тяп-ляп движок, и вот под руку попался Zend FW, классная штука уже начал думать как на основание его создать новый двигатель, огромное спасибо автору перевода, буду рад видеть продолжение!
UFO just landed and posted this here
Как я понял, в данном примере авторизационная информация храниться в течении сессии, то есть пока броузер не закрыт. А что надо делать, что бы запомнить пользователя на какое-то время? Есть соответствующие механизмы в Zend_Auth, или надо руками делать?
Если речь идёт о таймауте сессии - это делается через стандартные настройки РНР. Если же нужна ситуация, когда надо закрыть сессию юзера по истечению какого-то времени (довольно странная ситуация) - это можно легко добавить в preDispatch() контроллера, который будет проверять когда юзер залогинился (это время придется сохранить в сессии) и не пора ли его разлогинить.
Вот интересно какие есть плюсы у zend framework по отношению к symfony?
Кто-нибудь использовал один и другой framework в работе?
Symfony уже года 2 как из бэтты вышел, а zend framework из бэтты вышел буквально месяц назад.
Мне в symfony очень понравился генератор CRUD-приложений - это сильно экономит время. Есть такой в zend framework?
UFO just landed and posted this here
Не совсем по теме, но довольно важный нюанс: поле для хранения пароля в MySQL нужно создавать как VARCHAR BINARY, а не просто VARCHAR. Иначе пароль получается case insensitive, и стойкость пароля падает на порядок.
Хранить нужно хеш пароля, потому что:
1. зачем вам знать пароль пользователя, может у него на почте такой же
2. кто-нибудь может спереть базу
3. база кроме вас доступна еще и хостеру
Хеш нужно сделать понадежней, желательно нестандартным алгоритмом, иначе пароли пожно подобрать перебором (не обязательно совсем новый алгоритм, можно просто чуть поменять результат стандартного).

В случае хранения хеша необходимость BINARY отпадает.
Всё верно. Только если в базе хеш, то и поле обычно называют не password, а pass_md5 или pass_hash, etc.
Вариант pass_md5 мне совсем не нравиться, особенно если храниться действительно md5, это же подсказка злоумышленнику, а вот pass_hash гораздо лучше, нужно внедрить в свою практику, спасиб.
Security through obscurity - это не очень хорошая идея, особенно если без неё можно обойтись. И уж точно на неё нельзя полагаться как на один из основных механизмов обеспечения безопасности.

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

Используйте стойкие алгоритмы хеширования, плюс проверяйте пароль за стойкость (либо перед хешированием, и отказывайтесь принимать от юзера слабые пароли, либо после хеширования - запустив john и требуя чтобы юзеры меняли пароли, которые john смог быстро подобрать).
Спасибо огромное за статью, особенно за ПДФ. Очень удобно распечатывать по 8 страниц на А4 никаких лишних бумажек =)

Вот я разбираюсь сейчас с мануалом фреймворка. До этого я такими вещами не занимался =)

Возник вопрос.

Zend_Auth основывается на Zend_Session или нет. Всмысле пригодится ли мне Zend_Session при использовании Zend_Auth или о нём можно забыть?

Если вопрос глупый, то прошу прощения.
Zend_Auth по-умолчанию использует PHP сессии для хранения авторизационных данных. Т.е. его можно использовать совместно с Zend_Session, но не обязательно. Подробности здесь: http://framework.zend.com/manual/ru/zend…
Если у меня есть административная часть сайта (CMS), и система авторизации на сайте (назовем "личный кабинет") — как Zend_Auth будет различать два разных типа пользователей? (Работаю на ZF второй месяц %-]).

Пока думаю что в сессии Zend_Auth хранить ключ `is_admin` или что-то подобное.
Здесь стоит вопрос о разграничении прав доступа к ресурсам. Резонно будет использовать класс, реализующий список прав доступа Zend_Acl.
Кстати во вложенном архиве и в описании замечена ошибка
zf-tutorial/index.php:
...
$dbAdapter = Zend_Db::factory($config->db->adapter,
$config->db->config->asArray());
...

Fatal error: Call to undefined method Zend_Config::asArray() in C:\Apache2.2\htdocs\zf.auth2\index.php on line 26

Рецепт лечения
$config->db->config->asArray()
заменить на
$config->db->config->toArray()
совместное использование с PHPDoctrine (о том, как при использовании доктрины создать аналог Zend_Auth_Adapter_DbTable, чтоб не создавать новый конект для Zend_Db_Table, а использовать конект и классы доктрины): http://www.framework.zend.com/wiki/display/ZFPROP/Zend_Auth_Adapter_Doctrine_Table
идея хорошая. есть ли где-то готовое решение?
Sign up to leave a comment.

Articles