Hello à tous,

Il serait bon d'avoir vos avis concernant les ACL (Access Control List), c'est à dire les différents niveaux d'habilitation que les utilisateurs peuvent avoir lors de l'utilisation du Robert.

Les ACL sont intimement liés à l'interface, c'est pourquoi il est crucial de les définir avant de penser au design de l'interface.

Voici un exemple d'ACL basique, pour vous faire une idée de la façon dont elles se présentent :

Action Visiteur Stagiaire Technicien ... Admin
Créer Matériel Non Non Oui ... Oui
Modifier Matériel Non Oui Oui ... Oui
Ajouter utilisateur Non Non Non ... Oui
Créer événement Non Oui Oui ... Oui
Voir événements Oui Oui Oui ... Oui
Modifier événement Non Les siens Les siens ... Oui
Configurer Robert Non Non Non ... Oui
etc...

Bien entendu cette table des ACL serait modifiable dans l'admin du Robert, mais partir sur une base la plus précise possible pour tout le monde nous aidera à concevoir l'interface !

Donc je vous en prie, n'hésitez pas à faire des propositions, concernant la liste des actions à contrôler, ainsi que le nombre de niveaux différents que vous aimeriez pouvoir utiliser (maximum 9 niveaux, on ne va pas abuser smile ) et leurs noms. En ce qui concerne le contenu de la table (oui/non/les siens), on verra ça de façon logique !

Cheers !!

Hello à tous, Il serait bon d'avoir vos avis concernant les ACL (Access Control List), c'est à dire les différents niveaux d'habilitation que les utilisateurs peuvent avoir lors de l'utilisation du Robert. Les ACL sont intimement liés à l'interface, c'est pourquoi il est crucial de les définir avant de penser au design de l'interface. Voici un exemple d'ACL basique, pour vous faire une idée de la façon dont elles se présentent : | *Action* | Visiteur | Stagiaire | Technicien | ... | Admin | |:--------------------- |:-------:|:--------:|:----------:|:--:|:------:| | *Créer Matériel* | *Non* | *Non* | **Oui** | ... | **Oui** | | *Modifier Matériel* | *Non* | **Oui** | **Oui** | ... | **Oui** | | *Ajouter utilisateur* | *Non* | *Non* | *Non* | ... | **Oui** | | *Créer événement* | *Non* | **Oui** | **Oui** | ... | **Oui** | | *Voir événements* | **Oui** | **Oui** | **Oui** | ... | **Oui** | | *Modifier événement* | *Non* | Les siens | Les siens | ... | **Oui** | | *Configurer Robert* | *Non* | *Non* | *Non* | ... | **Oui** | | etc... Bien entendu cette table des ACL serait modifiable dans l'admin du Robert, mais partir sur une base la plus précise possible pour tout le monde nous aidera à concevoir l'interface ! Donc je vous en prie, n'hésitez pas à faire des propositions, concernant la liste des actions à contrôler, ainsi que le nombre de niveaux différents que vous aimeriez pouvoir utiliser (maximum 9 niveaux, on ne va pas abuser ;) ) et leurs noms. En ce qui concerne le contenu de la table (*oui/non/les siens*), on verra ça de façon logique ! Cheers !!
edited Apr 11 '16 at 3:44 pm
 
1
reply

Effectivement ce serait indispensable d'implémenter des ACL, ne serai-ce que pour qu'il n'y ait pas que les techniciens qui puissent y accéder, mais permettre aussi aux bénéficiaires de visualiser leurs infos, comme discuté ici.

Pour la catégorie "visiteur", je me pose la question de la confidentialité. Est-ce qu'un visiteur peut être n'importe qui ? Est-ce qu'il peut voir toutes les infos de n'importe quel événement ? Les bénéficiaires ne souhaitent pas forcément que leurs événements/réservations soient visibles de tout le monde... (Par exemple pour une bibliothèque, j'ai pas forcément envie que tout le monde sache quels livres je lis)
Mais si on place le visiteur plutôt dans le cadre d'un bénéficiaire, on pourrait se dire que son accès pour l'action "Voir événements" serait plutôt sur "les siens".

Par ailleurs, dans le cas du simple visiteur (mais on peut sûrement le fusionner avec le bénéficiaire), il peut être intéressant de pouvoir visualiser certaines informations d'un matériel. Si je reprends l'exemple de la bibliothèque, on peut vouloir voir la description d'un livre et à partir de quand il sera à nouveau disponible.

Effectivement ce serait indispensable d'implémenter des ACL, ne serai-ce que pour qu'il n'y ait pas que les techniciens qui puissent y accéder, mais permettre aussi aux bénéficiaires de visualiser leurs infos, comme discuté [ici](http://robertforum.polosson.com/index.php?u=/topic/20/reservation-am-ou-pm/1#post-81). Pour la catégorie "visiteur", je me pose la question de la confidentialité. Est-ce qu'un visiteur peut être n'importe qui ? Est-ce qu'il peut voir toutes les infos de n'importe quel événement ? Les bénéficiaires ne souhaitent pas forcément que leurs événements/réservations soient visibles de tout le monde... (Par exemple pour une bibliothèque, j'ai pas forcément envie que tout le monde sache quels livres je lis) Mais si on place le visiteur plutôt dans le cadre d'un bénéficiaire, on pourrait se dire que son accès pour l'action "Voir événements" serait plutôt sur "les siens". Par ailleurs, dans le cas du simple visiteur (mais on peut sûrement le fusionner avec le bénéficiaire), il peut être intéressant de pouvoir visualiser certaines informations d'un matériel. Si je reprends l'exemple de la bibliothèque, on peut vouloir voir la description d'un livre et à partir de quand il sera à nouveau disponible.
 
