Как стать автором
Обновить

Комментарии 37

И потом по мере увеличения числа разделов на сайте образуется большущий список из ->addRole… и $acl->add(new Zend_Acl_Resource(…
сам об этом задумываюсь, может Вы подскажете, как этого избежать?
Не подскажу. У самого такой на три экрана. :-)
А за ним немаленький список редиректов роутера, отличных от «/контроллер/экшн».
я с Acl ещё не разбирался… такой вопрос — а нельзя например разделы сайта держать в БД и потом строить список из ->addRole строить по выборке из БД?
можно, а еще лучше держать их в xml и использовать Zend_Config_Xml для работы с оным.
недостаток Zend_Config_Xml в том что он не понимает несколько элементов с одинаковым названием но с разными атрибутами и значениями.
А если роли и редиректы в базу понапихать? А потом посто кешированные данные из базы доставать и назначать всё это циклами?
Это, пожалуй, единственное решение проблемы, только еще нужно хранить таблицу связей «ресурс-роль».
Есть еще интересный момент, как вести эти базы, если контроллеры или действия добавляются часто и много?
в смысле как? Если они добавляются не каждые 2 секудны, то написать простенький интерфейс и добавлять\удалять\редактировать :)
Zend_Acl работает не так гибко как хотелось бы, по этому пишу свой контролер и добавляю его в хелпер, при это все права доступа держу в одном массиве который с помощью наследственности проверяет доступ.
В ini-файле этот список смотрится гораздо лаконичнее :)
Эм… А где вы используете Zend_Auth? Zend_Acl и Zend_Session то видно, а
if ($this->_request->isPost()) { Zend_Loader::loadClass('Zend_Filter_StripTags'); $f = new Zend_Filter_StripTags(); $username = $f->filter($this->_request->getPost('username')); $password = $f->filter($this->_request->getPost('password')); if (empty($username)) { $this->view->message = 'Please provide a username.'; } else { Zend_Loader::loadClass('Zend_Auth_Adapter_DbTable'); $dbAdapter = Zend_Registry::get('dbAdapter'); $authAdapter = new Zend_Auth_Adapter_DbTable($dbAdapter); $authAdapter->setTableName('users'); $authAdapter->setIdentityColumn('username'); $authAdapter->setCredentialColumn('password'); $authAdapter->setIdentity($username); $authAdapter->setCredential($password); $auth = Zend_Auth::getInstance(); $result = $auth->authenticate($authAdapter); if ($result->isValid()) { $data = $authAdapter->getResultRowObject(null, 'password'); $auth->getStorage()->write($data); $this->_redirect('/'); } else { $this->view->message = 'Login failed.'; } } }
И даже если не использовать таблицу, а другой метод хранения у вас юзеров
$auth = Zend_Auth::getInstance(); $auth->setStorage(new Zend_Auth_Storage_Session('someNamespace')); $result = $auth->authenticate($authAdapter);
Это все примеры авторизации, но именно так он работает, а не прямое присваивание в сессию :)
Хабр… Вот пример авторизации при использовании таблицы с юзерами (Zend_Auth)
if ($this->_request->isPost()) {
Zend_Loader:: loadClass('Zend_Filter_StripTags');
$f = new Zend_Filter_StripTags();
$username = $f->filter($this->_request->getPost('username'));
$password = $f->filter($this->_request->
getPost('password'));

if (empty($username)) {
$this->view->message = 'Please provide a username.';
} else {
Zend_Loader:: loadClass('Zend_Auth_Adapter_DbTable');
$dbAdapter = Zend_Registry:: get('dbAdapter');
$authAdapter = new Zend_Auth_Adapter_DbTable($dbAdapter);
$authAdapter->setTableName('users');
$authAdapter->setIdentityColumn('username');
$authAdapter->setCredentialColumn('password');

$authAdapter->setIdentity($username);
$authAdapter->setCredential($password);

$auth = Zend_Auth:: getInstance();
$result = $auth->authenticate($authAdapter);
if ($result->isValid()) {
// success: store database row to auth's storage
// system. (Not the password though!)
$data = $authAdapter->getResultRowObject(null, 'password');
$auth->getStorage()->write($data);
$this->_redirect('/');
} else {
$this->view->message = 'Login failed.';
}
}
}
по моему в шаге 2 так и написано. нет?:)
Вместо
header('Location: /error/error/');
я бы написал
$this->_redirect('/error/error/')
Это типа унаследованный метод от Zend_Controller_Action.
Как минимум postDispatch() не будет выполняться в таком случае, а значит уже какой-никакой, а прирост производительности :)
да, извините, в попыхых забыл совсем:)
исправил:)
> Решил сразу написать простенькую cms.
Велосипеды изобретаем?
ну а почему сразу велосипед?
у меня например есть своя простенькая цмс. и делая сайты на фриланс заказы — я делаю на своей. лично мне так проще. и кажется многим это проще.
человек пишет, что взялся за обучение. почему бы не начать с написания чего-либо привычного.
я фигею с кретинской фразы «изобретать велосипед».
«велосипед» — писать сайт на C.
Когда сайт пишется на таком популярном и очень простом средстве разработки. как PHP, да еще с фреймворком, это уже фактически очень простое решение.

