Zend Auth y ACL

Question

Espero que algunos me ayuden un poco, actualmente estoy desarrollando mi primer sitio usando un framework PHP, parte del sitio se derrama en un área de miembros, aquí es donde mi confusión comienza a emerger, Dentro del área de miembros quiero que los miembros normales puedan agregar nuevos comentarios y editar sus propios comentarios, lo suficientemente simple como para que pueda verificar el nombre de los carteles con el nombre de usuario que está almacenado en la sesión, mi confusión viene con diferenciar entre lo 'normal Los usuarios y los usuarios de nivel superior que tienen la capacidad de eliminar y modificar los comentarios, etc., también deben poder acceder a la sección de administración del sitio.

Mi pregunta es: ¿todos los usuarios deben iniciar sesión a través del mismo controlador Zend_Auth, o deben existir controladores separados que usan Zend_Auth para cada tipo de usuario o se puede tratar todo eso con Zend_Acl? Cualquier ayuda, consejo, artículo o tutorial sería muy apreciado. Personalmente, creo que la documentación de Zend es un poco cruda en algunas clases.

Gracias de antemano

sico87

Answer 1

Sí, en la mayoría de los casos la totalidad de su autenticación deben pasar por el mismo controlador. Sin embargo, Zend Auth no es un tipo de controlador. Zend Auth es una API para utilizar métodos de autenticación comunes, como una base de datos o http. Su trabajo es realmente ser una envoltura alrededor del arduo trabajo de escribir código de autenticación.

Zend Acl es lo que está buscando para distinguir entre usuarios normales y usuarios privilegiados. Solo involucra a Zend Acl después de que los usuarios se hayan autenticado e iniciado sesión.

La mayor parte de lo que necesita se encuentra en la documentación de ZF. Leí casi toda la documentación de Auth y Acl antes de que tuviera mucho sentido para mí. Aunque Auth, ACL, Storage_ * de ZF y otras clases se usan muy juntas, todas tienen propósitos muy distintos. Con un poco de tiempo verás que se complementan muy bien.

Un par de enlaces para que pueda empezar:

Pádraic Brady's ZF Tutorial

Zend's DevZone article on ACL and MVC

Answer 2

recomiendo el libro "Zend Framework en Acción" de Manning Publicaciones como un gran, hasta a la fecha, introducción a esto. Está disponible como descarga en PDF, por lo que puede tener ahora :)

Pero para responder a esta pregunta en particular:

Vamos a empezar por definir dos términos clave. La "Auth" en Zend_Auth se refiere a la Autenticación, que prueba que alguien es quien dice ser (es decir, iniciar sesión). La "A" en Zend_Acl se refiere a la Autorización, que prueba que alguien tiene el derecho de hacer lo que está tratando de hacer (es decir, control de acceso).

Suponiendo que el usuario tiene un solo rol ... Almacene las funciones del usuario en la "identidad" que obtiene como parte de Zend_Auth. En entrada:

$auth = Zend_Auth::getInstance(); 
$identity = new stdClass(); 
$identity->user_pk = $user->getPrimaryKey(); 
$identity->user_name = $user->getName(); 
$identity->role = $user->getRole(); // select * from user_role where user_pk=xxx 
$auth->getStorage()->write($identity); 

En Controlador:

$acl->add(new Zend_Acl_Resource('news')) 
->allow('defaultRole', 'news'); 

Todo es negada por defecto, así que realmente no necesita especificar:

->deny('defaultRole', 'news', 'add'); 

Más adelante en el código del controlador :

$identity = Zend_Auth::getInstance()->getIdentity(); 
if(!$acl->isAllowed($identity->role, 'news', 'add')) 
{ 
    header('Location: http://www.yoursite.com/error/unauthorized'); 
} 

Si la identidad del usuario no puede hacer "news-> add", los redireccionará a la página no autorizada (suponiendo que haya creado dicha página).

Si el usuario tuviera> 1 rol, almacenaría una matriz de roles en su identidad. Entonces su cheque sería algo como esto:

$identity = Zend_Auth::getInstance()->getIdentity(); 
$isAllowed = false; 
foreach($identity->role as $role) 
{ 
    if($acl->isAllowed($role, 'news', 'add')) 
    { 
     $isAllowed = true; 
    } 
} 
if(!$isAllowed) 
{ // if NO ROLES have access, redirect to unauthorized page 
    header('Location: http://www.yoursite.com/error/unauthorized'); 
} 

Espero que ayude.

Answer 3

Entiendo por qué te confundes. Estaba/todavía estoy un poco confundido. Por lo tanto, desafortunadamente no puedo responder su pregunta directamente. Pero, una cosa que estoy haciendo para aclarar todo esto en mi cabeza es pensar en términos de 'objetos de dominio' en oposición a los registros de la base de datos.

