Version imprimable
Bonjour,
j'aimerais avoir vos avis sur comment gérer les habilitations de chaque action dans une application struts.
En fait j'utilise des DispatchAction et pour chaque action j'ai plusieurs méthodes, par exemple "ajouter", "modifier", "supprimer" et j'aimerais savoir comment gérer le fait que certains utilisateurs aient les droits de création uniquement, d'autres en création et modification et enfin d'autres avec le droit de suppression en plus.
Si les methodes sont toujours nommés pareil, tu pourrais peut-etre combinée Spring à Struts. Je sais que la partie AOP (programmation orienté aspect) te permet de faire un traitement en amont ou aval des methodes. Ainsi tu pourrais checker a ce moment si l'utilisateur a le droit de faire le ajouter si oui faire l'action et dans le cas contraire envoyé un message d'erreur.
J'espere avoir été à peu près clair et que c'est ce que tu cherchais!!
Bonjour phoebe,
je ne croies pas qu'il y ait de solution miracle pour gerer ceci.
Il faut que tu codes avant chaque appel de tes dispatchs l'appel a la fonction qui gere la notion de droit.
Apres je ne sais pas comment est ton application, mais si tu dois rendre visible les boutons, liens, champs en fonctions des droits de l'utilisateur, j'ai cree un projet FormView qui gere entre autres l'etat des champs en fonction des roles (sans etre oblige de mettre des if partout dans tes JSP, c'est laction qui pilote l'etat de tes champs (invisble, lecture seule, lecture-ecriture,...).
Angelo
Personnellement je crée une Action pour chaque action (modifier, créer, supprimer...).
Pour chaque Action il me reste plus qu'à contrôler les droits de l'utilisateur. ;)
Au niveau architecture, le mieux me semble de coder une action abstraite générique dérivant de DispatchAction, qui définit les méthodes abstraites nécessaires.
Toutes tes actions de ce type hériteront de cette classe, ce qui te permettra, sous eclipse par exemple, de créer obligatoirement et quasi-automatiquement (via la fonction Source > Override / Implement methods) tes méthodes.
Ca te permettra aussi, au besoin, de coder du code générique à toutes tes actions de ce type, pour par exemple controler tes droits d'accès.
C'est cette solution que j'utilise avec les Action : Chaque Action dérive d'une Super-Action qui contient une déclaration abstraite pour une méthode de contrôle.Citation:
Envoyé par mixouille
Chaque Action doit donc la redéfinir mais il est possible comme variante de surcharger une méthode générique de la Super-Action.
A+ ;)
Exactement :king:
Il est aussi possible de gérer les droits d'accès en sous classant le RequestProcessor ou la classe Filter
Il est ainsi possible de vérifier les droits de l'utilisateur avant d'exécuter l'action.
Vous trouverez des exemples (en Anglais) à cette adresse :
http://www.devarticles.com/c/a/Java/...pplications/5/
Oui, bien vu ptit-lu, après, tout dépend des besoins de phoebe (qu'on a pas revu à ce propos ...) et de la complexité de ses droits.
Dans l'appli que je code actuellement, quasiment chaque page a des droits particuliers qui sont fonction de beaucoup de paramètres. J'ai donc créé, dans mon action générique, une méthode abstraite (qui pourrait avoir une implémentation par défaut comme suggéré par Mister Nono) que j'implémente dans toutes mes actions et qui retourne un indicateur de "niveau de droits" (dans mon cas un int, ou un item d'une enum, qui indique le niveau : pas d'accès, lecture, écriture, mais ca pourrait aussi être un boolean).
Et, dans mon execute() générique, j'appelle cette méthode et je peux ainsi router éventuellement vers une page d'erreur, ou mettre à jour un attribut de mon form indiquant que je suis en lecture seule, etc.
Bon déjà, un grand merci pour vos propositions.
Mes méthodes ne s'appellent pas toute pareil, dans une même action je peux avoir "calculerTruc", "calculerMachin", "AjouterBibule" etc...
je vais regarder de plus prêt ce que propose ptit-lu et azerr puis je reviendrais faire un bilan de ces deux méthodes.
je voudrais ne pas avoir à gérer les "if" dans tous les sens dans mes jsp (comme le disait si bien azerr)
Sinon, je suis d'accord avec Mister Nono, le mieux serait d'avoir autant d'Action que d'action (supprimer, ajouter, calculer, etc...) seulement je trouve ça beaucoup trop lourd à coder et à maintenir car les écran d'ajout et de modification sont souvent identiques...
C'est vrai que le code est un peu plus long mais mais pas tant que cela en utilisant l'héritage où la surcharge des méthodes.Citation:
Envoyé par phoebe
Un autre avantage de cela est une approche modulaire de ton application : chaque Action ne fait qu'une tâche (elle est sous une forme atomique) et son interraction avec le reste de l'application reste très limitée. Donc tu peu très aisément et facilement utiliser une Action de ce type (ou module) dans une autre application sans changement du code source. Il y aura donc moins de tests et la réutilisation d'un code déjà validé auparavent impliquera une nouvelle application plus sûre aussi.
Enfin dans les DispatchAction on se base sur des Labels (par exemple : nom d'un bouton submit) pour déterminer la suite à réaliser. Le soucis c'est que dans une application multilangue les Labels sont modifiés (par exemple : Nom devient Name) suivant le client et il faut gérer cela dans les DispatchAction.
A+ ;)
pour ce qui est du nom des méthodes d'un DispatchAction, il y a plusieurs façon de faire et je n'utilise pas directement le libellé du bouton donc aucun soucis de ce point de vue là
Si tu veux vraiment faire un code générique qui, à partir de la valeur d'un champ (qui stoquerait le nom de ta méthode, si j'ai bien compris), appellerait la méthode correspondante de ton action, tu peux utiliser l'introspection de java :
http://ricky81.developpez.com/tutori...flection/#L4.2
Cela te permettra d'appeler une méthode suivant son nom, et de lui passer les paramètres que tu veux. Tu mets tout cela dans le "execute()" d'une action générique dont dérivent tes actions, et ca devrait marcher.
EDIT : je viens de m'apercevoir que je te proposais plus ou moins de recoder la fonction de Dispatch de Struts... :( . Il n'empêche que, par exemple, si tu as en base tous les noms des méthodes et les droits qui vont avec selon les utilisateurs, tu peux gérer ca come cela, à partir de la valeur de ton champ, et faire le dispatch ensuite, soit en dérivant la classe DispatchAction de Struts, soit en faisant comme je le disais, mais je ne vois plus trop l'intérêt.
EDIT 2 : pas très clair ce post :( :(
stocker les noms de méthode en base ne me parait pas terrible... il faut penser à ajouter une ligne en base dès qu'on écrit une nouvelle méthode
Je dirais plus : PAS TERRIBLE DU TOUT !!!! :aie:Citation:
Envoyé par phoebe
Ben, si son souhait est d'avoir des droits spécifiques pour chaque méthode, ca va être dur d'avoir quelque chose de non-dépendant du code !
Bon, c'est vrai qu'un fichier XML de config serait plus approprié, mais à part ça, ca ne me choque pas plus que ca. Certains frameworks fonctionnent ainsi (ceux des progiciels Websphere notamment, qui ne se gènent pas pour stocker en base toute la config des actions, droits, classes, etc..., et demandent des insert en base à chaque nouvelle fonctionnalité).
Et les possibilités que j'ai évoqué ne te conviennent pas ?Citation:
Envoyé par phoebe
En fait, je ne vois pas vraiment de problème sur la facon de controler l'affichage des pages et l'accès aux actions (toutes les méthodes proposées reviennent à peu près au même d'ailleurs), mais plutot sur comment configurer la chose.
Mais on aurait besoin de quelques précisions sur les besoins exacts de phoebe.
Si elle (il ?) doit configurer des droits particuliers pour chaque méthode/action de l'utilisateur, la solution que je proposais, à savoir configurer ca dans un fichier XML (mieux qu'en base, donc) est pour moi la meilleure. Après, pour appliquer cette configuration, on peut procéder comme tu le proposes, ptit-lu, ou comme je l'ai proposé, cela revient à peu près au même.
Merci à tous pour votre participation mais je vais sans doute opter pour la proposition d'Azerr, c'est ce qui correspond le plus à mes attentes.
Pour l'instant les habilitations ne sont pas mon soucis principal, on verra ça après.
J'ai un autre problème sur les bras, qui va faire l'objet d'un autre post...
Ok, mais à ce que j'ai compris, la solution de azerr concernait plus le rendu HTML, qu'as-tu choisi pour la configuration des droits ?
je ne sais pas encore comment nous allons faire.
de toute façon il faut un stockage en base du nom des actions pour que l'administrateur puisse gérer les droits de chaque action en fonction des profils utilisateurs.
Si l'action est "\listeProduits" par exemple, je peux facilement donner ou non le droit aux différents profils utilisateurs pour cette action, mais là où ça se complique c'est que certains soient limités aux droits de lecture, d'autres aux droits de lecture + écriture et enfin d'autres aux droits de lecture + écriture + suppression
c'est là mon réel problème mais je pense que vous l'aviez déjà cernés.
Un exemple similaire aux droits sur linux (commande chmod) :
1 = droit de lecture
2 = droit d'écriture
4 = droit de suppression
1 + 2 + 4 = 7 = tous les droits
1 + 2 = 3 = droits de lecture et d'écriture, etc...
Par exemple ton action possède un droit = 3 (droits lecture et d'écriture) et bien il faut que tu testes lorsque l'action est appelée :
Salut, ;)Code:
2
3
4
5
6
7
8
9
ce système nous (mon équipe) le connaissons déjà mais n'en sommes pas satisfaits car il faut penser à faire les tests dans chaque méthodes... et en fait si la personne n'a pas les droits de suppression par exemple, plutôt que de la laisser cliquer sur le bouton et lui envoyer un message d'erreur, j'aimerais plutôt ne pas lui afficher le bouton "supprimer".
et autre problème, quand on clique sur le bouton "modifier produit" par exemple alors accéder à l'écran en modification ou en consultation uniquement, suivant les droits.
Mais il suffit d'appeler une Action qui instancie le ActionForm en fonction des droits de l'utilisateur avec des attributs Boolean comme :Citation:
Envoyé par phoebe
boutonLire, boutonEcrire, boutonSupprimer...
Ensuite la JSP affichera les boutons en fonction des valeurs des attributs.
Et voilà le tour est joué.
Salut. ;)