1
reply

Yes @fbastien le terme "visiteur" dans mon exemple était dans le sens de "bénéficiaire, ou personne ayant un intérêt particulier à avoir un compte sur le Robert" smile

En aucun cas la liste des événements ne doit être publique, cela va de soi smile
Les différents "niveaux d'habilitation" des ACL correspondent forcément chacun à un compte utilisateur du Robert. Pas de connexion, pas d'accès, donc pas d'ACL.

Donc on pourrait effectivement imaginer un compte spécial qui n'ait accès que à la liste du matériel (ou livres) à des fins purement informatives, mais je pense que ça peut être développé facilement en dehors du Robert, comme une simple page web ayant accès à la base de données... Ou alors on pourra proposer un module ou plugin qui permette d'afficher certaines infos publiquement (c'est à dire sans compte utilisateur), plus tard...

Concernant les ACL, si tu as d'autres idées sur les différents "niveaux" (colonnes) possibles ? Pour ma part je verrai :

  1. Bénéficiaire
  2. Stagiaire
  3. Technicien
  4. Responsable
  5. Comptable
  6. Administrateur
  7. Développeur
  8. Root

Le compte "Root" ayant accès à tout, à des fins de débogage et de config poussée, de même que le compte "dev" (mais ce dernier aurait quelques accès restreints à "les siens" ).
Bien sûr tout ces niveaux ne seraient pas forcément pertinents dans tout les cas, mais "qui peut le plus peut le moins" ! smile

Enfin, la liste des "actions" (lignes) peut être assez longue au final, et surtout complétée au fur et à mesure du dev, donc on ne va pas forcément tout recenser ici, mais les idées sont aussi les bienvenues smile

Cheers !

Yes @fbastien le terme "visiteur" dans mon exemple était dans le sens de "bénéficiaire, ou personne ayant un intérêt particulier à avoir un compte sur le Robert" :P En aucun cas la liste des événements ne doit être publique, cela va de soi ;) Les différents "niveaux d'habilitation" des ACL correspondent forcément chacun à un **compte utilisateur** du Robert. Pas de connexion, pas d'accès, donc pas d'ACL. Donc on pourrait effectivement imaginer un compte spécial qui n'ait accès que à la liste du matériel (ou livres) à des fins purement informatives, mais je pense que ça peut être développé facilement en dehors du Robert, comme une simple page web ayant accès à la base de données... Ou alors on pourra proposer un module ou plugin qui permette d'afficher certaines infos publiquement (c'est à dire sans compte utilisateur), plus tard... Concernant les ACL, si tu as d'autres idées sur les différents "niveaux" (colonnes) possibles ? Pour ma part je verrai : 1. 2. Bénéficiaire 3. Stagiaire 4. Technicien 5. Responsable 6. Comptable 7. Administrateur 8. Développeur 9. Root Le compte "Root" ayant accès à tout, à des fins de débogage et de config poussée, de même que le compte "dev" (mais ce dernier aurait quelques accès restreints à "les siens" ). Bien sûr tout ces niveaux ne seraient pas forcément pertinents dans tout les cas, mais "qui peut le plus peut le moins" ! ;) Enfin, la liste des "actions" (lignes) peut être assez longue au final, et surtout complétée au fur et à mesure du dev, donc on ne va pas forcément tout recenser ici, mais les idées sont aussi les bienvenues ;) Cheers !
edited Apr 11 '16 at 3:40 pm
 
0
reply

En aucun cas la liste des événements ne doit être publique, cela va de soi smile
Les différents "niveaux d'habilitation" des ACL correspondent forcément chacun à un compte utilisateur du Robert. Pas de connexion, pas d'accès, donc pas d'ACL.

Oui bien sûr, moi aussi je pars du principe qu'il faut obligatoirement un compte pour accéder au Robert. Mais en fait j'avais en tête la suggestion que j'ai vue dans un autre sujet de permettre aux utilisateurs de créer eux-mêmes leur compte. Du coup ça revenait à peu près à être publique...

Concernant les ACL, si tu as d'autres idées sur les différents "niveaux" (colonnes) possibles ?

Il pourrait y avoir un rôle genre "Chef" ou "Responsable", qui aurait les mêmes droits que les techniciens mais pourrait aussi accéder et modifier les événements des autres, voire aussi ajouter des utilisateurs ou modifier leurs droits (uniquement inférieurs ou égaux à "technicien" bien sûr).

Le compte "Root" ayant accès à tout, à des fins de débogage et de config poussée, de même que le compte "dev" (mais ce dernier aurait quelques accès restreints à "les siens" ).

Je ne vois pas trop la différence entre "root" et "dev"... Tu pensais limiter quoi pour un compte "dev" ? Parce que si c'est le compte de quelqu'un qui accède et modifie le code source, je vois pas trop l'utilité... Mais il y a peut-être quelque chose qui m'échappe smile

