Projet

Général

Profil

Actions

Evolution #78

fermé

Nouveau module d'administration des droits

Ajouté par Grégory MARIGOT - TEICEE il y a plus de 13 ans. Mis à jour il y a plus d'un an.

Statut:
Fermé
Priorité:
Normal
Version cible:
Début:
13/12/2010
Echéance:
% réalisé:

100%

Temps estimé:
Version ProxyEPN:
1.0

Description

La gestion des droits permets de définir les accès possibles (écriture, lecture, aucun) sur les différents modules de l'application, en fonction des profils des contacts (animateur, directeur, simple utilisateur, non authentifié).

La partie webadmin permettant la gestion de ses droits est restée celle d'origine de EPNadmin, il serait nécessaire de la remplacer par un nouveau module développé sur le framework Symfony.


Demandes liées 5 (0 ouverte5 fermées)

Lié à Evolution #77: Nouvelle version d'EPNadminFerméGrégory MARIGOT - TEICEE09/12/2010

Actions
Lié à Evolution #83: Améliorer l'interface de gestion des droitsFerméGrégory MARIGOT - TEICEE03/02/2011

Actions
Lié à Evolution #104: Accèder aux fiches animateurs/coordinateurs sans accéder aux fiches usagersFerméGrégory MARIGOT - TEICEE21/04/2011

Actions
Lié à Evolution #143: Etat public/privé des sessionsFerméGrégory MARIGOT - TEICEE28/11/2013

Actions
Lié à Anomalie #146: Optimisations sur les requêtes SQLFerméGrégory MARIGOT - TEICEE12/12/2013

Actions

Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans

  • Statut changé de Nouveau à In Progress
  • % réalisé changé de 0 à 80

Modifications publiées sur le svn (r323) :

