Zend FR

Consultez la FAQ sur le ZF avant de poster une question

Vous n'êtes pas identifié.

Pages: 1

 

#1 04-04-2008 19:06:18

Akis
Membre
Date d'inscription: 29-03-2008
Messages: 86
Site web

[Zend_Acl][1.5.1] Plus précis dans les accès

Bonsoir,

Imaginons une situation comme celle-ci :

Un membre peut modifier son profil.
Un administrateur peut modifier son profil & le profil des autres.

Imaginons qu'avec l'url : http://localhost/account/modify/ ; le membre tombe sur le formulaire de modification pour son compte. Pareil pour l'admin puisque c'est simplement un membre privilégié.

Maintenant, avec l'url suivante par exemple : http://localhost/account/modify/id/3
L'administrateur doit pouvoir éditer le profil du membre (ici 3).

Ma question est : Est-il possible, avec les Acl directement de bloquer le fait qu'un membre puisse accéder à une telle URL ? Ou bien dans mon action, je dois tester si l'utilisateur est admin ou pas ?

Merci d'avance

Hors ligne

 

#2 04-04-2008 21:29:55

philippe
Administrateur
Lieu: Grenoble
Date d'inscription: 01-03-2007
Messages: 1624

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

Tu peux faire ça avec des assertions :
http://framework.zend.com/manual/en/zen … assertions

Ca te permet de faire en gros le test que tu veux au moment où tu utilises tes ACL.

A+, Philippe

twitter : @plv ; kitpages.fr : Création de sites internet à Grenoble et Paris

Hors ligne

 

#3 04-04-2008 21:34:20

Akis
Membre
Date d'inscription: 29-03-2008
Messages: 86
Site web

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

Merci, je vais essayer d'utiliser cela.

Hors ligne

 

#4 05-04-2008 15:03:39

Akis
Membre
Date d'inscription: 29-03-2008
Messages: 86
Site web

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

Hmm, j'ai regarder les Assertions et j'ai compris leurs rôles. Mais je coince légèrement pour faire l'assertion qui me permettra de vérifier s'il peut ou non accéder à la page.

Je pars du principe qu'en fait, s'il y a un id dans l'url, il ne peut pas. Mais, je dois faire comment pour le récupérer dans ma class assertion ? A moins que je m'y prends mal hmm ?

Hors ligne

 

#5 12-04-2008 14:37:22

Akis
Membre
Date d'inscription: 29-03-2008
Messages: 86
Site web

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

Je fais légèrement remonté le post afin qu'un plus expérimenté puisse peut-être me répondre wink

Hors ligne

 

#6 12-04-2008 14:58:40

lethak
Membre
Lieu: France
Date d'inscription: 05-04-2008
Messages: 168

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

Déjà il faut partir du principe que personne n'a le droit, ensuite il suffis juste d'indiquer que si le compte utilisateur est du type admin,
allow = true;


donc dans la page il faut juste tester allow.

IT Dev @Twitter

Hors ligne

 

#7 12-04-2008 17:23:59

Paulop
Membre
Date d'inscription: 20-03-2008
Messages: 15

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

Si tu veux récupérer ton id, il faut récupérer la dans la requête la clef id, et vérifier si elle existe ou non.

     

Code:

$id = $this->getRequest()->id;

De la tu peux très bien verifier dans une fonction que l'id est le même que dans la BDD (ou mieux tu enregistre l'id dans la session d'auth !), alors si oui tu renvoie true dans l'assertion, si c'est pas pareil, tu renvoie false.
Bien sûr il faut rajouter dans ta fonction que si c'est l'admin (je te conseille de comparer ici le role et pas l'id de l'admin, le mieux étant d'avoir un groupe Admins, histoire de pas faire 32 verifications si tu as 32 admins), alors il faut renvoyer true quoi qu'il en soit.

Tout cela représente en fait une factorisation de la sécurité que tu souhaite dans une assertion (a peu près car pour ce que tu veux il faut quelques modif).

Ensuite tu vas pouvoir créer une route pour ne pas afficher l'id dans la barre d'adresse (il sera masqué).

De la si tu es un pirate et que tu rajoute /id/13 ton assertion va bloquer car tu n'es ni le membre 13, ni l'admin, l'accès est refusé (tu peux même le renvoyer sur une erreur 404), pour le reste des membres, il leur suffira de taper /membre pour tomber sur leur propre page, ou bien alors membre/id/leurid (mais ce n'est pas bien grave je pense).

