Re: API Autoriser ! ;)
Cédric Morin <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello David, bravo et merci pour tous ces efforts et cette piste d'évolution. Sur le fond je souhaite quand même attirer ton attention sur un point : les fonctions d'autorisation existante ne sont pas simplement des fonctions de vérification de droit lié à l'auteur connecté, mais aussi/surtout (selon les cas) des fonctions qui intègrent la logique métier propre à SPIP. Par exemple : La previsu liée à un token : https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/autoriser.php#L292 La traduction https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/autoriser.php#L398 Le datage d'un objet https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/autoriser.php#L466 La suppression d'une rubrique https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/autoriser.php#L614 etc etc (je n'ai regardé que les premières fonctions du fichier). La solution que tu décris ne peut donc pas remplacer brutalement les fonctions existantes sauf à perdre totalement cette logique métier. Peut-être serait-il possible de faire un plugin fonctionnel avec un peu d'astuce en surchargeant la fonction autoriser() point d'entrée de l'API pour prendre la main qui ferait : - vérification des droits de l'utilisateur via ta couche ACL - upgrade temporaire des droits de l'utilisateur courant comme webmestre (on fake le 'qui' de autoriser) - appel de la fonction autoriser via mécanisme de autoriser_dist actuel, qui normalement ne devrait pas buter sur un refus lié au faux 'qui' webmestre, mais uniquement se baser sur les règles métiers pour autoriser/refuser le droit - faire un ET entre les 2 autorisations et retourner le résultat C'est un petit bricolage et il n'est pas certain que ça fonctionne totalement. Je pense à certains droits qui seraient reservés aux visiteurs, au rédacteurs ou aux admins restreints, c'est en théorie possible qu'il y en ait mais j'ai pas d'exemple précis en tête. Il faudra traiter ces cas là au coup par coup en fonction des retours de bug. Si on voit plus loin pour une éventuelle intégration propre, il faudrait commencer par découper les fonctions autoriser en 2 en séparant la partie métier de la partie ACL, pour pouvoir ensuite remplacer la partie ACL par ta proposition d'évolution (que ce soit en plugin ou directement dans le core ne change rien). C'est clairement une évolution assez majeure à réfléchir murement. Si on s'y prend bien pour que ce soit une structuration possible mais non obligatoire qui continue de fonctionner avec l'existant, ce peut-être quelque chose qu'on introduirait dans la 3.2 (la découpe en 2 couches). Il faudra ensuite qu'elle soit releasée, puis que ce découpage soit propagé dans tous les plugins importants (ou concernés). Tout ça est donc à l'échelle de mois, voir d'années avant qu'une migration vers ta solution d'ACL soit intégrable de manière robuste et satisfaisante. Voilà pour les enjeux et pour mes réflexions sur le sujet. A te lire -- Cédric David Fredette a écrit : > Bonjour la liste… > > Je repars sur une discussion que j'avais lancé il y a 8… Peut-être 10 > mois ! ;) > > JE parlais entre autre de peut-être revoir le principe d'autorisation de > SPIP pour pouvoir assigner des droits directement a un utilisateur… > > Je n'ai pas donné de nouvelles depuis, puisque les choses étant ce > qu'elles sont, parfois le temps manque… Mais bon, comme j'ai 3 projets > cette automne ou cette façon de faire va être importante, je me suis > lancé un peu plus a fond dans le développement de ce plugin… > > J'ai pris pas mal de note au cours du développement basique et pour le > moment, c'est sur le principe fonctionnel de la chose, il reste encore > beaucoup a faire, mais avant d'être rendu trop loin, j'aimerais avoir > votre avis sur ce qui a été fait question que j'oriente le tout le mieux > possible et que si j'ai déjà des erreur grossière, je puisse déjà les > corriger avant d'être rendu trop loin… > > Le lien vers ma doc : > > Le lien vers ce que j'ai de fait pour mon plugin : > http://www.visioninfo.qc.ca/spip_plugins/droits_autorisations/droits_et_autorisations.pdf > > Ça devrait aider aussi certains a mieux visualiser ce que je voulais > faire ! :) > http://www.visioninfo.qc.ca/spip_plugins/droits_autorisations/droits_autorisations.zip > > Merci ! :) > > David Fredette > "La technologie n'est qu'un outil, c'est l'utilisateur qui lui donne un > sens." > - Pierre Frackowiak - > > > > > _______________________________________________ > liste: http://listes.rezo.net/mailman/listinfo/spip-dev > doc: http://www.spip.net/ > dev: http://trac.rezo.net/trac/spip/ > irc://irc.freenode.net/spip _______________________________________________ liste: http://listes.rezo.net/mailman/listinfo/spip-dev doc: http://www.spip.net/ dev: http://trac.rezo.net/trac/spip/ irc://irc.freenode.net/spip