Dans la BDD, les tables app_module et app_module_rights remplacent les tables functions et functions_rights. Possibilité de transformer les tables existantes vers les nouvelles (voir #3).

A partir de ces tables, deux nouveaux modules font leur apparition dans symfony :
  • AppModule : gestion de la liste des modules applicatifs
  • AppModuleRights : gestion des droits des usagers sur les modules

Leurs rôles étant proches, leur utilisation est liée et l'accès est commun, via la route "/droits".

Les fonctionnalités des nouveaux modules sont quasiment complètes :
  • liste des modules applicatifs, visualisation avec les droits associés, édition, suppression
  • liste des droits par "profil" : directeur / animateur / utilisateur / anonyme (non authentifié)
  • liste des droits également surchargeable pour un directeur ou animateur en particulier
  • édition sur un même formulaire de l'ensemble des droits pour le profil/utilisateur sélectionné
  • les droits restent définis sur 3 valeurs (aucun/lecture/écriture) pour 2 contextes (me/others)

Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans

TODO :

Quelques suggestions pour finaliser totalement :
  • Ajouter un champs de description sur les modules
  • Gérer la notion de dépendance inter-modules (ou la supprimer)
  • Pouvoir modifier les droits depuis la fiche d'un module (pour tous les profils)
  • Faire apparaitre les modules inactifs dans les listes de droits
  • Voir facilement les utilisateurs disposant de droits surchargés
  • Indiquer dans le cas de surcharges le paramètre par défaut du profil

Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans

NOTES :

Procédure de transformation des anciennes tables vers les nouvelles :

UPDATE sf_guard_group SET description='Administrateur général' WHERE id=1;
UPDATE sf_guard_group SET description='Directeur' WHERE id=2;
UPDATE sf_guard_group SET description='Animateur' WHERE id=3;
INSERT INTO sf_guard_group (id,name,description) VALUES ('4','user','Utilisateur enregistré');
INSERT INTO sf_guard_group (id,name,description) VALUES ('5','visitor','Visiteur anonyme');

ALTER TABLE functions ADD active CHAR(1) NOT NULL DEFAULT 'n';
ALTER TABLE functions CHANGE fn_id id INT(11) NOT NULL AUTO_INCREMENT;
ALTER TABLE functions CHANGE fn_name name VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '';
ALTER TABLE functions CHANGE fn_depend depends VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL;

DELETE FROM functions_rights WHERE fr_id_type='function';
ALTER TABLE functions_rights ADD group_id INT(11) NOT NULL DEFAULT 0 AFTER fr_id_type;
UPDATE functions_rights SET group_id=1 WHERE fr_id_type='admin';
UPDATE functions_rights SET group_id=2 WHERE fr_id_type='manager';
UPDATE functions_rights SET group_id=3 WHERE fr_id_type='facilitator';
UPDATE functions_rights SET group_id=4 WHERE fr_id_type='user';
UPDATE functions_rights SET group_id=5 WHERE fr_id_type='visitor';
UPDATE functions_rights SET group_id=0 WHERE fr_id>0;
ALTER TABLE functions_rights DROP fr_id_type;

ALTER TABLE functions_rights CHANGE fr_id user_id INT(11) NOT NULL DEFAULT 0;
ALTER TABLE functions_rights CHANGE fr_id_function app_module_id INT(11) NOT NULL DEFAULT 0;
ALTER TABLE functions_rights CHANGE fr_me me CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'n';
ALTER TABLE functions_rights CHANGE fr_others others CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'n';
ALTER TABLE functions_rights DROP fr_is_active;

ALTER TABLE functions DROP INDEX fn_name, ADD INDEX name (name);
ALTER TABLE functions_rights DROP INDEX fr_id_function;
ALTER TABLE functions_rights ADD PRIMARY KEY (user_id, group_id, app_module_id);

RENAME TABLE functions TO app_module;
RENAME TABLE functions_rights TO app_module_rights;

Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans

Evolutions à apporter :

  • Le rôle de Directeur n'a jusqu'à présent pas été exploité. Ce type de profil reste pertinent, il s'agit avant tout d'un accès en consultation uniquement des données. Pour correspondre à ce besoin, un nouveau terme tel que "coordinateur" parait approprié (un sens plus large permettra de l'utiliser par exemple pour des institutionnels ayant un droit de regard sur des EPN/GEPN).
  • Le rôle de Directeur/Coordinateur est bien à distinguer de celui des Animateurs, qui eux restent les opérationnels de l'applicatif. Pour obtenir une gestion des droits fiable, il apparait nécessaire d'empêcher formellement le cumul de ces rôles, sans quoi le cumul des droits est très problématique (surtout lorsqu'il s'applique sur des entités différentes). Si une personne doit disposer des 2 status, elle devra alors utiliser 2 comptes différents.
  • Aucun autre rôle supplémentaire n'est envisagé, inutile de devoir en administrer trop... Si des besoins de comptes avec des droits intermédiaires se présentent, ils devraient être peu fréquents et pourront toujours se régler au cas par cas en spécifiant des droits particuliers individuellemnt (puisqu'il reste la possibilité de définir les droits pour un contact précis).
  • Les niveaux de permissions pourraient être étendus : les 3 états actuels (aucun/lecture/écriture) sont parfois vagues, en particulier pour l'écriture qui peut signifier à la fois la création, l'édition et la suppression. Des niveaux plus précis ne seraient pas plus complexes à administrer du moment qu'ils peuvent s'organiser graduellement (chacun incluant les droits des précédents), par exemple :
    Rien < Lecture < Edition < Création < Suppression

Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans

Modification de la base de données

Les tables définissant la liste des modules et les droits applicables sur ceux-ci selon le profil des utilisateurs bénéficient de quelques adaptations :
  • La gestion de dépendances entre modules est définitivement abandonnée (trop lourd à gérer pour le peu d'utilité)
  • Une description est ajoutée aux modules pour faire bénéficier l'interface d'admin d'explications sur les fonctionnalités liées à chaque module présenté
  • L'activation/désactivation des modules se fait sur un champs de type booléen (0/1) plutôt qu'un char (y/n)
  • Une liste de choix est ajoutée pour chaque module : elle permettra de spécifier les droits applicables afin de ne pas proposer dans l'admin des possibilités non pertinentes (un widget personnalisé sera à définir pour prendre en compte des attributs 'disabled' propre à chaque option)
  • Les contextes applicables lors de l'affectation de droits restent au nombre de 2, mais sont renommés 'epn' et 'gepn' au lieu de 'me' et 'others' pour plus de clarté.

Détail des modifications SQL :

ALTER TABLE app_module DROP depends;
ALTER TABLE app_module ADD description TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL AFTER name;
ALTER TABLE app_module CHANGE active active TINYINT(1) NOT NULL DEFAULT '1';
ALTER TABLE app_module ADD choices VARCHAR(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '';

ALTER TABLE app_module_rights CHANGE me epn SMALLINT NOT NULL DEFAULT '0';
ALTER TABLE app_module_rights CHANGE others gepn SMALLINT NOT NULL DEFAULT '0';

Quelques changements également sur les tables annexes ajoutées au plugin sfGuard :
  • Les assignations de rôles se font uniquement sur des structures, l'affectation sur des gepn est supprimée car peu utile (les droits en places sont migrés vers les epn correspondants)
  • Le cumul de rôle étant à proscrire, les doublons sont nettoyés de la table (seul reste le rôle animateur dans ce cas)
  • La table contenant l'association simple "user-group" (ie le profil type) est regénérée pour prendre en compte le nettoyage des assignations
  • Les noms (et l'ordre) des groupes est modifié pour respecter la logique : le rôle 'manager' devient celui des animateurs, le rôle 'facilitator' est renommé en 'coordinator' pour les coordinateurs.

Détail des modifications SQL :

INSERT IGNORE INTO sf_guard_user_group_structure (user_id, group_id, structure_id)
SELECT user_id, group_id, structure.id FROM sf_guard_user_group_structure_group
LEFT JOIN structure ON structure.structure_group_id=sf_guard_user_group_structure_group.structure_group_id;
DROP TABLE `sf_guard_user_group_structure_group`;

DELETE a FROM sf_guard_user_group_structure AS a
LEFT JOIN sf_guard_user_group_structure AS b ON a.user_id=b.user_id
WHERE a.group_id!=b.group_id AND a.group_id=2;

DELETE FROM sf_guard_user_group WHERE group_id>1;
INSERT INTO sf_guard_user_group (user_id, group_id)
SELECT user_id, group_id FROM sf_guard_user_group_structure
GROUP BY user_id, group_id;

UPDATE sf_guard_group SET description='Animateur' WHERE id=2;
UPDATE sf_guard_group SET name='coordinator', description='Coordinateur' WHERE id=3;

UPDATE sf_guard_user_group_structure SET group_id=4 WHERE group_id=3;
UPDATE sf_guard_user_group_structure SET group_id=3 WHERE group_id=2;
UPDATE sf_guard_user_group_structure SET group_id=2 WHERE group_id=4;
UPDATE sf_guard_user_group SET group_id=4 WHERE group_id=3;
UPDATE sf_guard_user_group SET group_id=3 WHERE group_id=2;
UPDATE sf_guard_user_group SET group_id=2 WHERE group_id=4;

Note : Les données des tables 'app_module' et 'app_module_rights' sont obsolètes. Le mieux est de purger ses tables pour redéfinir la nouvelle liste des modules, puis redéfinir les droits pour chaque profil.

Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans

  • Statut changé de In Progress à Résolu
  • % réalisé changé de 80 à 100

Modifications publiées sur le svn (r335) :

Mise à jour majeure du code concernant l'application des droits.

Détermination des droits de l'utilisateur

La session web de l'utilisateur dispose de son contexte (dans un attribut "context_epn", c'est à dire la liste de ses EPN :
  • aucun pour un visiteur anonyme ;
  • son EPN de rattachement pour un utilisateur normal authentifié ;
  • les EPN sur lesquels son rôle s'applique pour un animateur ou un coordinateur.
Mais également la liste (et non un seul) des GEPN concernés (dans un attribut "context_gepn" :
  • le GEPN lié au sous-domaine utilisé pour un visiteur anonyme (sinon aucun) ;
  • le GEPN de l'EPN de rattachement pour un utilisateur normal authentifié ;
  • les GEPN des EPNs sur lesquels son rôle s'applique pour un animateur ou un coordinateur.

Il est donc prévu dans la gestion des droits qu'un animateur/directeur puisse être assignés sur plusieurs EPN appartenant à des GEPN différents. Le cloisonnement au sein d'un unique GEPN n'est plus une obligation, celà offre un niveau intermédiaire vu qu'auparavant seul le "superadmin" pouvait avoir une vision multi-GEPN (mais en les voyant tous sans restriction). Ceci a été jugé particulièrement utile pour le rôle de coordinateur.

Enfin, en fonction de son profil, ses droits seront également mémorisés dans la session comme suit :
  • Un credential au nom de son profil (MANAGER, COORDINATOR, USER ou VISITOR).
  • Un credential pour chacune des actions permises sur chaque module (ex "LIST_USER", "SHOW_USER", "EDIT_USER"...). Ceci étant hors-contexte, les droits les plus élevés sont retenus entre ceux définis sur EPN (ex-ME) et GEPN (ex-OTHERS).
  • Deux attributs pour chaque module (GEPN_"MODULE" et EPN_"MODULE"), mémorisant les niveaux d'action permis pour les deux contextes EPN et GEPN.

Application de la politique de droits

Un ensemble de méthodes sont mises en place pour faciliter l'application des permissions, particulièrement lorsqu'il s'agit de prendre en compte le contexte de l'utilisateur avec celui de l'entité ciblée :
  • pour des actions générales, la méthode user->hasCredential("ACTION_MODULE") reste suffisante ;
  • pour des actions ciblées, la méthode user->hasRight("ACTION", "MODULE", "ID") sera utilisée.
En faisant appel à la méthode hasRight, tout en ensemble de controles est effectué pour obtenir simplement la bonne réponse : true / false
  • Détermination du contexte de l'objet cible : à partir de son ID, on récupère l'EPN qui en est propriétaire et donc le GEPN correspondant (l'indication du MODULE est utilisé pour savoir quel est le type de l'objet et ainsi comment rechercher sa structure parente).
  • Comparaison entre le contexte de l'utilisateur et le contexte de l'objet cible, afin de savoir si l'action à lieu dans un EPN ou sinon dans un GEPN de l'utilisateur
  • Application des règles du profil de l'utilisateur, en regardant s'il dispose du niveau suffisant pour effectuée l'action demandée, pour le module spécifié, dans le contexte établi à l'étape précédente.

Maintenance du cloisonnement sur le(s) GEPN de l'utilisateur

Lors de toute requête de recherche (pour obtenir une liste d'objets), un filtre est systématiquement appliqué pour transformer le contexte de l'utilisateur en critères SQL.
La nouvelle classe 'Context' permet de faciliter ses opérations : en l'initialisant avec un contexte EPN/GEPN, elle permet notamment d'obtenir un objet 'Criteria' correspondant.

Au passage, l'ensemble des méthodes de type 'retrieveBy' ont dû être revues sur les classes peer. C'était l'occasion d'y faire le ménage et de les uniformiser. L'usage d'un Behavior Propel a permit d'enrichir automatiquement toutes les classes peer concernées de quelques méthodes génériques :
  • retrieveByContext : retourne une liste après application du contexte en filtre
  • retrieveByFilters : retourne une liste avec application de filtres divers (celui sur le contexte est posé d'office)
  • getPager : équivalent à la méthode précédente mais retourne un objet sfPropelPager pour gérer des listes paginées
Pour fonctionner, deux méthodes doivent être spécifiées dans les classes peer, afin de retourner les critères SQL utilisés par les méthodes précédentes :
  • criteriaFromContext : établit les jointures nécessaire pour exploiter le Criteria généré par la classe 'Context'
  • criteriaFromFilters : traitement spécifique des filtres transmis, le paramètre $filters étant un hachage dont chaque élément doit donner lieu à une condition SQL appropriée.

Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans

Assignations des rôles sur les structures

Pour rappel, il a été retenu :
  • que les rôles (animateur/coordinateur) ne s'appliquaient que sur les EPN, aucune assignation ne peut désormais se faire sur les GEPN (celà clarifie l'application des droits, sans pour autant pénaliser l'aspect fonctionnel). L'EPN reste ainsi l'entité centrale de l'application (aucune autre entité n'est directement reliée aux GEPN).
  • que les rôles ne doivent pas être cumulables : par exemple, un usager qui est déjà animateur ne doit pas pouvoir être assigné avec une autre rôle. Sans quoi une application stricte des politiques de droits devient imposible.

Modifications publiées sur le svn (r339) :

L'assignation redevient possible à partir de la fiche d'un EPN.
Comme auparavant, un formulaire propose une liste de tous les usagers du GEPN afin de choisir celui qui deviendra animateur ou directeur de l'EPN concerné. Cette liste exclue automatiquement les usagers ayant déjà un autre rôle.

En plus de la sélection dans cette liste, il est également possible d'utiliser un champs texte de recherche. Cette méthode alternative permet de retrouver un contact par son nom/prénom (recherche et autocomplétion via Ajax). Selon les goûts, cette méthode peut apparaitre plus pratique, mais surtout elle ne limite pas le choix aux membres du GEPN. En effet, puisqu'il est désormais possible d'obtenir un rôle sur des EPN appartenant à plusieurs GEPN, la recherche s'effectue sur tous les usagers disponibles (selon les droits de l'utilisateur).

Modifications publiées sur le svn (r347) :

Amélioration du controle visant à interdire le cumul de rôles différents.
Le filtre excluant de la sélection tout usager disposant déjà d'un autre rôle est amélioré afin de pouvoir s'appliquer aussi bien sur le sélecteur que sur le champs de recherche. Non seulement la validation du formulaire refuse un usager ayant un autre rôle, il est normalement impossible d'effectuer une telle opération, ces choix n'étant pas disponibles dans aucun des deux modes de désignation.

Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans

En conclusion

Cet ensemble de modifications met un terme à ce ticket.
Le nouveau système de gestion des droits est en place, administrable et applicable.
Il répond aux attentes en offrant suffisament de souplesse dans la gestion des profils, tout en assurant une bonne fiabilité et en facilitant son usage dans le code.

Quelques améliorations sur le formulaire d'édition des droits restent envisageables, essentiellement pour faire ressortir les utilisateurs qui disposeraient de droits particuliers (hors profil). Mais ceci pourra faire l'objet d'un autre ticket d'évolution future... (cf #83)

On peut aussi imaginer rendre possible les assignations de rôle à partir d'une fiche d'usager (plutot qu'en partant de la fiche d'un EPN), en sélectionnant alors la structure cible. (cf #85)

Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans

Modifications publiées sur le svn (r354) :

Prise en compte des droits des visiteurs anonymes

Un problème se posait sur l'application des permissions sur des utilisateurs non authentifiés :
  • la méthode hasCredential() fournit par le plugin sfGuardUser répond systématiquement "false" pour tout utilisateur non authentifié.
  • le système de droits de Symfony basé sur les fichiers security.yml, s'il permet de spécifier que les visiteurs anonymes soient acceptés ("is_secure: false"), ne tient alors pas compte des contraintes de credentials.

Pour résoudre le premier problème, la méthode hasCredential() a été réécrite dans la classe myUser afin de poursuivre les controles de credentials même s'il n'y a pas de comptes authentifiés.

Quant au second problème, il implique de se passer de la mise en place des permissions dans les fichiers security.yml : le paramètre "is_secure" est à "false" par défaut et doit rester ainsi pour tout module étant potentiellement accessible en anonyme. Dans ce cas, les contraintes de credentials qui y figuraient ne servent plus à rien et ces controles doivent être déportés vers les actions.

Pour faciliter cette tache et améliorer le code, le fichier actions de ces modules hérite d'une nouvelle classe myActions (qui hérite elle-même de la classe d'origine sfActions) afin d'y ajouter quelques méthodes génériques utiles :
  • checkCredential($credentials, $useAnd = true) : remplace les contraintes credentials des security.yml
  • checkRight($action, $module, $target) : remplace les appels forward404unless($this->getUser()->hasRight(...))

Ces deux méthodes sont respectivement des surcouches aux tests hasCredential et hasRight effectués sur l'utilisateur. Suite au controle, si le test échoue elles se chargent d'effectuer directement une redirection (forward Symfony vers une autre action).
De plus elles opèrent la distinction entre un utilisateur authentifié ou non : s'il ne l'est pas il sera redirigé vers la page de connexion, sinon il sera envoyé vers une page d'erreur indiquant qu'il ne dispose pas des droits nécessaires.

Grace à ces modifications l'application des politiques de droits est totalement paramétrable et effective, y compris pour le profil "visiteur".

Mis à jour par Grégory MARIGOT - TEICEE il y a presque 13 ans

Modifications publiées sur le svn (r413) :

Les modules définis dans cette administration des droits peuvent être désactivés. Dans ce cas aucun credential ne doit être accordé aux utilisateurs.
Ceci est à présent corrigé, une jointure oubliée empechait cette restriction de s'appliquer

Mis à jour par Grégory MARIGOT - TEICEE il y a presque 13 ans

  • Statut changé de Résolu à Fermé

Mis à jour par EleoSew EleoSew il y a plus d'un an

https://buydoxycyclineon.com - buy doxycycline Myc- ZEB1 was precipitated with an anti- Myc Tag antibody.

Mis à jour par EleoSew EleoSew il y a plus d'un an

Six2 heterozygous Six2 GCE mice were crossed to tdTomato reporter R26R tdTomato tdTomato mice https://nolvadex.one - natural alternatives to tamoxifen

Mis à jour par EleoSew EleoSew il y a plus d'un an

3 Info for medical coders on how to properly use this ICD 10 code https://priligy.me - dapoxetine priligy uk

Actions

Formats disponibles : Atom PDF