Re: API autoriser

Le 24/11/2015 20:01, David Fredette a écrit :
>> En fait j'ai vraiment l'impression que tu veux étendre ce que fait la
>> Fabrique (qui est largement basée du plugin Autorité que mentionne Fil)
>
> Alors il me manque une référence sur ce que fait le plugin autorité …
> Parce que de ce que j’ai lu sur ce plugin moi ça ne me semble pas avoir
> la même souplesse…
>
> De ce que je comprends d’autorité (mais je peux me tromper, corrigez-moi
> si je me trompes) , il permet d’ajouter des droits et tout autant de
> fonction a écrire en fonction de ce qu’on veut surcharger tout en
> utilisant le modèle de base de spip actuel…
>
> Moi, c’est un peu ce modèle de base que je veux revoir ! :P

Salut David,

Perso, je pense que Gilles mélange un peu tout. :D

Autorité est un plugin qui prévoit EN DUR des autorisations précises, et 
qui proposent de les configurer dans un formulaire : mais parce que des 
développeureuses ont listé des cas d'utilisation précis déjà reconnus 
comme étant utiles. Tout est déjà pré-défini.

Cela n'a donc rien à voir, d'après moi, avec l'aspect générique que tu 
cherches.

Quant à La Fabrique, ça permet, à partir d'un gros formulaire de config, 
de générer des fichiers PHP/HTML "en dur" aussi, qui ne bougent plus 
ensuite. Donc là non plus je ne vois pas le rapport avec ton besoin 
décrit au départ…

Toi ce que tu cherches à faire, c'est programmer un système de rôles 
(Role-based access), on ne réinvente pas la roue : c'est un "design 
pattern" connu en architecture de l'information :
https://fr.wikipedia.org/wiki/Contr%C3%B4le_d'acc%C3%A8s_%C3%A0_base_de_r%C3%B4les

Le principe de ce modèle de conception est :
- avoir une liste d'autorisations possibles
- avoir une liste de rôles (ici les statuts d'utilisateurs à priori)
- avoir un tableau (peu importe son stockage, table, fichier, autre) qui 
met en lien les rôles et les autorisations

(Comme dans Redmine par exemple, où on a un grand tableau-croisé plein 
de cases à cocher.)

C'est un serpent de mer qui ressort régulièrement dans SPIP, car ce 
dernier ne propose que des cas d'utilisations simples par défaut (et qui 
suffisent dans la très grand majorité des cas, possiblement plus que 
80%). Si ça revient souvent mais que ça n'a jamais été fait : une des 
possibilités c'est que ça n'est pas utile à tant de monde que ça IRL. :)

Dans tous les cas, à mon avis, que ce soit à terme intéressant de 
l'intégrer au noyau ou pas : tu devrais commencer en plugin. Ce qui 
n'empêche pas de réfléchir dès le début à la meilleure nomenclature 
possible pour les noms de tableaux à déclarer, les pipelines, etc, etc.

Faire un plugin permet de réellement voir si ça marche, de lister s'il 
manque des ouvertures dans le noyau (peut-être mais même pas sûr), etc, 
et de discuter aussi bien des API que des interfaces en ayant un truc 
concret sous les yeux, pas juste des besoins abstraits.

À priori :
- le pipeline "lister_objet_sql" te permet déjà de rajouter ce que tu 
veux pour tous les objets du noyau, y compris donc des clés dédiées pour 
l'autorisation
- la fonction autoriser() est "dist", donc surchargeable, donc ton 
plugin peut la réécrire entièrement à zéro

Pour finir, j'ajouterais quand même qu'il y a de nombreuses difficultés 
sur le chemin :

- est-ce que ça doit rester *aussi* compatible avec le système de 
fonctions, quand on décide d'en écrire en dur ? (et le cas échéant, 
laquelle des méthodes est prioritaire ?)

- dans la réalité de la vraie vie réelle, les choses ne se limite PAS à 
"j'ai tel rôle" + "j'ai telle autorisation *simple*" : en effet il y a 
des autorisations (d'ors et déjà existantes !) qui sont BEAUCOUP plus 
complexes que juste "j'ai le droit de modifier l'article parce que je 
suis admin" !
D'ailleurs tu vois bien que l'API actuelle n'a pas du tout que les TROIS 
paramètres :
- quelle autorisation
- quel objet
- quel statut d'utilisateur
Non actuellement on a :
- quelle autorisation
- quel objet
- quel objet PRÉCIS (son id)
- quel utilisateur EN GÉNÉRAL (son statut mais aussi tout autre infos !)
- un tableau d'options LIBRES qui peut contenir n'importe quelles infos 
nécessaires en plus !


Des exemples ?

1) J'ai le droit de modifier TEL article (123 par ex) parce que je fais 
partie des auteurs *liés* à cet article (peu importe mon statut !)

2) J'ai le droit de faire telle chose parce que j'ai contribué à plus de 
20 contenus dans le site.

3) J'ai des autorisations avec des *options* (libres !) qui peuvent 
contenir n'importe quelles infos supplémentaires.
Par exemple le statut *demandé* pour un objet quand on veut changer son 
statut. Avec une autorisation qui serait du type : "J'ai le droit de 
passer le statut de 'redac' à 'prop' pour TEL article, mais PAS de le 
passer en 'publie'"
(Pour ce genre de cas, Redmine pour les statuts des tickets a un 
*deuxième* GROS tableau qui dit que quand on a tel rôle, et que le 
statut en place est XXX, j'ai le droit de le modifier pour tels et tels 
autres statuts. C'est dans une page d'admin qui s'appelle "Workflow" je 
crois. => Ça augmente encore le nombre de tableaux-clicodrômes)

Bref, je peux en lister plein, des cas bien plus compliqués que "juste 
avoir tel rôle".
Tout ça est donc encore à réfléchir… :D

-- 
RastaPopoulos