Bonjour,

Je me pose une question sur la "bonne" méthode de gestion des droits par modules dans une application web.
Aujourd'hui, je compte procéder ainsi :
- affecter un utilisateur à un groupe.
- affecter des droits sur des modules à ce groupe.
Ces infos étant stockées dans une base SQL, à la connexion je genere des variables de session à partir des droits (par exemple $_SESSION['module1']) ; ensuite je vérifie sur chaque page des modules la présence d'une telle variable correspondante au nom du module pour donner l'accès au non au module.

Voici la méthode qui m'est venue à l'esprit, avez-vous de vôtre coté des expériences dans ce genre de méthode et pouvez-vous critiquer la mienne en particulier au niveau sécurité.

merci d'avance.

JCPREAUX76

j'utilise le même principe pour gérer les doits dans mes applis.

Bon codage!

A+

Pascal

Moi j'attends Zend_Acl:
http://framework.zend.com/wiki/display/ ... .+Zend_Acl
http://framework.zend.com/apidoc/incubator/

Personnellement, j'ai crée un table d'authorisations pour les modules de la forme suivante
-auth_id
-auth_module_id
-auth_actions
-auth_group_id
Le champ auth_actions contient sous forme d'une chaine séparée par des ; les actions auxquelles le groupe est autorisé a acceder.
Quand je charge un module, la variable $_SESSION['auth_params'] est crée grace a une selection des autorisations en fonction de l'id du groupe et contient un tableau du type suivant:

• action n1
• action n2
• action n3
• action n...

Ensuite, j'ai crée un fonction check_auths qui me permet de vérifier, en spécifiant une clef action qui me permet de vérifier si l'utilisateur est autorisé car chaque action est référencée par son index.
Globalement, mon système peut se résumer de la facon suivante ^^

J'ai un système un peu à la momox, mais totalement objet :
- un objet Permission est un triplet [ cible, action, autorisation ] (par exemple cible = un nom de fichier, action = écrire, autorisation = oui ou non).
- un objet Groupe est (pour ce qui nous intéresse) un quadruplet [ sous-groupes, groupe-parent, utilisateurs, permissions ] (permissions et sous-groupes sont des tableaux, groupe-parent peut être null).
- un objet Utilisateur est (pour ce qui nous intéresse) un triplet [ id, groupes, permissions ] avec en plus à côté toutes les infos de l'utilisateur.

Pour vérifier qu'un utilisateur a la permission P je vérifie s'il l'a lui-même, ou si l'un de ses groupes l'a.
Pour vérifier qu'un groupe a la permission P je vérifie s'il l'a lui-même, ou si son groupe-parent l'a (s'il existe).
Dans l'ordre des vérifications, dès que je tombe sur la même permission (même cible et même action) je renvoie la valeur de son autorisation et j'interromps là le parcours. Si je ne trouve rien je renvoie "non".

Je m'arrange pour que les relations Groupe.sous-groupes <-> Groupe.groupe-parent et Utilisateur.groupes <-> Groupe.utilisateurs sont gérés automatiquement par un système du genre ezPdo par exemple (comme ça c'est plus facile).
Ce système étant basé sur deux chaines (cible et action) il est virtuellement infini. Et la gestion des héritages de permission est assez naturelle. J'ai mis ça en place et je m'en sers dans une GED que j'ai développée pour le boulot, l'interface de gestion de droits est en cours de développement je crois que je pourrais bien avoir l'autorisation de publier ce module en GPL, mais bon il n'est pas révolutionnaire je crois simplement avoir réinventé un genre d'ACL "light".

J'ai mis ça en place et je m'en sers dans une GED que j'ai développée pour le boulot, l'interface de gestion de droits est en cours de développement je crois que je pourrais bien avoir l'autorisation de publier ce module en GPL, mais bon il n'est pas révolutionnaire je crois simplement avoir réinventé un genre d'ACL "light".

Tu sais que tu m'intéresses ? Je viens de me farcir l'intégralité du sous-fofo "Méthodologie, modélisation, sécurité" et c'est le seul article qui parle de ce que je veux vraiment.

Moi aussi, je souhaite organiser mon site de la manière suivante :

