Nouvelle lib d'authentification et autorisation
Bonjour, Je réfléchis à une librairie d'authentification et autorisation basée sur les jsp et sur shiro. Le but est de proposer: * une gestion simple d'accès à des fonctionnalités suivant un login et un role * de proposer une interface de création des utilisateurs, des roles et des permissions (matrice utilisateurs/roles) * une méthode d'authentification Je ne connais pour l'instant pas du tout shiro, et je m’interroge sur la façon la plus propre de créer des interfaces web dans une lib pour l'utiliser dans une application (jsp et servlet) : si possible sans passer par des taglib. La persistance serait plutôt orientée ToPIA. La librairie devra être suffisamment générique pour servir à plusieurs projets. Le but de mon application est simplement très basic, suivant les rôles de l'utilisateur, il s'agira de cacher des entrées de menu (voire limite d'interdire l'accès aux actions struts), mais rien concernant le rendu des pages ou le filtrage des données. Auriez vous des pistes concernant le codage des views (jsp) et code (???) dans ce cas ? Merci. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
On Wed, 26 Sep 2012 17:20:13 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Bonjour,
Je réfléchis à une librairie d'authentification et autorisation basée sur les jsp et sur shiro. Le but est de proposer: * une gestion simple d'accès à des fonctionnalités suivant un login et un role * de proposer une interface de création des utilisateurs, des roles et des permissions (matrice utilisateurs/roles) * une méthode d'authentification
Je ne connais pour l'instant pas du tout shiro, et je m’interroge sur la façon la plus propre de créer des interfaces web dans une lib pour l'utiliser dans une application (jsp et servlet) : si possible sans passer par des taglib.
arch bah justement shiro est là pour fournir les taglibs très pratiques qui permettent d'encapsuler des fragments de jsp qui ont besoin d'une authen ou d'une permission. Il faut je pense s'en servir. J'ai la même demande dans Pollen, mais pour le moment personne n'y a répondu :(
La persistance serait plutôt orientée ToPIA.
La librairie devra être suffisamment générique pour servir à plusieurs projets.
La seule chose à faire c'est se plugger sur l'authentication et autorization de Shiro via l'utilisation des filtres shiro et/ou d'un realm
Le but de mon application est simplement très basic, suivant les rôles de l'utilisateur, il s'agira de cacher des entrées de menu (voire limite d'interdire l'accès aux actions struts), mais rien concernant le rendu des pages ou le filtrage des données.
Auriez vous des pistes concernant le codage des views (jsp) et code (???) dans ce cas ?
Je suis aussi preneur et on peut s'y mettre peut-être à plusieurs. Dans polen pour le moent j'ai juste utiliser les filtres shiro pour bloquer l'accès à certaines pages mais ça n'utilise pas de realm shiro (et ça devrait, idem pour l'authent). Dans l'extranet y'a des example aussi à reprendre (mais ça serait encore mieux qu'on puisse avoir le retour d'XP d'Arnaud, Brendan et Julien). Je suis volontaire pour t'aider à construire cette api. tony.
On 09/26/2012 05:20 PM, Eric Chatellier wrote:
Je ne connais pour l'instant pas du tout shiro, et je m’interroge sur la façon la plus propre de créer des interfaces web dans une lib pour l'utiliser dans une application (jsp et servlet) : si possible sans passer par des taglib.
Pas facile de proposer des composants graphiques génériques, réutilisable dans n'importe-quel framework basé sur Servlet/JSP. En gros, tu veux faire une taglib sans passer par taglib.
La persistance serait plutôt orientée ToPIA.
La librairie devra être suffisamment générique pour servir à plusieurs projets. Le but de mon application est simplement très basic, suivant les rôles de l'utilisateur, il s'agira de cacher des entrées de menu (voire limite d'interdire l'accès aux actions struts), mais rien concernant le rendu des pages ou le filtrage des données.
De mon point de vue : * Il est extrêmement prématuré étant donné notre faible expérience de Shiro (mise en oeuvre rapide dans l'extranet, pas encore en place sur Pollen) de lancer dans l'écriture d'une surchouche. * De ce que j'en ai vu, Shiro fait très bien le job. Pas besoin de surcouche. * Il me semble que faire la lib d'abord n'est pas la bonne démarche, c'est mettre la charrue avant les boeux. Il me semble qu'il faut d'abord faire quelque-chose dans le projet en lui-même, vérifier que l'approche est bonne puis plus tard, extraire s'il s'avère qu'un autre projet peut prendre appui sur l'API dégagée. Pondre une lib et considérer que c'est la bonne façon de faire parce que "ça marche sur le projet que je fais dans mon coin" c'est la meilleure façon de faire un truc qui en fait aurait du rester dans le projet client plutôt que d'en faire une lib. Cf topia-service-transformer, topia-security...
Auriez vous des pistes concernant le codage des views (jsp) et code (???) dans ce cas ?
Oui. Utiliser Shiro directement. Dans l'extranet tu as un exemple (menu de gauche, dans le template sitemesh). On verra bien après. Si, une fois que tu as terminé, tu découvres qu'il y a certaines portions de codes rébarbatives, des répétitions, des choses qu'on pourrait généraliser ou qu'on se rend compte qu'on a des portions de codes qui reviennent plusieurs fois aussi bien dans l'extranet, Pollen, ton projet, alors il sera temps de se poser la question de créer une surcouche. Donc pour moi. Utilise Shiro. Et on en reparle après. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
Le 28/09/2012 12:01, Brendan Le Ny a écrit :
La persistance serait plutôt orientée ToPIA.
La librairie devra être suffisamment générique pour servir à plusieurs projets. Le but de mon application est simplement très basic, suivant les rôles de l'utilisateur, il s'agira de cacher des entrées de menu (voire limite d'interdire l'accès aux actions struts), mais rien concernant le rendu des pages ou le filtrage des données.
De mon point de vue : * Il est extrêmement prématuré étant donné notre faible expérience de Shiro (mise en oeuvre rapide dans l'extranet, pas encore en place sur Pollen) de lancer dans l'écriture d'une surchouche.
Ca serait pas une surcouche en fait, ca serait du shiro pur mais avec une interface en plus pour la configuration en gros.
* De ce que j'en ai vu, Shiro fait très bien le job. Pas besoin de surcouche. * Il me semble que faire la lib d'abord n'est pas la bonne démarche, c'est mettre la charrue avant les boeux. Il me semble qu'il faut d'abord faire quelque-chose dans le projet en lui-même, vérifier que l'approche est bonne puis plus tard, extraire s'il s'avère qu'un autre projet peut prendre appui sur l'API dégagée.
Pondre une lib et considérer que c'est la bonne façon de faire parce que "ça marche sur le projet que je fais dans mon coin" c'est la meilleure façon de faire un truc qui en fait aurait du rester dans le projet client plutôt que d'en faire une lib. Cf topia-service-transformer, topia-security...
Le problème est que dans mon cas, si je la fait, c'est dans un projet privateur. Et a moins de négocier avec le client, il ne sera pas possible de l'extraire. Il faudra que quelqu'un d'autre la réécrive sans s'inspirer du code qui a été fait pour en "refaire" une lib libre.
Auriez vous des pistes concernant le codage des views (jsp) et code (???) dans ce cas ?
Oui. Utiliser Shiro directement. Dans l'extranet tu as un exemple (menu de gauche, dans le template sitemesh). On verra bien après.
Si, une fois que tu as terminé, tu découvres qu'il y a certaines portions de codes rébarbatives, des répétitions, des choses qu'on pourrait généraliser ou qu'on se rend compte qu'on a des portions de codes qui reviennent plusieurs fois aussi bien dans l'extranet, Pollen, ton projet, alors il sera temps de se poser la question de créer une surcouche.
Donc pour moi. Utilise Shiro. Et on en reparle après.
On vient d'en discuter, et voici quelques réflexions: * les entités topia (utilisateurs/role/permissions) ne pourront pas facilement être utilisées dans des projets qui ont leurs propres entités (ex pollen). * les lib qui fournissent des entités topia, c'est pas une bonne idée (problèmes avec la sécurité ???) * faire une lib pour 3 entités et une jsp c'est pas très utile * faire un jsp qui s'intégre super bien dans le style du projet final c'est pas évident. Au final, ca me gêne pas de faire dans le projet, mais ce que je pourrais en faire ne sera pas réutilisable. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 26/09/2012 17:20, Eric Chatellier a écrit :
Bonjour,
Je réfléchis à une librairie d'authentification et autorisation basée sur les jsp et sur shiro. Le but est de proposer: * une gestion simple d'accès à des fonctionnalités suivant un login et un role * de proposer une interface de création des utilisateurs, des roles et des permissions (matrice utilisateurs/roles) * une méthode d'authentification
Je ne connais pour l'instant pas du tout shiro, et je m’interroge sur la façon la plus propre de créer des interfaces web dans une lib pour l'utiliser dans une application (jsp et servlet) : si possible sans passer par des taglib.
La persistance serait plutôt orientée ToPIA. Une première version a été développé et présentée hier.
En résumé (de ce qui a été fait) : * librairie struts qui contient les actions (matrix de droits, creation des utilisateurs et des roles) * contient aussi les jsp de rendu, mais celle ci doivent être extraite via un maven-dependencies-plugin:unpack lors du build (donc mvn jetty:run ne fonctionne pas, il faut utiliser run-exploded) * surcharge du filtres d'init de shiro pour ajouter un royaume basé sur la persistence topia de la lib Axes d'amélioration : * La lib doit rester simple d'utilisation pour une sécurité simple * Ajouter un seul filtre pour utiliser la lib de sécurité * Supprimer le fichier shiro.ini et configurer uniquement la lib qui s'occupera de configurer les royaumes shiro * Les utilisateurs et role doivent être dynamiques, les permissions sont fixées par configuration. * Ajouter des entrées de configuration pour associer un pattern d'url à une permission (pour pouvoir cacher visuellement un lien et quand même empêcher l'accès à la page si on devine le lien) * Supprimer la dépendance à struts (filter/jsp) * (plus tard) supprimer les jsp (pour que la lib n'est pas besoin d'une configuration de build maven et soi plus simple) : template freemarker ? Exemple de configuration: org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 12/10/2012 11:07, Eric Chatellier a écrit :
Exemple de configuration: org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read org.nuiton.web.securite.permission.Rechercher=search:read Ha le mail est partit trop vite, voici un exemple de configuration:
Exemple de configuration: org.nuiton.web.securite.permission.Ajouter\ une\ tache=task:read org.nuiton.web.securite.permission.Supprimer\ une\ tache=task:delete org.nuiton.web.securite.permission.Editer\ une\ tache=task:edit org.nuiton.web.securite.permission.Administer=admin:* org.nuiton.web.securite.url.Ajouter\ une\ tache=/task/add org.nuiton.web.securite.url.Editer\ une\ tache=/task/edit org.nuiton.web.securite.url.Administer=/admin/task/**,/admin/user/**, org.nuiton.web.securite.url.Administer=/admin/task/**,/admin/user/**, -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 12/10/2012 11:14, Eric Chatellier a écrit :
Ha le mail est partit trop vite, voici un exemple de configuration:
Exemple de configuration: org.nuiton.web.securite.permission.Ajouter\ une\ tache=task:read org.nuiton.web.securite.permission.Supprimer\ une\ tache=task:delete org.nuiton.web.securite.permission.Editer\ une\ tache=task:edit org.nuiton.web.securite.permission.Administer=admin:* org.nuiton.web.securite.url.Ajouter\ une\ tache=/task/add org.nuiton.web.securite.url.Editer\ une\ tache=/task/edit org.nuiton.web.securite.url.Administer=/admin/task/**,/admin/user/**, org.nuiton.web.securite.url.Administer=/admin/task/**,/admin/user/**,
La lib est dans une version entièrement fonctionnelle. Par contre: * c'est encore une lib struts * les transactions topia sont codées à la va-vite * elle n'est pas traduite (fr) * shiro est un peu "hacké" (sentiment personnel) * le style est générique et simple (proche de l'application qui l'utilise actuellement) (il peut être style via css) Voilà, si vous pouviez faire une revu de code pour voir s'il n'y a pas une grosse erreur de conception avant la release. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
participants (3)
-
Brendan Le Ny -
Eric Chatellier -
Tony Chemit