>En aucun cas la liste des événements ne doit être publique, cela va de soi ;) >Les différents "niveaux d'habilitation" des ACL correspondent forcément chacun à un **compte utilisateur** du Robert. Pas de connexion, pas d'accès, donc pas d'ACL. Oui bien sûr, moi aussi je pars du principe qu'il faut obligatoirement un compte pour accéder au Robert. Mais en fait j'avais en tête la suggestion que j'ai vue dans un autre sujet de permettre aux utilisateurs de créer eux-mêmes leur compte. Du coup ça revenait à peu près à être publique... >Concernant les ACL, si tu as d'autres idées sur les différents "niveaux" (colonnes) possibles ? Il pourrait y avoir un rôle genre "Chef" ou "Responsable", qui aurait les mêmes droits que les techniciens mais pourrait aussi accéder et modifier les événements des autres, voire aussi ajouter des utilisateurs ou modifier leurs droits (uniquement inférieurs ou égaux à "technicien" bien sûr). >Le compte "Root" ayant accès à tout, à des fins de débogage et de config poussée, de même que le compte "dev" (mais ce dernier aurait quelques accès restreints à "les siens" ). Je ne vois pas trop la différence entre "root" et "dev"... Tu pensais limiter quoi pour un compte "dev" ? Parce que si c'est le compte de quelqu'un qui accède et modifie le code source, je vois pas trop l'utilité... Mais il y a peut-être quelque chose qui m'échappe :)
edited Apr 11 '16 at 3:40 pm
 
0
reply

Bonjour @polosson et @fbastien

Je vous laisse jeter un oeil, dès demain je vous poste un tableau récapitulatif avec tous nos besoin et ce que l'on a déjà mis en place en prenant compte de vos remarque dans ces postes

Bonjour @polosson et @fbastien Je vous laisse jeter un oeil, dès demain je vous poste un tableau récapitulatif avec tous nos besoin et ce que l'on a déjà mis en place en prenant compte de vos remarque dans ces postes
edited Mar 23 '16 at 12:36 pm
 
0
reply

@melvin
Merci de nous partager ce que vous avez déjà fait.
Par contre je t'invite vraiment à supprimer de ton post les identifiants d'accès, et à plutôt nous les envoyer en MP. C'est le genre d'infos qu'il ne vaut mieux pas laisser dans un visible de tout le monde ! smile (sauf si c'est juste une instance de test et que tu ne crains pas que quelqu'un de malintentionné vienne pourrir ta base de données, et encore...)
Idem dans l'autre sujet.

@polosson
Je repensais à la mise en œuvre technique des ACL : si on veut quelque chose de plus modulable/configurable, on peut faire un système du genre rôles et groupes plutôt qu'un simple entier dont on vérifie s'il est >= au niveau requis.

Je m'explique :

On aurait une table pour faire l'association entre chaque fonctionnalité et le ou les rôles qui y ont accès. Ensuite, le principe est que chaque utilisateur est associé à un ensemble de rôles. Et pour simplifier l'admin, on n'associe pas directement les utilisateurs aux rôles mais à un groupe, avec une table d'association permettant de dire que les utilisateurs de tel groupe ont tels rôles. Du coup quand on veut accéder à une fonctionnalité, on vérifie qu'au moins un des rôles du groupe de l'utilisateur est autorisé.

Ici les groupes correspondraient à bénéficiaire, techos, admin, etc.
Les rôles sont plus spécifiques et correspondent à un ensemble d'actions similaires nécessitant le même niveau d'autorisations, par exemple : gestion des comptes, gestion (création/modif) de ses événements, suivi global des événements, correction des événements des autres, suivi (lecture seule pour bénéficiaires) de ses réservations, gestion courante du matériel, gestion création/inventaire/modif avancée du matériel, etc.
Les fonctionnalités ou actions sont alors plus précises que dans ce tableau, par exemple on distingue afficher la liste de tous les événements, afficher la liste seulement des miens, afficher les infos d'un événement sur lequel je suis, afficher les infos de l'événement de quelqu'un d'autre, etc. En gros, ça correspond à chaque point d'accès dans le code...

L'avantage d'une solution comme ça, c'est aussi que quand on choisit les accès d'un niveau, on n'est pas obligés (sauf mettre des exceptions moches dans le code) d'inclure tous les droits des niveaux inférieurs.
Par exemple, on pourrait mettre un groupe RH qui a les rôles permettant de créer/modifier les comptes, sans avoir les droits "inférieurs" de créer/modifier les événements et le matos...
Bien sûr, il faut qu'à l'installation ces tables d'ACL soient pré-remplies.

Bon, je sais pas si c'est très clair tout ce que j'ai dit... smile