Mi táctica para resolver este problema es crear mi propio Auth Adapter al que se le pasa un 'Usuario Base Object' junto con las credenciales del usuario. Mi 'Base de usuario' es como un repositorio de usuarios.

De modo que Zend Auth queda como 'una interfaz' para otros componentes Zend mientras que todavía tengo un poco más de control sobre mi sistema para almacenar y acceder a 'Usuarios'. Mi clase User_Base podría ser un contenedor alrededor de un Zend Db tbl o incluso solo tener algún código difícil que pueda usar para las pruebas.

Así en general-

• diseñar su propio modelo de un 'usuario'

• diseñar su propio adaptador de Auth - comenzando con la interfaz mínima requerida como se indica aquí: http://framework.zend.com/manual/en/zend.auth.html

• y simplemente mantén todo simple e ir despacio a medida que aprendes más sobre él.

bueno eso es lo que voy a hacer de todos modos.

Ni siquiera voy a molestarme con Zend ACL hasta que tenga Auth claro en mi cabeza.

---

estoy renovando un sitio de memoria y su conversión a Zend MVC

Estas son algunas cosas (quizá no convencionales) que he tenido que llegar a enfrentarse con mi 'modelo' para trabajar.:

• una aplicación puede ser utilizada por los usuarios de múltiples 'bases de usuarios' - openID, legado tabla de usuarios, la nueva tabla de usuarios, clientes fugaces, etc
• la identidad de un cliente podría ser un hash creado cuando por primera vez llegar
• mientras que la identidad de un usuario heredado puede estar representada por una identificación en la tabla de usuarios heredados
• usuarios y user_accounts son cosas separadas. no intente mezclarlos en un solo concepto porque podría complicarse.
• puede haber muchos tipos diferentes de cuentas en el sistema. Es decir. Cuentas de compradores versus cuentas de vendedores. Readers_Account frente Writers_Account
• cuentas 'tiene' usuarios - 'soporte principal a la cuenta', 'admin superusuario', etc
• la relación entre los usuarios y una cuenta están representados por, digamos, 'account_users' (un subconjunto local de la todos los usuarios en todas las bases de usuarios)
• roles arew asociados a account_users (los usuarios de esa cuenta en particular). (A diferencia de los roles que flotan)
• no temas tener más de una aplicación Zend en un servidor para representar un sitio web, por ejemplo, aplicación de administrador, aplicación de miembros, aplicación de front-end.
• no temas permitir que estas aplicaciones usen objetos modelo almacenados en la carpeta 'modelos compartidos', con el único código modelo que se relaciona directamente con la aplicación individual ubicada en las carpetas/application/models/foomodel.
• cada aplicación puede tener su propia costumbre adaptador de autenticación
• un adaptador de autenticación de administrador sólo podrá permitir a los usuarios de la 'tabla de usuarios admin' mientras que el adaptador de autenticación de una aplicación front-end podría ser capaz de autenticar a los usuarios de la base de usuarios invitados, el personal, o miembros de la base de usuarios.
• podría ser un caso vales para sesión en sesión de aplicaciones front-end se borra y replced por sesión de miembro de la elevación cuando los registros miembros en.
• un objeto usuario por aplicación por webclient en el momento nadie (en contraposición a tratar de hacer referencia a una persona con un usuario invitado Y un usuario miembro, eso es demasiado complicado)
• una sesión por usuario por aplicación (espacio de nombres para evitar conflictos con otras aplicaciones en las que pueden haber iniciado sesión en ese dominio) - (en lugar de tratar de referirse simultáneamente a 'la persona que lo usa' con una sesión de invitado Y una sesión de miembro. De nuevo, eso es muy complicado)

ok estoy empezando a divagar .... pero entiendes la idea. No permita que los tutoriales de Zend_Auth + Zend Db que vea influyan en su propio modelo. son solo ejemplos simplificados.

nuff dijo

Answer 4

Tengo algunas preguntas sobre esta pieza de código

$auth = Zend_Auth::getInstance(); 
    $identity = new stdClass(); 
    $identity->user_pk = $user->getPrimaryKey(); 
    $identity->user_name = $user->getName(); 
    $identity->role = $user->getRole(); // select * from user_role where user_pk=xxx 
    $auth->getStorage()->write($identity); 

    $identity = Zend_Auth::getInstance()->getIdentity(); 

Están user_pk, nombre_usuario y el papel almacenan como galletas? ¿Alguien que hace una cookie con el nombre de rol puede acceder a las partes aseguradas de los sitios web? ¿No debería una contraseña (con md5-encryption) ser parte de la identificación así que cuándo puede verificar el nombre de usuario y la contraseña con cada solicitud?