Si tu n'as pas compris n'hésite pas à poser des questions, car je pense m'être mal expliqué smile

Hors ligne

 

#8 12-04-2008 17:53:31

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

Salut

J'ai depuis pas mal de temps adopté une gestions des droits qui réponds à une large problématique.
J'ai des utilisateurs identifiant + période de validité, l'utilisateur est autorisé pendant une période donnée à utiliser l'application.
j'ai des rôles identifiant ex admin, vendeur, redacteur etc.
et j'ai des groupes un identifiant la boutique de toulouse, le forum help la rubrique machin etc.

pour pouvoir se connecter mon utilisateur doit posséder un profil
un profil est un triplet user role group + une période de validité

cela signifie que l'utilisateur pourra exercer ce rôle dans ce groupe pendant la période de validité du profil

l'utilisateur peut ainsi exercer plusieurs rôles dans l'applications il peut changer au cours du temps

le role sert uniquement à vérifier l'accès fonctionnel
ainsi un administrateur peut utiliser les fonction d'administrations, le vendeur le module vente, et le rédacteur l'écriture d'article.

le groupe lui sert à définir le périmètre de couverture. le domaine dans lequel le rôle est exercé.
ainsi l'administrateur de la boutique de toulouse peut utiliser les fonction d'administration sur la boutique de toulouse et ne peut pas toucher aux données des autres boutiques.

bien évidement tous les rôles ne sont pas possible pour tous les groupes.
j'utilise pour ça une typologie de groupe
les boutiques, les forums, les entrepôts etc.
ainsi la boutique de toulouse est de type boutique
à chaque type j'associe une liste de rôle autorisés.

je peux ainsi ajouter des groupes à loisir et continuer à pouvoir y faire travailler des utilisateurs.

pour délimiter le périmètre fonctionnel j'utilise le rôle ce sont les ACL
pour les données j'associe mes données à un où plusieurs groupes ainsi le périmètre est définit.

très souvent on rencontre des notions hiérarchiques dans les groupes.
par exemple si je prend une société de vente de  vêtements
elle à plusieurs enseignes qui ont elle-même plusieurs boutique

mes groupe sont donc systématiquement hiérarchisés. même s'il n'y en a pas besoin (ça permet de toujours utiliser le même code)
de fait de cette hiérarchie la gestions de la couverture des droits se simplifie.

je peux utiliser cette hiérarchie pour dire dans mon modèle que un rôle exercé dans un groupe supérieur à visibilité du contenu de tous les groupes inférieur.

j'ai petit à petit ajouté des dates de début et de fin à tous ces objets.
sur les user les dates signifie que l'utilisateur peut ce connecter
sur les profils qu'il peut exercer le role dans le groupe
sur les groupes qu'on peut y affecter des rôles
sur les rôles qu'ont peut affecter ce rôle
sur un type de groupe qu'on peut créer un groupe de ce type

l'utilisateur peut avoir plusieurs rôles en même temps mais il ne peut se connecter à un instant que sur un profil

j'ai pour habitude de permettre aux utilisateur qui ont le droit de gestions de profils (ceux peuvent affecter un profils à quelqu'un) de leur permettre d'affecter à un autre utilisateur le même rôle dans le même groupe que le leur. cela permet à un gestionnaire de pouvoir déléguer sont activité (pendant ces congé par exemple) cela évite de devoir donner sont mot de passe pour que l'intérim soit assuré.