П. С.
почему-то мне кажется, что про «велосипеды» упоминают в основном ленивые бездари. развей сомнения.
Ты перегибаешь палку. Для обучения обычно пишутся приложения не сложнее гостевой книги либо простейшего блога. Цмс — это уже выше уровень как мне кажется. И есть уже готовые решения, архитектуру которых можно поизучать в целях обучения.
По поводу ленивости. Лень — двигатель прогресса. Я достаточно хорошо и давно знаю PHP (ZCE). И почему-то именно программисты на этом языке стараются написать свой фреймворк, свою цмс, свой форум, а не взять готовые решения, а в дальнейшем и помочь в развитии проекта.
Хотя и конечно всё это субъективно.
для обучения советуют делать то, что вызывает интерес. если интересно писать цмс, но не интересно делать гостевую — пишут цмс. тебя никто не заставляет результат покупать или использовать. самые полезные знания PHP у меня сформировались при написании именно таких, более-менее сложных проектов. по началу все шло достаточно криво, но потом быстро понимаешь, что и так.
те, кто болтается на таком низком уровне, как «наскриптить гостевуху», такими знаниями не обладают.
Что касается лени. Мне на фиг не нужен Зенд Фреймворк. пусть его используют те люди, которым он удобен. я все пишу руками и счастлив.
Ты никогда не задумывался, почему появляются альтернативы? почему появился Зенд? потому что определенный разработчик на каком-то этапе понял, что ему нужен более удобный, заточекный под его потребности, инструмент. вот этот процесс обезьянами называется «изобретение велосипеда».
Та лень, о которой ты говоришь, ведет к деградации а не к прогрессу. сам-то ты сильно участвуешь в разработке этого фреймворка?
vzasos, следи за своим языком.

Обычно, когда люди переходят на оскорбления, означает, что у них не хватает ума дальше отстаивать свою позицию нормальными аргументами. Это к слову об обезьянах.

Пиши всё себе руками и дальше, за то время, как ты будешь стругать очередной велосипед, я на том же кейкпхп сделаю быстрее и качественее заказ и потрачу высвободившееся время более продуктивно.
В разработке этого фреймворка я не участвую, но я делал и посылал патчи к другим продуктам.
кроме того, что я отнес людей, постоянно упоминающих о «велосипедостроении», к которым ты, судя по всему, относишся, к обезьянам, других оскорблений не было, так что все хорошо ) извини и не обижайся.

перечитай предыдущий комментарий и постарайся его понять. то есть свою позицию я как бы нормально отстаиваю.

теперь вопрос: на основании чего ты вобще решил, что твои разработки во фреймворках будут лучше моих на простом PHP? читаешь мысли?

