Accorder ou non une autorisation peut reposer sur des raisons multiples,
dues au statut de l'internaute, à ses droits spécifiques,
ou dues au statut de l'objet ou à d'autres de ses propriétés,
et souvent c'est un mix des 2.
Parfois la décision peut être assez complexe
et nécessiter l'examen de toute une arborescence de possibilités.
Au final l'API des autorisations qui font ce boulot
indique si OUI ou NON l'autorisation est accordée,
mais comment faire pour expliquer un refus
lorsque l'autorisation n'est pas accordée ?
Parfois il suffit de ne pas présenter le bouton, ou l'option du menu,
ou de ne pas afficher le texte protégé, ou de ne rien faire...
mais parfois il faut motiver le rejet de la demande
(article périmé, droits insuffisants, etc).
Parfois aussi, il faut inviter l'internaute
à satisfaire quelque condition pré-requise :
basiquement l'inviter à se connecter, s'il ne l'est pas,
ou à acheter le service désiré, si c'est un service payant.
Mais pour présenter un texte explicatif après avoir déterminé la non autorisation,
il faut refaire tous les tests.
On ne peut employer les fonctions d'autorisations cette fois ci
car on ne veut pas un booléen.
Il faut donc une nouvelle structure en parallèle avec la première
et qui refasse exactement le même cheminement,
mais pour aboutir non à un booléen mais à un texte :
un code de refus ou un morceau de html.
Il y a 1 ou 2 ans, j'avais commencé une modification du mécanisme
d'autorisation qui permettait optionnellement
de récupérer un texte d'explication (motif de refus) au lieu d'un booléen.
Mais je n'ai pas poursuivi ainsi.
Actuellement, alors que les autorisations sont en php,
j'ai codé cette autre structure en squelettes SPIP.
C'est pas satisfaisant toutefois de devoir dupliquer l'arborescence des tests
- que ce soit en php ou en SPIP -
car il est plus difficile de se prémunir d'un décalage
entre le calcul de l'autorisation
et le calcul de son explication.
En fait, plus qu'une API d'autorisation,
c'est peut être une API de non-autorisation qu'il faudrait utiliser.
Celle-ci renverrait "false" en cas d'autorisation,
et en cas de refus, elle renverrait une chaine ou une structure de donnée fournissant
le motif de refus.
Elle aurait les mêmes possibilités de spécialisation par action et par type d'objet,
et de surcharge en plugins, que l'API d'autorisation.
Et il n'y aurait plus besoin de l'API d'autorisation.
Êtes vous confronté aussi à cette problématique
et à quelles solutions avez vous recours ?
JL