J'ai aussi hiérarchisé les rôles cela permet de n'autoriser un gestionnaire à n'affecter que des rôles qui dépendent du sien.

voilà j'espère avoir été clair.

ce qui est à retenir c'est la séparation des élément
user l'utilisateur
role ACL périmètre fonctionnel
group couverture des droit sur les donnée.

A+JYT

Hors ligne

 

#9 12-04-2008 21:34:44

Akis
Membre
Date d'inscription: 29-03-2008
Messages: 86
Site web

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

@lethak : Dans mon cas, je pense que justement je dois partir du principe que tout le monde à le droit. Puisque l'accès est restreint sur un paramètre et non sur une action. A moins que ma vision de la chose est plutôt foireuse ^^

@sekaijin : ton exemple semble très pertinent et très bien construit mais un peu complexe encore pour moi et surtout trop précis je crois pour l'exemple que je recherche à faire smile

@Paulop : Je n'arrive pas à récupérer l'id en fait. Ton code me génère une erreur me disant que getRequest n'est pas défini.

Oui j'ai un groupe d'admin que je compare avec le rôle de l'utilisateur.
Seulement, je dois comparer uniquement s'il y a un paramètre id.

Je ne cherche pas forcément à accepter le fait qu'un membre puisse accéder à l'url avec son ID. C'est un détail pour l'instant qui ne devrait pas être trop dur à avoir lorsque j'arriverai à faire fonctionner le bazar déjà maintenant ^^

Pour l'instant, je cherche juste à bloquer l'accès s'il y a un ID (même si c'est le sien), et l'autorisé si c'est un admin.

J'ai le code suivant :

Code:

class ModifyDeleteAssertion implements Zend_Acl_Assert_Interface {
    public function assert(Zend_Acl $acl, Zend_Acl_Role_Interface $role = null, 
            Zend_Acl_Resource_Interface $resource = null, $privilege = null) {
    
        if($privilege == "modify" || $privilege == "delete") {
            $id = (int) $this->getRequest()->id;
            
            if($id > 0) {
                return ROLE_ADMIN == $role->getRoleId();
            }
            return true;
        }
        return true;
    }
}

Merci pour votre aide smile

Hors ligne

 

#10 12-04-2008 22:43:04

Paulop
Membre
Date d'inscription: 20-03-2008
Messages: 15

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

l'id doit être récupéré par ton controlleur car il va chercher la chose dans l'URI.

Donc il faudra la passer en param apres à ton assert.

Hors ligne

 

#11 13-04-2008 02:22:37

lethak
Membre
Lieu: France
Date d'inscription: 05-04-2008
Messages: 168

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

en partant du principe que personne n'a le droit c'est plus simple car tu peux:

- allouer un droit ou pas si le visiteur a confirmé son adresse email
- allouer un droit d'accès simple a chaque visiteur (en dur dans le code, et le désactiver si besoin)
- allouer des accès plus poussé pour les membre qui sont admin.

je conseil l'utilisation de My_acl de Michael "MistaGee" Ziegler qui permet de gérer les acl avec une base de donnée.

http://www.phpclasses.org/browse/package/4100.html

IT Dev @Twitter

Hors ligne

 

#12 13-04-2008 10:49:27

Akis
Membre
Date d'inscription: 29-03-2008
Messages: 86
Site web

Re: [Zend_Acl][1.5.1] Plus précis dans les accès

Paulop a écrit:

l'id doit être récupéré par ton controlleur car il va chercher la chose dans l'URI.

Donc il faudra la passer en param apres à ton assert.

L'assertion n'est pas testé avant d'arriver dans le controlleur justement ?

Merci lethak, j'y jetterai un oeil.

Hors ligne

 

 

Pages: 1

Pied de page des forums

Propulsé par PunBB
© Copyright 2002–2005 Rickard Andersson
Traduction par punbb.fr

Graphisme réalisé par l'agence Rodolphe Eveilleau
Développement par Kitpages