за патчи — молодец, что тут еще сказать.
По поводу разработок, я конечно не знаю твой уровень в том же PHP, возможно ты и гуру в нём. Но я сделал такой вывод на основании того, что популярные и активно развивающиеся опен сорс проекты, поддерживаемые целым сообществом разработчиков и тестеров, обычно оказываются на порядок мощнее и стабильнее самостоятельных разработок. И то время, которое придется тратить на реализацию каких-то базовых вещей, лучше потратить на проработку архитектуры и грамотную реализацию более специфичного функционала, имхо.
Да, и я не считаю свою позицию абсолютно верной в данном вопросе. Тем не менее, я считаю, что она более применима в реальной жизни.
применима не в реальной жизни, а применима на не очень больших и не очень специфических проектах, которые надо сделать быстро.
К сожалению, об оптимизации и производительности в том же кейке никто, похоже не думает… Вы смотрели, сколько запросов он делает при выполнении простейшего примера (нарпример, вывод списка статей)? И сколько запросов по идее достаточно для этой задачи? (должно быть 2 — опреджеление кол-ва записей и выборка нужных).

Мне до сих пор как в кошмарном сне вспоминаются бессмысленные запросы вроде DESC sometable

Грустно все это. Ни оформления нормального (кода), ни нового об авторизации и правах в ZF.
извините, писал новичок для новичков. уж как получилось
ну вообще не фонтан. Вопервых разширение конторллера для ограничения доступа плохая идея, используйте action plugin || action plugin кому как нравится. Во вторых логику решать в разширенном контроллере (я тут имею ввиду работу с сессией) тоже имхо не стоит, перенесите это в модель юзера и используйте в контроллере.

дефолтные роли описывайте либо в хелпере либо в плагине, а права определяйте в конкретном контроллере, не нужно этого кидать в предиспатч.
Авторизация вобщем-то довольно простая вещь в зенде, а вот АЦЛ интереснее.
1) Не стоит злоупотреблать наследованием.
В данном случае лучше использовать плагины и хелперы, они для это и сделаны.

Про Ацл можно почитать на девзоне.
devzone.zend.com/article/3509-Zend_Acl-and-MVC-Integration-Part-I-Basic-Use
devzone.zend.com/article/3510-Zend_Acl-and-MVC-Integration-Part-II-Advanced-Use

2) Как тут отмечали лучше его грузить от куда-нибудь, например из конфиг файла, бд и т.д. Для этого стоит написать некоторые классы загрузчиков, которые бы вытаскивали инфу (чтобы можно было легко перейти с файлов на бд или наоборот).
спасибо, подумаю над этим.
я только не понял смысл этого метода:
public function getUser() {
Zend_Session:: start();
$namespace = new Zend_Session_Namespace('Zend_Auth');

if($namespace->storage) {
$user['id'] = $namespace->storage->id;
$user['username'] = $namespace->storage->username;
$user['name'] = $namespace->storage->name;
$user['group'] = $namespace->storage->group;

return $user;
}

не проще ли было бы написать так:
public function getUser() {
Zend_Session:: start();
$namespace = new Zend_Session_Namespace('Zend_Auth');

if($namespace->storage) {
return $namespace->storage
}

Вам с массивами удобней работать, или таки был смысл в пользу массива готовому обьекту?
А так не прощели ещё?

public function getUser()
{
if(Zend_Auth:: getInstance()->hasIdentity())
{

}
}
Неплохой пример роботы с Zend_Acl даные о ролях? ресурсах и пользователях хранятся в БД.
Вместо вот этой прелести:
if($namespace->storage) {
$user['id'] = $namespace->storage->id;
$user['username'] = $namespace->storage->username;
$user['name'] = $namespace->storage->name;
$user['group'] = $namespace->storage->group;

return $user;
}
если погуглить (не говоря уже о том, чтобы в доках примеры разобрать), получится вполне ничего себе и в духе фреймворка

public function getUser()
{
$auth = Zend_Auth:: getInstance();
if($auth->hasIdentity())
{
$user = $auth->getIdentity();
}
else
{

}
}
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории