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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.