Комментарии 34
что-то мне кажется, что это то же самое, что писать гостевую книгу на объектах с использованием каких-нибудь крутых фреймворков типа CakePHP - ненужно и глупо...
или если мы пользуемся ZF, то авторизацию иначе как через Zend_Auth не провести? о_О
или если мы пользуемся ZF, то авторизацию иначе как через Zend_Auth не провести? о_О
как обычно получается в итоге - нагромоздили столько, что и на голову не налазит
никаких претензий к автору и переводчику, но такие вот примеры как раз и показывают, как излишне тяжёлым может быть ООП код в интерпретируемых языках.
из-за какой-то мелочи подгружается куча классов (для функций которых приходится выделять память), и непонятно, в чём выигрыш собственно?
никаких претензий к автору и переводчику, но такие вот примеры как раз и показывают, как излишне тяжёлым может быть ООП код в интерпретируемых языках.
из-за какой-то мелочи подгружается куча классов (для функций которых приходится выделять память), и непонятно, в чём выигрыш собственно?
А как еще можно на примерах разобрать подобный фреймворк-тяжеловес? Не писать же статью "Создаем социальную полный аналог Хабра на Zend Framework"
Именно ZF и помогает не писать каждый раз одно и то же с кучами проверок и фильтров. Первый раз как увидел ZF_Auth, тоже решил. что наворочено и не нужно. А когда попробовал в деле - все оказалось быстро, ясно и приятно. Вот вам и выигрыш.
ZF это комплекс компонент, которые в сумме облегчают разарботку сайта. Не совсем правильно оценивать и гнобить данный фреймворк по конкретному примеру.
Поддержу den_rad, статья предназначена в первую очередь для знакомства с данным классом.
Сейчас потихоньку начинаем использовать ZF. Но используем в первую очередь ядро, контроллеры и настройки ... все остальное самописное легко интегрируем с системой. Но постепенно будем переходить полностью на средства ZF, имхо, так будет более правильно для организации проектов на ZF. Тем более что идет слух, что поддержка ZF может появится в самом php.
Поддержу den_rad, статья предназначена в первую очередь для знакомства с данным классом.
Сейчас потихоньку начинаем использовать ZF. Но используем в первую очередь ядро, контроллеры и настройки ... все остальное самописное легко интегрируем с системой. Но постепенно будем переходить полностью на средства ZF, имхо, так будет более правильно для организации проектов на ZF. Тем более что идет слух, что поддержка ZF может появится в самом php.
ZF мне понравился как раз тем, что в нем предусмотрено все, что необходимо и при этом сохранена гибкость благодаря грамотной ОО-реализации. Zend_Auth на учебном примере действительно смотрится как реактивный двигатель на велосипеде, но не нужно забывать, что это не реальная задача, а просто иллюстрация. В ней основное внимание уделено не прикладному предназначению программного продукта, а технологии его реализации. Чтобы можно было вникнуть в эту технологию, не отвлекаясь на предметную область какого-то частного случая. Факт, что ZF расчитан на программы более высокого уровня сложности, чем приведенная в примере. Несложные и автономно-работающие скрипты (мэйл-форма, например, или минимальная по функциям книга гостевая) не слишком выйграет от его применения.
Но я по своему опыту могу сказать, что все проиллюстрированный здесь и оставшиеся за кадром фичи на реальных задачах найдут свое применение. А благодаря тому, что фреймворк развивается как единое целое, а не набор отдельных компонент, это здорово облегчит задачу сохранения грамотной (и унифицированной) структуры приложения на его основе.
Очень приятно читать документацию и находить в ней довольно толковые решения многих задач, аналоги которых относительно недавно писал сам :)
Но я по своему опыту могу сказать, что все проиллюстрированный здесь и оставшиеся за кадром фичи на реальных задачах найдут свое применение. А благодаря тому, что фреймворк развивается как единое целое, а не набор отдельных компонент, это здорово облегчит задачу сохранения грамотной (и унифицированной) структуры приложения на его основе.
Очень приятно читать документацию и находить в ней довольно толковые решения многих задач, аналоги которых относительно недавно писал сам :)
Хорошо в таких статьях класть в прицеп архив с рабочим примером.
Архив есть на сайте автора. Я хотел дать на него ссылку, но просто забыл :)
http://akrabat.com/wp-content/uploads/ze…
http://akrabat.com/wp-content/uploads/ze…
После беглого просмотра этой и предшествующей статьей окончательно пропадает желание ближе знакомиться как с этим фрэймвоком в частности так и с самим PHP.
Спасибо!
Спасибо!
Хм, выражаете благодарность и ставите отрицительный балл статье. Интересный вы человек.
P.S. Чем конкретно вас неустроили как PHP в общем и целом, так и конкретные framework'и в частности?
P.S. Чем конкретно вас неустроили как PHP в общем и целом, так и конкретные framework'и в частности?
Боюсь не совсем корректно выразился. Отрицательный бал статье я не ставил, наооборот, я благодарен автору, за сэкономленное время. В качестве фрэймворка для изучения я для себя уже выбрал джанго(www.djangoproject.com), в котором,к слову, та же система авторизации - стандартный плагин. Но нет нет да и посматриваю не ошибся ли в выборе, не появилось ли чего лучшего, как схожие задачи решаются в других фрэймвоках. И как раз просматривая такие обзоры с примерами и убеждаюсь насколько правильно я сделал свой выбор) По ПХП - это моё частное неофициально ощущение (надеюсь имею на него право?) Обосновывал я его тут:
http://recoilme.livejournal.com/1797.html
http://recoilme.livejournal.com/1797.html
Имеете, никто у вас его и не отнимает ;).
Я сам давно присматриваюсь в Django, да вот только руки никак не дойдут... Я бы посоветовал вам посмотреть на Symfony. Этот framework из той же серии, что и Django (Ruby on Rails). Возможно в нем вы найдете для себя что-нибудь интересное.
Я сам давно присматриваюсь в Django, да вот только руки никак не дойдут... Я бы посоветовал вам посмотреть на Symfony. Этот framework из той же серии, что и Django (Ruby on Rails). Возможно в нем вы найдете для себя что-нибудь интересное.
Спасибо за статью. Почему-то на framework.zend.com не было перевода этого компонента, хотя тема очень нужная.
Давно думал как переделать свой тяп-ляп движок, и вот под руку попался Zend FW, классная штука уже начал думать как на основание его создать новый двигатель, огромное спасибо автору перевода, буду рад видеть продолжение!
НЛО прилетело и опубликовало эту надпись здесь
Как я понял, в данном примере авторизационная информация храниться в течении сессии, то есть пока броузер не закрыт. А что надо делать, что бы запомнить пользователя на какое-то время? Есть соответствующие механизмы в Zend_Auth, или надо руками делать?
Если речь идёт о таймауте сессии - это делается через стандартные настройки РНР. Если же нужна ситуация, когда надо закрыть сессию юзера по истечению какого-то времени (довольно странная ситуация) - это можно легко добавить в preDispatch() контроллера, который будет проверять когда юзер залогинился (это время придется сохранить в сессии) и не пора ли его разлогинить.
Вот интересно какие есть плюсы у zend framework по отношению к symfony?
Кто-нибудь использовал один и другой framework в работе?
Symfony уже года 2 как из бэтты вышел, а zend framework из бэтты вышел буквально месяц назад.
Мне в symfony очень понравился генератор CRUD-приложений - это сильно экономит время. Есть такой в zend framework?
Кто-нибудь использовал один и другой framework в работе?
Symfony уже года 2 как из бэтты вышел, а zend framework из бэтты вышел буквально месяц назад.
Мне в symfony очень понравился генератор CRUD-приложений - это сильно экономит время. Есть такой в zend framework?
Не совсем по теме, но довольно важный нюанс: поле для хранения пароля в MySQL нужно создавать как VARCHAR BINARY, а не просто VARCHAR. Иначе пароль получается case insensitive, и стойкость пароля падает на порядок.
Хранить нужно хеш пароля, потому что:
1. зачем вам знать пароль пользователя, может у него на почте такой же
2. кто-нибудь может спереть базу
3. база кроме вас доступна еще и хостеру
Хеш нужно сделать понадежней, желательно нестандартным алгоритмом, иначе пароли пожно подобрать перебором (не обязательно совсем новый алгоритм, можно просто чуть поменять результат стандартного).
В случае хранения хеша необходимость BINARY отпадает.
1. зачем вам знать пароль пользователя, может у него на почте такой же
2. кто-нибудь может спереть базу
3. база кроме вас доступна еще и хостеру
Хеш нужно сделать понадежней, желательно нестандартным алгоритмом, иначе пароли пожно подобрать перебором (не обязательно совсем новый алгоритм, можно просто чуть поменять результат стандартного).
В случае хранения хеша необходимость BINARY отпадает.
Всё верно. Только если в базе хеш, то и поле обычно называют не password, а pass_md5 или pass_hash, etc.
Вариант pass_md5 мне совсем не нравиться, особенно если храниться действительно md5, это же подсказка злоумышленнику, а вот pass_hash гораздо лучше, нужно внедрить в свою практику, спасиб.
Security through obscurity - это не очень хорошая идея, особенно если без неё можно обойтись. И уж точно на неё нельзя полагаться как на один из основных механизмов обеспечения безопасности.
Так что пытаться скрывать алгоритм хеширования смысла мало. Все основные виды хешей обычно визуально определяются, и названием поля алгорим не скроешь. Что касается изменения результата стандартного алгоритма ручками, то обычно это тоже не спасает: дело в том, что в большинстве случаев когда хакер получает доступ к базе, он так же получает и возможность как минимум читать файлы на сервере, в том числе и файл с кодом вычисления и изменения хеша пароля.
Используйте стойкие алгоритмы хеширования, плюс проверяйте пароль за стойкость (либо перед хешированием, и отказывайтесь принимать от юзера слабые пароли, либо после хеширования - запустив john и требуя чтобы юзеры меняли пароли, которые john смог быстро подобрать).
Так что пытаться скрывать алгоритм хеширования смысла мало. Все основные виды хешей обычно визуально определяются, и названием поля алгорим не скроешь. Что касается изменения результата стандартного алгоритма ручками, то обычно это тоже не спасает: дело в том, что в большинстве случаев когда хакер получает доступ к базе, он так же получает и возможность как минимум читать файлы на сервере, в том числе и файл с кодом вычисления и изменения хеша пароля.
Используйте стойкие алгоритмы хеширования, плюс проверяйте пароль за стойкость (либо перед хешированием, и отказывайтесь принимать от юзера слабые пароли, либо после хеширования - запустив john и требуя чтобы юзеры меняли пароли, которые john смог быстро подобрать).
Спасибо огромное за статью, особенно за ПДФ. Очень удобно распечатывать по 8 страниц на А4 никаких лишних бумажек =)
Вот я разбираюсь сейчас с мануалом фреймворка. До этого я такими вещами не занимался =)
Возник вопрос.
Zend_Auth основывается на Zend_Session или нет. Всмысле пригодится ли мне Zend_Session при использовании Zend_Auth или о нём можно забыть?
Если вопрос глупый, то прошу прощения.
Вот я разбираюсь сейчас с мануалом фреймворка. До этого я такими вещами не занимался =)
Возник вопрос.
Zend_Auth основывается на Zend_Session или нет. Всмысле пригодится ли мне Zend_Session при использовании Zend_Auth или о нём можно забыть?
Если вопрос глупый, то прошу прощения.
Zend_Auth по-умолчанию использует PHP сессии для хранения авторизационных данных. Т.е. его можно использовать совместно с Zend_Session, но не обязательно. Подробности здесь: http://framework.zend.com/manual/ru/zend…
Кстати во вложенном архиве и в описании замечена ошибка
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()
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
идея хорошая. есть ли где-то готовое решение?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в Zend_Auth