@melvin Merci de nous partager ce que vous avez déjà fait. Par contre je t'invite vraiment à supprimer de ton post les identifiants d'accès, et à plutôt nous les envoyer en MP. C'est le genre d'infos qu'il ne vaut mieux pas laisser dans un visible de tout le monde ! ;) (sauf si c'est juste une instance de test et que tu ne crains pas que quelqu'un de malintentionné vienne pourrir ta base de données, et encore...) Idem dans l'[autre sujet](http://robertforum.polosson.com/index.php?u=/topic/20/reservation-am-ou-pm/1#post-89). @polosson Je repensais à la mise en œuvre technique des ACL : si on veut quelque chose de plus modulable/configurable, on peut faire un système du genre rôles et groupes plutôt qu'un simple entier dont on vérifie s'il est >= au niveau requis. Je m'explique : On aurait une table pour faire l'association entre chaque fonctionnalité et le ou les rôles qui y ont accès. Ensuite, le principe est que chaque utilisateur est associé à un ensemble de rôles. Et pour simplifier l'admin, on n'associe pas directement les utilisateurs aux rôles mais à un groupe, avec une table d'association permettant de dire que les utilisateurs de tel groupe ont tels rôles. Du coup quand on veut accéder à une fonctionnalité, on vérifie qu'au moins un des rôles du groupe de l'utilisateur est autorisé. Ici les groupes correspondraient à bénéficiaire, techos, admin, etc. Les rôles sont plus spécifiques et correspondent à un ensemble d'actions similaires nécessitant le même niveau d'autorisations, par exemple : gestion des comptes, gestion (création/modif) de ses événements, suivi global des événements, correction des événements des autres, suivi (lecture seule pour bénéficiaires) de ses réservations, gestion courante du matériel, gestion création/inventaire/modif avancée du matériel, etc. Les fonctionnalités ou actions sont alors plus précises que dans ce tableau, par exemple on distingue afficher la liste de tous les événements, afficher la liste seulement des miens, afficher les infos d'un événement sur lequel je suis, afficher les infos de l'événement de quelqu'un d'autre, etc. En gros, ça correspond à chaque point d'accès dans le code... L'avantage d'une solution comme ça, c'est aussi que quand on choisit les accès d'un niveau, on n'est pas obligés (sauf mettre des exceptions moches dans le code) d'inclure tous les droits des niveaux inférieurs. Par exemple, on pourrait mettre un groupe RH qui a les rôles permettant de créer/modifier les comptes, sans avoir les droits "inférieurs" de créer/modifier les événements et le matos... Bien sûr, il faut qu'à l'installation ces tables d'ACL soient pré-remplies. Bon, je sais pas si c'est très clair tout ce que j'ai dit... :S
edited Apr 11 '16 at 3:40 pm
 
1
reply

Bonjour @fbastien

Ne t'inquiètes pas j'ai fait une copie de notre BDD et de nos fichiers FTP et je vous ai donné l'accès c'est vraiment une base TEST j'ai supprimé toutes les infos de nos étudiants et toutes leurs anciennes réservations si vous voulez voir comment les étudiants voient leur réservation je peux en exporter quelqu'une de notre BDD et vous les mettre dans la base test avec les droits Utilisateurs. Je viens de vérifier de notre côté nos étudiants ont bien c'est droit là. Actuellement nous sommes configurés comme ça. Donc vous pouvez vous amuser. Pour la liste du matériel nous avons laissé ce que nous mettons à disposition comme ça vous pouvez faire des réservations.

Ton second commentaire dans ton poste je n'ai pas tout compris mais je pense le mieux c'est de ne pas s'embêter @polosson. Je pense que le plus simple et de faire une configuration de base exemple ci-dessous. Après il faudrait pouvoir avoir la possibilité de la moduler/ajouter/supprimer via un tableau les accès utilisateur à souhait.

Action Externe Beneficiaire Stagiaire Technicien Etudiant Utilisateur Comptable Admin Developpeur Root
S'incrire à l'application Oui Non Non Non Non Non Non Non Non Non
Modifier son mot de passe Les siens Les siens Les siens Les siens Les siens Les siens Les siens Les siens Les siens Les siens
Voir événements Non Oui Oui Oui Oui Oui Oui Oui Oui Oui
Voir le matériel Non Oui Oui Oui Oui Oui Oui Oui Oui Oui
Créer événement Non Non Non Non Oui Oui Non Oui Oui Oui
Modifier/Annuler/Copier événement Non Non Les siens Les siens Les siens Les siens Non Oui Oui Oui
Créer Matériel Non Non Non Oui Non Oui Non Oui Oui Oui
Modifier Matériel Non Non Non Non Non Non Non Oui Oui Oui
Ajouter utilisateur/technicien Non Non Non Non Non Non Non Oui Oui Oui
Configurer Robert Non Non Non Non Non Non Non Oui Oui Oui
Statistique Non Non Non Non Non Non Oui Oui Oui Oui

Ce tableau est disponible sur un Google Drive s'il vous interesse


MAJ 23/03/2016

Voulez-vous que je vous redonne accès à notre Robert Test pour que vous voyez le niveau d'habilitation de nos étudiants et notre appropriation de votre outils (personnalisation de certain paramètre) ?

Bonjour @fbastien Ne t'inquiètes pas j'ai fait une copie de notre BDD et de nos fichiers FTP et je vous ai donné l'accès c'est vraiment une base TEST j'ai supprimé toutes les infos de nos étudiants et toutes leurs anciennes réservations si vous voulez voir comment les étudiants voient leur réservation je peux en exporter quelqu'une de notre BDD et vous les mettre dans la base test avec les droits Utilisateurs. Je viens de vérifier de notre côté nos étudiants ont bien c'est droit là. Actuellement nous sommes configurés comme ça. Donc vous pouvez vous amuser. Pour la liste du matériel nous avons laissé ce que nous mettons à disposition comme ça vous pouvez faire des réservations. Ton second commentaire dans ton poste je n'ai pas tout compris mais je pense le mieux c'est de ne pas s'embêter @polosson. Je pense que le plus simple et de faire une configuration de base exemple ci-dessous. Après il faudrait pouvoir avoir la possibilité de la moduler/ajouter/supprimer via un tableau les accès utilisateur à souhait. Action|Externe|Beneficiaire|Stagiaire|Technicien|Etudiant|Utilisateur|Comptable|Admin|Developpeur|Root| :--------------------- |:-------:|:--------:|:----------:|:--:|:------:| *S'incrire à l'application* |Oui|Non|Non|Non|Non|Non|Non|Non|Non|Non *Modifier son mot de passe*|Les siens|Les siens|Les siens|Les siens|Les siens|Les siens|Les siens|Les siens|Les siens|Les siens *Voir événements* |Non|Oui|Oui|Oui|Oui|Oui|Oui|Oui|Oui|Oui *Voir le matériel* |Non|Oui|Oui|Oui|Oui|Oui|Oui|Oui|Oui|Oui *Créer événement* |Non|Non|Non|Non|Oui|Oui|Non|Oui|Oui|Oui *Modifier/Annuler/Copier événement*|Non|Non|Les siens|Les siens|Les siens|Les siens|Non|Oui|Oui|Oui *Créer Matériel*|Non|Non|Non|Oui|Non|Oui|Non|Oui|Oui|Oui *Modifier Matériel*|Non|Non|Non|Non|Non|Non|Non|Oui|Oui|Oui *Ajouter utilisateur/technicien*|Non|Non|Non|Non|Non|Non|Non|Oui|Oui|Oui *Configurer Robert*|Non|Non|Non|Non|Non|Non|Non|Oui|Oui|Oui *Statistique*|Non|Non|Non|Non|Non|Non|Oui|Oui|Oui|Oui Ce tableau est disponible sur un Google Drive s'il vous interesse *** MAJ 23/03/2016 Voulez-vous que je vous redonne accès à notre Robert Test pour que vous voyez le niveau d'habilitation de nos étudiants et notre appropriation de votre outils (personnalisation de certain paramètre) ?
edited Mar 23 '16 at 3:58 pm
 
1
reply

Hello @fbastien

Je repensais à la mise en œuvre technique des ACL : si on veut quelque chose de plus modulable/configurable, on peut faire un système du genre rôles et groupes plutôt qu'un simple entier dont on vérifie s'il est >= au niveau requis.

Héhé c'est exactement ce à quoi je pensais aussi, et je l'ai déjà développé pour une autre web app, j'ai déjà la classe php toute prête !!

En fait on a une table dans la base de données qui décrit le tableau des droits, avec pour chaque colonne un "rôle" (que j'appelle "niveau d'habilitation" mais c'est pareil), et pour chaque ligne une "action" qui correspond à un bouton, une page, ou une zone particulière de l'interface. Ensuite on a un objet "ACL" (classe php), qu'il suffit d'instancier et de lui faire faire la vérification que le rôle (niveau) de l'utilisateur actuellement connecté ait le droit d'accéder au bouton, à la page ou à la zone, ou bien le droit de démarrer une action.

Si ça t'intéresse je peux faire un petit dépôt github avec la classe et un exemple d'utilisation...

L'avantage d'avoir le tableau des correspondances des rôles dans la base, est qu'il est facilement modifiable depuis l'interface, et que l'on peut ajouter autant d'actions que l'on veut, au fur et à mesure du développement.

Ensuite,

Ici les groupes correspondraient à bénéficiaire, techos, admin, etc.
Les rôles sont plus spécifiques et correspondent à un ensemble d'actions similaires nécessitant le même niveau d'autorisations, (...)

Si je comprend bien ce que tu veux dire, tu parles de grouper les actions par type ? Si c'est le cas je pense que ça risque de compliquer un peu le dev, parce qu'il risque d'y avoir beaucoup d'actions différentes, qui ne se ressemblent pas forcément au final, et les grouper peut devenir un jeu d'esprit assez balèze... (Bien sûr je parle au conditionnel, je n'ai pas encore une vue assez globale ni précise de toutes les actions possibles à inscrire dans les ACL).

Dans le système que j'ai en tête, il n'y a pas d'inclusion des niveaux inférieurs pour une action donnée, il ne s'agit pas d'une comparaison >= ou <=, mais bien d'un == au rôle donné, dans tout les cas. Chaque rôle a un accès "refusé", "autorisé" ou "restreint aux siens", pour chaque action précise, sans s'occuper des autres rôles.

J'aime bien ce débat, j'attends ta réponse avec impatience smile

Cheers !!

Hello @fbastien &gt; Je repensais &agrave; la mise en &oelig;uvre technique des ACL : si on veut quelque chose de plus modulable/configurable, on peut faire un syst&egrave;me du genre r&ocirc;les et groupes plut&ocirc;t qu&#039;un simple entier dont on v&eacute;rifie s&#039;il est &gt;= au niveau requis. H&eacute;h&eacute; c&#039;est exactement ce &agrave; quoi je pensais aussi, et je l&#039;ai d&eacute;j&agrave; d&eacute;velopp&eacute; pour une autre web app, j&#039;ai d&eacute;j&agrave; la classe php toute pr&ecirc;te !! En fait on a une table dans la base de donn&eacute;es qui d&eacute;crit le tableau des droits, avec pour chaque colonne un &quot;r&ocirc;le&quot; (que j&#039;appelle &quot;niveau d&#039;habilitation&quot; mais c&#039;est pareil), et pour chaque ligne une &quot;action&quot; qui correspond &agrave; un bouton, une page, ou une zone particuli&egrave;re de l&#039;interface. Ensuite on a un objet &quot;ACL&quot; (classe php), qu&#039;il suffit d&#039;instancier et de lui faire faire la v&eacute;rification que le r&ocirc;le (niveau) de l&#039;utilisateur actuellement connect&eacute; ait le droit d&#039;acc&eacute;der au bouton, &agrave; la page ou &agrave; la zone, ou bien le droit de d&eacute;marrer une action. Si &ccedil;a t&#039;int&eacute;resse je peux faire un petit d&eacute;p&ocirc;t github avec la classe et un exemple d&#039;utilisation... L&#039;avantage d&#039;avoir le tableau des correspondances des r&ocirc;les dans la base, est qu&#039;il est facilement modifiable depuis l&#039;interface, et que l&#039;on peut ajouter autant d&#039;actions que l&#039;on veut, au fur et &agrave; mesure du d&eacute;veloppement. Ensuite, &gt; Ici les groupes correspondraient &agrave; b&eacute;n&eacute;ficiaire, techos, admin, etc. Les r&ocirc;les sont plus sp&eacute;cifiques et correspondent &agrave; un ensemble d&#039;actions similaires n&eacute;cessitant le m&ecirc;me niveau d&#039;autorisations, (...) Si je comprend bien ce que tu veux dire, tu parles de grouper les actions par type ? Si c&#039;est le cas je pense que &ccedil;a risque de compliquer un peu le dev, parce qu&#039;il risque d&#039;y avoir beaucoup d&#039;actions diff&eacute;rentes, qui ne se ressemblent pas forc&eacute;ment au final, et les grouper peut devenir un jeu d&#039;esprit assez bal&egrave;ze... (Bien s&ucirc;r je parle au conditionnel, je n&#039;ai pas encore une vue assez globale ni pr&eacute;cise de toutes les actions possibles &agrave; inscrire dans les ACL). Dans le syst&egrave;me que j&#039;ai en t&ecirc;te, il n&#039;y a pas d&#039;inclusion des niveaux inf&eacute;rieurs pour une action donn&eacute;e, il ne s&#039;agit pas d&#039;une comparaison &gt;= ou &lt;=, mais bien d&#039;un == au r&ocirc;le donn&eacute;, dans tout les cas. Chaque r&ocirc;le a un acc&egrave;s &quot;refus&eacute;&quot;, &quot;autoris&eacute;&quot; ou &quot;restreint aux siens&quot;, pour chaque action pr&eacute;cise, sans s&#039;occuper des autres r&ocirc;les. J&#039;aime bien ce d&eacute;bat, j&#039;attends ta r&eacute;ponse avec impatience :) Cheers !!
edited Apr 11 '16 at 3:40 pm
 
1
reply

@melvin

Merci pour le tableau, il pourra nous être utile pour votre cas d'utilisation.

Voulez-vous que je vous redonne accès à notre Robert Test pour que vous voyez le niveau d'habilitation de nos étudiants et notre appropriation de votre outils (personnalisation de certain paramètre) ?

Oui volontiers, j'ai supprimé les accès en pensant que cela pourrait vous nuire, mais si vous êtes sûrs que rien ne risque d'être détruit sur votre base de données, vous pouvez les publier ici.

@fbastien encore une chose, les colonnes de la table "ACL" sont des chiffres (de 1 à 9), mais une correspondance de ces chiffres sera faite via la config du Robert, afin de les rendre "lisibles" par les utilisateurs dans l'interface bien sûr ! Cette config étant modifiable, on pourra nommer chaque rôle comme on veut. (genre 9='root', 8='chieur', 7='zikos'...) smile

Cheers !

@melvin Merci pour le tableau, il pourra nous &ecirc;tre utile pour votre cas d&#039;utilisation. &gt; Voulez-vous que je vous redonne acc&egrave;s &agrave; notre Robert Test pour que vous voyez le niveau d&#039;habilitation de nos &eacute;tudiants et notre appropriation de votre outils (personnalisation de certain param&egrave;tre) ? Oui volontiers, j&#039;ai supprim&eacute; les acc&egrave;s en pensant que cela pourrait vous nuire, mais si vous &ecirc;tes s&ucirc;rs que rien ne risque d&#039;&ecirc;tre d&eacute;truit sur votre base de donn&eacute;es, vous pouvez les publier ici. @fbastien encore une chose, les colonnes de la table &quot;ACL&quot; sont des chiffres (de 1 &agrave; 9), mais une correspondance de ces chiffres sera faite via la config du Robert, afin de les rendre &quot;lisibles&quot; par les utilisateurs dans l&#039;interface bien s&ucirc;r ! Cette config &eacute;tant modifiable, on pourra nommer chaque r&ocirc;le comme on veut. (genre 9=&#039;root&#039;, 8=&#039;chieur&#039;, 7=&#039;zikos&#039;...) :D Cheers !
edited Apr 11 '16 at 3:40 pm
 
0
reply

Bonjour @polosson @fbastien

Voici les accès

http://forum-robert.ingemedia.net/

id : admin@admin.org
mdp : admin

id : utilisateur@utilisateur.org
mdp : utilisateur

id : consultant@consultant.org
mdp : condultant

Si vous avez besoin d'aide pour le développement de la V2 n'hésité pas smile. Je le ferai avec plaisir car c'est un outils que l'on utilise tous les jours donc ça ne me pose pas de problème.

Bonjour @polosson @fbastien Voici les acc&egrave;s http://forum-robert.ingemedia.net/ id : admin@admin.org mdp : admin id : utilisateur@utilisateur.org mdp : utilisateur id : consultant@consultant.org mdp : condultant Si vous avez besoin d&#039;aide pour le d&eacute;veloppement de la V2 n&#039;h&eacute;sit&eacute; pas ;). Je le ferai avec plaisir car c&#039;est un outils que l&#039;on utilise tous les jours donc &ccedil;a ne me pose pas de probl&egrave;me.
edited Apr 11 '16 at 3:41 pm
 
0
reply

@polosson

J'aime bien ce débat, j'attends ta réponse avec impatience smile

Oups, j'étais passé à autre chose et j'ai oublié de répondre ! smile

En tout cas c'est bien si t'avais la même vision, les grands esprits se rencontrent comme on dit ! smile

Effectivement, je ne l'ai pas mentionné tellement c'était évident dans ma tête, mais le principal avantage de cette solution est de pouvoir configurer les droits sans toucher au code, via une interface. smile

Héhé c'est exactement ce à quoi je pensais aussi, et je l'ai déjà développé pour une autre web app, j'ai déjà la classe php toute prête !!

Si ça t'intéresse je peux faire un petit dépôt github avec la classe et un exemple d'utilisation...

C'est super si t'en as une déjà faite ! Par contre pas besoin de créer un dépôt pour ça, et puis je pense que c'est encore trop tôt pour se pencher de manière aussi précise sur l'implémentation technique, on verra comment on l'utilise au moment des devs.

Si je comprend bien ce que tu veux dire, tu parles de grouper les actions par type ?

En fait c'était surtout dans l'idée de simplifier l'administration par un utilisateur lambda (qui a les droits, tout de même smile ) pour éviter qu'il ne se retrouve avec trop de lignes dans le tableau de configuration. Par exemple un rôle "gestion des comptes" regrouperait les actions de créer un compte, de modifier les infos d'un compte, de réinitialiser le mot de passe d'un compte, et de supprimer un compte. En général, on a soit toutes ces actions, soit aucune, d'où l'idée de les regrouper...
Et après si besoin, il peut toujours changer les associations actions <-> rôle, mais au moins les associations rôles <-> groupe (= niveau d'habilitation) sont faciles à administrer.

Mais bon, c'est peut-être un peu trop gadget ou trop coûteux à mettre en place ; effectivement on peut utiliser un seul tableau.
Sinon il peut y avoir une solution intermédiaire avec un seul tableau comme tu disais, mais avec 2 niveaux de lignes pour pouvoir faire des regroupements : quand on donne les droits pour une ligne-groupe, ça donne les droits pour toutes les lignes normales qu'elle contient. Et dans l'interface, par défaut on affiche que les lignes de premier niveau, mais l'utilisateur peut développer pour afficher celles de 2e niveau...

Dans le système que j'ai en tête, il n'y a pas d'inclusion des niveaux inférieurs pour une action donnée, il ne s'agit pas d'une comparaison >= ou <=, mais bien d'un == au rôle donné, dans tout les cas.

Là je parlais du fonctionnement actuel du code, donc j'ai bien compris que ce n'était pas le cas de ta solution. smile

@fbastien encore une chose, les colonnes de la table "ACL" sont des chiffres (de 1 à 9), mais une correspondance de ces chiffres sera faite via la config du Robert, afin de les rendre "lisibles" par les utilisateurs dans l'interface bien sûr ! Cette config étant modifiable, on pourra nommer chaque rôle comme on veut. (genre 9='root', 8='chieur', 7='zikos'...) smile

Comme je vois les choses, les chiffres seraient juste des ID d'une table... (surtout si on peut configurer au point d'ajouter/supprimer des niveaux d'habilitation)
En fait on aurait 3 tables : une table pour les niveaux d'habilitation, avec leur ID et leur nom lisible ; une table pour les actions, avec idem leur ID et leur nom lisible ; et puis une table associative qui pour chaque couple d'ID niveau+action indique si c'est autorisé, refusé, ou restreint au sien. Dans le code on utilise juste la dernière table de conf, et les 2 autres sont simplement utilisées pour afficher les noms dans l'interface de conf. Quoique la table pour les actions est discutable, ça pourrait juste être des constantes dans le code (vu que le contenu n'est pas censé être modifié).

Bon... affaire à suivre smile

@polosson &gt;J&#039;aime bien ce d&eacute;bat, j&#039;attends ta r&eacute;ponse avec impatience :) Oups, j&#039;&eacute;tais pass&eacute; &agrave; autre chose et j&#039;ai oubli&eacute; de r&eacute;pondre ! :x En tout cas c&#039;est bien si t&#039;avais la m&ecirc;me vision, les grands esprits se rencontrent comme on dit ! :D Effectivement, je ne l&#039;ai pas mentionn&eacute; tellement c&#039;&eacute;tait &eacute;vident dans ma t&ecirc;te, mais le principal avantage de cette solution est de pouvoir configurer les droits sans toucher au code, via une interface. ;) &gt;H&eacute;h&eacute; c&#039;est exactement ce &agrave; quoi je pensais aussi, et je l&#039;ai d&eacute;j&agrave; d&eacute;velopp&eacute; pour une autre web app, j&#039;ai d&eacute;j&agrave; la classe php toute pr&ecirc;te !! &gt;Si &ccedil;a t&#039;int&eacute;resse je peux faire un petit d&eacute;p&ocirc;t github avec la classe et un exemple d&#039;utilisation... C&#039;est super si t&#039;en as une d&eacute;j&agrave; faite ! Par contre pas besoin de cr&eacute;er un d&eacute;p&ocirc;t pour &ccedil;a, et puis je pense que c&#039;est encore trop t&ocirc;t pour se pencher de mani&egrave;re aussi pr&eacute;cise sur l&#039;impl&eacute;mentation technique, on verra comment on l&#039;utilise au moment des devs. &gt;Si je comprend bien ce que tu veux dire, tu parles de grouper les actions par type ? En fait c&#039;&eacute;tait surtout dans l&#039;id&eacute;e de simplifier l&#039;administration par un utilisateur lambda (qui a les droits, tout de m&ecirc;me (mm) ) pour &eacute;viter qu&#039;il ne se retrouve avec trop de lignes dans le tableau de configuration. Par exemple un r&ocirc;le &quot;gestion des comptes&quot; regrouperait les actions de cr&eacute;er un compte, de modifier les infos d&#039;un compte, de r&eacute;initialiser le mot de passe d&#039;un compte, et de supprimer un compte. En g&eacute;n&eacute;ral, on a soit toutes ces actions, soit aucune, d&#039;o&ugrave; l&#039;id&eacute;e de les regrouper... Et apr&egrave;s si besoin, il peut toujours changer les associations actions &lt;-&gt; r&ocirc;le, mais au moins les associations r&ocirc;les &lt;-&gt; groupe (= niveau d&#039;habilitation) sont faciles &agrave; administrer. Mais bon, c&#039;est peut-&ecirc;tre un peu trop gadget ou trop co&ucirc;teux &agrave; mettre en place ; effectivement on peut utiliser un seul tableau. Sinon il peut y avoir une solution interm&eacute;diaire avec un seul tableau comme tu disais, mais avec 2 niveaux de lignes pour pouvoir faire des regroupements : quand on donne les droits pour une ligne-groupe, &ccedil;a donne les droits pour toutes les lignes normales qu&#039;elle contient. Et dans l&#039;interface, par d&eacute;faut on affiche que les lignes de premier niveau, mais l&#039;utilisateur peut d&eacute;velopper pour afficher celles de 2e niveau... &gt;Dans le syst&egrave;me que j&#039;ai en t&ecirc;te, il n&#039;y a pas d&#039;inclusion des niveaux inf&eacute;rieurs pour une action donn&eacute;e, il ne s&#039;agit pas d&#039;une comparaison &gt;= ou &lt;=, mais bien d&#039;un == au r&ocirc;le donn&eacute;, dans tout les cas. L&agrave; je parlais du fonctionnement actuel du code, donc j&#039;ai bien compris que ce n&#039;&eacute;tait pas le cas de ta solution. ;) &gt;@fbastien encore une chose, les colonnes de la table &quot;ACL&quot; sont des chiffres (de 1 &agrave; 9), mais une correspondance de ces chiffres sera faite via la config du Robert, afin de les rendre &quot;lisibles&quot; par les utilisateurs dans l&#039;interface bien s&ucirc;r ! Cette config &eacute;tant modifiable, on pourra nommer chaque r&ocirc;le comme on veut. (genre 9=&#039;root&#039;, 8=&#039;chieur&#039;, 7=&#039;zikos&#039;...) :D Comme je vois les choses, les chiffres seraient juste des ID d&#039;une table... (surtout si on peut configurer au point d&#039;ajouter/supprimer des niveaux d&#039;habilitation) En fait on aurait 3 tables : une table pour les niveaux d&#039;habilitation, avec leur ID et leur nom lisible ; une table pour les actions, avec idem leur ID et leur nom lisible ; et puis une table associative qui pour chaque couple d&#039;ID niveau+action indique si c&#039;est autoris&eacute;, refus&eacute;, ou restreint au sien. Dans le code on utilise juste la derni&egrave;re table de conf, et les 2 autres sont simplement utilis&eacute;es pour afficher les noms dans l&#039;interface de conf. Quoique la table pour les actions est discutable, &ccedil;a pourrait juste &ecirc;tre des constantes dans le code (vu que le contenu n&#039;est pas cens&eacute; &ecirc;tre modifi&eacute;). Bon... affaire &agrave; suivre :)
edited Apr 11 '16 at 3:41 pm
 
0
reply
153
views
10
replies
3
followers
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft