Discussion :

[bambou]

Bonjour,

Je suis en train de concevoir un extranet en PHP (basé sur CakePHP) donc avec un espace membre et des données spécifiques à chaque utilisateur.

Je voulais savoir comment vous gérez d'empêcher un utilisateur d'accéder à des données qui ne lui appartiennent pas?

Par exemple, j'ai vu que pour éditer un post sur ce forum, l'id du post est renvoyé au serveur par une requête GET, il est alors très facile de modifier l'id et d'éditer un post qui n'est pas le sien...ce qui, ce forum étant bien développé, ne fonctionne pas bien sur

Lorsqu'il s'agit d'un simple post d'un utilisateur, il est assez facile de vérifier si le post appartient bien à l'utilisateur...mais lorsque le model de la BD se complexifie un peu, avec par exemple plusieurs tables et diverses relations entre ses tables (0 à n, 1 à n, n à m), ça devient assez lourd de faire tout le chemin pour remonter à l'utilisateur...

Donc j'ai pensé à mettre un champs (owner par exemple) contenant id de l'utilisateur, dans les tables contenant les données spécifiques à l'utilisateur, ce qui me permet de vérifier très facilement si l'utilisateur loggué est en train d'éditer/supprimer des données qui lui appartiennent bien.

Est-ce que cette façon vous parait correcte?

merci

[real34]

Bonjour,

CakePHP contient un système de gestion des rôles basé sur ACL. Tu trouveras un tutorial ici : http://book.cakephp.org/fr/view/641/...C3%A9e-par-Acl
Et la documentation contient également une section dessus : http://book.cakephp.org/fr/view/93/ACL

Ces deux pages sont encore en cours de traduction, c'est donc en anglais ...

Sinon, dans ton message certains points semblent bizarre : tu es en effet obligé de déterminer qui est le propriétaire d'un objet (exemple un message) de par les relations qui doivent exister dans ta modélisation ... sauf des cas très bizarres !
Ainsi il devrait être déjà possible pour toi de faire ces vérifications "à la main".

Es-tu nouveau avec le framework CakePHP ? Mieux vaudrait peut-être dans ce cas là commencer par les bases et faire des exemples plus simples.
Si tu as des questions, n'hésites pas !

[bambou]

Bonjour,

Merci pour ta réponse.

CakePHP contient un système de gestion des rôles basé sur ACL. Tu trouveras un tutorial ici : http://book.cakephp.org/fr/view/641/...C3%A9e-par-Acl
Et la documentation contient également une section dessus : http://book.cakephp.org/fr/view/93/ACL

Ces deux pages sont encore en cours de traduction, c'est donc en anglais ...

