Zend FR
Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
#1 12-06-2009 10:52:28
Gestion des droits au cas par cas.
Bonjour,
Je suis en train de développer l'intranet de ma boite et je vais avoir une gestion des droits a mettre en place.
Après discutions je me rends compte qu'il ne sera pas possible de gerer les ACL avec une notion de groupe. Il y aura toujours un cas particulier à gérer !
Je suis encore en train de regarder comment faire mais je ne cracherais pas sur un petit retour d'expérience ou quelques idées 
Dois-je utiliser les ACL de Zend en éclipsant la notion de groupe ?
Développer mon propre test ?
Je pensais associer a chaque compte utilisateur un tableau associatif un peu comme suit :
Code:
[user_droits] => Array
(
[actions] => Array
(
[entite] => Array
(
[index] => Array
(
[0] => liste
[1] => formulaire
[2] => enregistrer
[4] => modifier
[5] => effacer
[6] => restaurer
)
)
[utilisateur] => Array
(
[index] => Array
(
[0] => liste
[1] => formulaire
[2] => enregistrer
[4] => modifier
[5] => effacer
[6] => restaurer
)
)
)
)Et un plugin qui test si l'action est authorisée...
du genre :
Code:
<?php
class Acl extends Zend_Controller_Plugin_Abstract {
public function preDispatch (Zend_Controller_Request_Abstract $request) {
$module = $request->getModuleName();
$controller = $request->getControllerName();
$action = $request->getActionName();
$session = new Zend_Session_Namespace(NOM_SESSION);
$droitsUser = $session -> Utilisateur['user_droits'];
$aDroit = false;
if ( in_array( $action, $droitsUser['actions'][$module][$controller] ) ) {
$aDroit = true;
}
//--> Page d'erreur
if ( !$aDroit ) {
$request->setModuleName("default") ;
$request->setControllerName("error") ;
$request->setActionName("action-interdite") ;
}
}
}Qu'en pensez-vous ?
Merci pour vos réponses.
Cordialement,
Kaimite
Hors ligne
#2 19-07-2009 18:49:59
Re: Gestion des droits au cas par cas.
je suis un peu dans le meme cas : je suis entrain d'ecrire une application basée sur le Zf , après avoir réussi une authentification assez facilement , je me retrouve face a un cas de gestion de droits assez spécifique :
Mon application est modulaire mais chaque module contient des sous modules
Code:
module1
|
->sous module 1.1
->sous module 1.2
...
->sous module 1.n
module2
|
->sous module 2.1
->sous module 2.2
...
->sous module 2.nA cette modularité s'ajoutent des rôles bien spécifiques, mais on aura des exceptions aux groupes , pour tel ou tel utilisateur
Code:
groupe1
|
->utilisateur 1
->utilisateur 2
...
->utilisateur n
groupe2
|
->utilisateur 1
->utilisateur 3
...
->utilisateur npar exemple dans ce cas , l' utilisateur 3 pourrait avoir un droit d'accès spécifique a un module(voire meme un seul sous module), sans que son groupe y ait droit. Ce droit devra donc se cumuler avec ceux du groupe...(Droit liés au groupe + droits liés a l'utilisateur en cours)
Dans ce cas précis , je ne comprends pas trop comment bien architecturer mes ACLs , et je me pose même la question de l'utilité des ACLs dans ce cas précis, sachant qu'a terme , on aura une très grande quantité de droits différents...
Ne serait t'il pas plus judicieux de créer mon systeme totalement ?? (Malgré le fait que je pense que cette fcon de faire soit contraire a l'idée même du framework... 
J'aimerais beaucoup avoir des retours d'expérience sur vos utilisations des ACLs... parce que la , ca coince un peu dans ma petite tete de débutant... 
Hors ligne
#4 20-07-2009 13:56:47
Re: Gestion des droits au cas par cas.
yannux a écrit:
Si on pense aux droits unix par exemple, un utilisateur à (par défaut) un groupe qui porte le même nom que lui...
Ca peut être une solution
donc on pourrait avoir des groupes a la base , et créer un nouveau groupe si on doit créer un utilisateur avec des droits spécifiques... Effectivement , ca peut etre une solution...
Si quelqu'un a d'autres idées , je les prends quand même , histoire de voir les différentes facons d'aborder cette problématique.
En tous cas , merci de ton aide 
Hors ligne
#6 14-08-2009 10:14:38
Re: Gestion des droits au cas par cas.
Salut,
De mon coté et après discussion je pense partir sur un double principe...
Mélanger une notion de profil et de droits spécifique en même temps.
Par exemple je défini :
un groupe "RH" qui peut accéder aux congés payés, annuaire, etc.
un groupe "Vendeur" qui peut accéder a la gestion du stock, des promos etc.
...
Lors de la création de la fiche d'une personne je lui attribut un groupe pour la gestion de ses droits. Je vais également pouvoir lui donner, ou retirer, des droits spécifiques.
Par exemple M. Martin est vendeur MAIS ne doit pas pouvoir accéder aux promos (ne me demander pas pkoi !)
Au moment ou il arrive sur la page on teste avec les ACL standard si le groupe "vendeur" peur accéder à la ressource "promos" s'il a le droit je test dans ses droits spécifiques (voir mon 1er post) s'il n'a pas d'interdiction sur cette ressource.
Cette solution oblige une double vérification (groupe + droits spécifiques) mais lors la création d'une fiche sera plus simple car au final il y aura peut de gens avec des droits spécifiques. En discutant on s'est rendu compte que c'était con de tout gérer comme des cas particulier alors qu'au final la plupart des utilisateurs resteront dans le groupe sans avoir besoin de droits "étendus"...
De plus lors de l'ajout d'un nouveau module il sera plus simple de l'intégrer dans les ACL d'un groupe que d'aller modifier la fiche de chaque utilisateur pour lui attribuer les droits sur ce nouveau module...
Le principe a été adopté.... il ne reste plus qu'a le développer
Voilà, je ne sais pas pas ça peut vous aider...
Cordialement,
Kaimite
Hors ligne
#7 14-08-2009 10:51:58
Re: Gestion des droits au cas par cas.
Les ACL en eux même n'utilisent pas de groupe. C'est un effet de bord de la doc Zend ou autre.
Les ACL utilisent des rôles, des ressources et des privilèges. Les rôles ici peuvent être "guest", "member" et "admin" ou encore "RH". Mais un groupe peut également être "Keilnoth" et "Kaimite". Le tout étant de passer à Zend_Auth un tableau de privileges valide.
Il est, à mon avis, assez facile de définir un ou plusieurs rôles à un utilisateur et ensuite de permettre la personnalisation de ses privileges dans un deuxième "tableau". Les deux tableaux ayant chacun une priorité sur l'autre (le tableau personnel est plus fort) et écrase les définitions du premier.
En gros, le plugin qui détecte et transmet les privilèges à Zend_Auth fera une sorte de "array_intersect" si l'utilisateur a des rôles personnalisés.
Je crois que c'est la solution retenue et que j'ai pas vraiment fait avancer le débat.
Quelques tutoriaux Zend Framework !
Hors ligne
#8 14-08-2009 11:42:12
Re: Gestion des droits au cas par cas.
ouaips, c'est sûrement pas les bons termes... Mais c'était pour le principe d'utiliser les ACL de Zend (pour une gestion groupée) et une personnalisation.
Pour l'identification je n'utilise pas Zend_Auth car je n'ai pas trouvé comment prendre en compte les notions de dates de validité d'un compte ou autre. En général j'ai plus de contraintes qu'un simple login/mot de passe mais j'avoue que j'ai pas vraiment regarder en profondeur !
Cordialement,
Kaimite
Hors ligne
#9 14-08-2009 12:03:28
Re: Gestion des droits au cas par cas.
Mmmh, j'ai dit une connerie en fait. Ce n'est pas Zend_Auth qui doit faire le array_intercept. C'est le plugin d'authentification (My_Controller_Plugin_Auth).
Zend_Auth ne fait que d'authentifier l'utilisateur. Mais si tu crées ton propre adaptateur de Zend_Auth, tu peux y faire n'importe quoi. Il te suffit de surcharger la fonction authenticate(). Quel est le problème avec les dates ?
Code:
class Kaimite_Auth_Adapter implements Zend_Auth_Adapter_Interface {
public function authenticate() {
// c'est moche ça mais c'est pour l'exemple...
$db = Zend_Registry::get('db') ;
$db->select(...) ;
if ( ... DATE OK ? ... ) {
// set session
return true ;
}
return false ;
}
}Dernière modification par keilnoth (14-08-2009 12:03:51)
Quelques tutoriaux Zend Framework !
Hors ligne
#10 14-08-2009 12:23:43
Re: Gestion des droits au cas par cas.
Effectivement, je m'était pas vraiment penché dessus.
En fait quand je créé des espace d'admin en général chaque utilisateur a une date de debut et de fin. Comme ça si un stagiaire vient on peut definir une période de validité pour son compte et pas oublier de le désactiver à la fin de son stage...
J'ai aussi un champ 'actif' qui est à oui ou non et qui est prioritaire sur la date de fin...
J'va me pencher sur Zend_Auth et voir comment étendre authenticate() pour qu'il réponde à mes besoins...
En tout cas merci pour l'info
@++ Kaimite
Dernière modification par Kaimite (14-08-2009 12:24:32)
Hors ligne
Développement par Kitpages