Groupes
- SuperAdmin (1)
- Admin (2)
- Modérateur (3)
- Membre (4)
- Ami (5)
- Neutre (6)
- Ennemi (7) (oui y'a du jeu derrière )

Bien entendu, les groupes se chevauchent puisque certains de mes amis m'aideraient à administrer le site.

On est donc en plein dans le sujet !

Par contre, bien qu'ayant compris la logique des objets ('fin je crois), je ne vois pas trop comment organiser tout ça dans ma base de données (ni encore tout à fait l'exploiter en objet, m'enfin on va déjà commencer par l'organisation dans les tables

Table Visiteurs Bref, si je commence "au feeling" : GROUPES
'groupe =0' : SuperAdmin
'groupe=2,5' : Admin Ami
'groupe=3,6' : Admin Ami

Permissions
'perm = 0' : DieuSurMonSite (toutes fonctions)
'perm = 1' : T'esDouéMaisPasLeMeilleur (quasi-toutes fonctions)
'perm = 2' : TouristeEnGoguette
'perm = 3' : Espece-d-Elfe-va !

Le niveau de permission / le(s) groupe(s) de chacun est rapatrié en SESSION à sa connexion : jusque là ça va ?

Mais comme je suis chiant (et ambitieux dans mon projet, mais chiant surtout), je voudrais donner (ou non ) la possibilité à certains de :

- utiliser certains modules (en fonction du statut Ami-Ennemi)
- partager des infos entre membres d'un même groupe.

Concrètement, j'aimerai bien un système de gestion des utilisateurs et sous-forum façon forum PHPbb.

J'ose pas encore me lancer directement dans le reverse-engineering de leur code, je dois conserver une apparence de vie sociale normale jusqu'à ce que je décroche mon contrat de développeur en alternance... Et si je m'y met, je sens que je ne vais pas en sortir de suite...

Personnelement j'utilise un systeme de calcul sur les bit pour les gestions de droits en définissant des actions sous forme de constante.
define('LECTURE',1);
define('CREATION',2);
define ('MODIFICATION', 4);
define ('SUPPRESSION', 8);

Ensuite il suffit d'utiliser ces constantes pour définir des droits en les enregistrant en base de données, exemple :

$query = "UPDATE table SET droits = (droits ^ ".LECTURE.") WHERE user_id='2'";

Ensuite pour savoir si l'utilisateur à le droits de lecture il suffit de recuperer les droits pour l'action souhaitée et de faire la comparaison :
if(doit_utilisateur & LECTURE){
// l'utilisateur peut lire
}

Je trouve ce système sympa, on peut ainsi définir différents droits suplémentaires facilement :
define ('VISION_GLOBALE',16);
define ('ALTERATION', 8|4|2);

Aaaaaaaaah ! Une réponse ! Merci ! ^^

Ton système permet-il d'autoriser un même utilisateur à écrire dans une section et pas dans une autre ?

Je voudrais gérer finement les accès à mes modules et à des sous-forums particuliers créés par les utilisateurs.

Ex : Paul, Modérateur, Ami, crée un sous-forum partagé avec tout le Groupe Ami /// Groupe Ami => Lecture sur le forum.

Elisabeth, Membre, Ami, crée un sous-forum partagé avec Paul seulement.
=> On met quoi comme permission et à quel groupe ?

J'suis chiant hein, je suis très exigeant et je suis sûr que y'aurait moyen de faire ça, mais pour l'instant la seule solution que j'envisage c'est en tables... N'en a rien compris aux objets, pourtant bien attirants !

A chaque création de nouveau groupe donc, on rajoute une colonne à la table Permissions. A chaque enregistrement (et donc à module/forum) correspond le niveau de permission de chaque groupe.

Je me trompe où ma modélisation est correcte (approximativement parlant) ?

Après, j'ai pas trop compris l'utilité de mettre des bits partout :S

define ('ALTERATION', 8|4|2);

C'est pas plus simple de la jouer :
define('LECTURE',1);
define('CREATION',2);
define ('MODIFICATION', 3);
define ('SUPPRESSION', 4); ???[/color]

1 : me suis inscrit
2 : il faut encore créer une table avec une clé étrangère pour indiquer à "Table formation" la liste des utilisateurs en individuels autorisés à consulter le forum non ?

Je sais pas vous, mais moi ça me donne le tournis, je sens venir l'usine à gaz !

Je prends tous les conseils pour avoir un truc qui marche, quitte à partir sur les objets et plus les tables (mais ils sont générés par les tables, alors comment je m'en sors moi ?)

edit : Une piste ici

Avec ça je devrai pouvoir créer dans ma table des forums mon tableau des groupes et utilisateurs..

Je vous tiens au courant d'ici ce soir de ce que ça donne...

OK, j'ai mis du temps à revenir, mais j'ai embauché entretemps
fonction serialize trop lourde à gérer pour les tris, je pense faire une table liant les id des tables groupes/modules/utilisateurs

critère d'unicité : la jonction de ces 3 ids
Nombre d'enregistrements de cette table = nb_enr(groupes) * nb_enr(modules) * nb_enr(utilisateurs)

Faut pas en avoir trop, mais perso ça me ferait au max

100*20*2000 = 4 000 000
OK, ça va ptêt faire trop... :-°