J'ai exploré un peu les ACL de cake et testé sur mon application, mais de mes tests, recherche sur la documentation et diverses demandes sur le chan IRC de Cake j'en suis arrivé à la triste conclusion que les ACL de cake sont faites pour qu'un utilisateur appartienne qu'à un seul et unique groupe (ça devrait etre corrigé pour la milestone 1.3 cf https://trac.cakephp.org/ticket/4063). Ce qui est relativement lourd dans mon cas.

Sinon, dans ton message certains points semblent bizarre : tu es en effet obligé de déterminer qui est le propriétaire d'un objet (exemple un message) de par les relations qui doivent exister dans ta modélisation ...

Oui je comprend bien, ma question était de savoir si c'était plus "propre" de mettre un champs owner dans tous les elements qui doivent avoir une verification particuliere ou si c'est mieu de se baser sur les relations de bases de données qui me permettent de remonter à l'utilisateur.
Par exemple dans mon cas, l'utilisateur "possede" des saisines, ces saisines "possedent" des entreprise qui elle-meme "possedent" des representant qui eux-meme "possedent" des couriers

Chaque modification sur un element saisine, entreprise, représentant, courrier ne doit pouvoir etre fait que par l'utilisateur qui les a créée. La solution la plus simple me parait être le champs "owner" dans les différentes tables et de faire la vérification effectivement "a la main" comme tu dis.

sauf des cas très bizarres !

Par exemple?

Es-tu nouveau avec le framework CakePHP ? Mieux vaudrait peut-être dans ce cas là commencer par les bases et faire des exemples plus simples.
Si tu as des questions, n'hésites pas !

Je suis effectivement nouveau avec Cake, enfin, maintenant un peu moins vu que je travaille dessus, a temps partiel, depuis juillet/aout 2008...je commence à maitriser un peu mieu le framework.

En tout cas merci encore pour ta réponse.

bonne journée

[real34]

Bonjour,
En effet on ne peut pas te considérer comme un débutant, tu as l'air de t'être pas mal renseigné sur le sujet !

Ce que je voulais dire pour les relations c'est que tu étais obligé d'avoir une relation entre différents modèles pour savoir à qui appartient quoi ... d'une manière ou d'une autre, sauf si tu fais des choses bizarres !

Concernant les ACL, je ne parle qu'en théoricien car cela fait partie (avec les tests unitaires) des aspects du framework que je n'ai pas encore pu mettre en oeuvre sur un projet (je n'utilise CakePHP que durant mon temps libre ).
Cependant, il me semble d'après la documentation que tu devrais pouvoir autoriser juste le créateur d'un élément à le modifier.

Pour cela, lorsque tu crées cet élément (on considère que tes ARO/ACO sont configurés) en ajoutant l'instruction suivante cela devrait faire ce que tu souhaites :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$this->Acl->allow($utilisateur_courant, array('model'=>'TonModele', 'foreign_key'=>$id_de_lelement_cree)); // Autorises l'utilisateur courant à faire toutes les modifications sur l'instance de TonModele ayant la clé $id...
// Tu peux également passer directement l'objet créé en second paramètre

Sinon, pour plus d'exemples et si tu te sens l'esprit d'un aventurier sache que dans certains cas pointus où la doc, l'IRC et les forums ne trouvent pas de solution, tu peux essayer de jeter un coup d'oeil dans les tests du framework : cela en dit beaucoup sur la manière d'utiliser une méthode.

[bambou]

Bonjour,
Ce que je voulais dire pour les relations c'est que tu étais obligé d'avoir une relation entre différents modèles pour savoir à qui appartient quoi ... d'une manière ou d'une autre, sauf si tu fais des choses bizarres !

Je me suis conformé aux possibilités qu'offre Cake, donc je n'ai que des relations gérées par le Framework (hasMany, hasOne, belongTo & HABTM), donc pas de bizarreries.
Cela dit comme dans l'exemple que je t'ai donné précédemment
ie un utilisateurs hasMany Saisines, une Saisine hasMany entreprises, une entreprise hasMany employés..etc
je trouve ça relativement lourd de remonter de l'employé pour trouver à quel utilisateur il appartient. Mettre un champs owner peut-être une solution, mais c'est pas trés trés propres dans mesure ou la gestion du CRUD sur l'employé sera codé en dur...cela dit pour mon cas c'est pas tellement un problème étant donné que seul l'utilisateur (et pas un admin ou un membre d'un groupe de plus haut niveau) peut lire/modifier/supprimer les données qu'il crée.

Aprés effectivement je peux passer par le système d'ACL de Cake, ou développer un petit système perso sur le même principe, sans sortir l'artillerie lourde.

J'hésite encore sur qu'elle solution adoptée, les ACL de Cake correspondent bien à ce dont j'ai besoin pour la gestion des accès d'un utilisateur à ces données, mais ne vont pas du tout pour la gestion des droits relatifs aux groupes d'utilisateurs...un mix d'une solution perso pour les permissions au niveau des groupes et accés aux controleurs et des ACL de cake pour les permissions au niveau des enregistrements serait peut-être le mieu...

Sinon, pour plus d'exemples et si tu te sens l'esprit d'un aventurier sache que dans certains cas pointus où la doc, l'IRC et les forums ne trouvent pas de solution, tu peux essayer de jeter un coup d'oeil dans les tests du framework : cela en dit beaucoup sur la manière d'utiliser une méthode.

Effectivement je n'ai jamais regardé les tests du framework, ça devrait surement m'aider. Merci pour le conseil.