#AUTORISER_EXPLIQUER pour obtenir les raisons d'une (non)autorisation #4983

Open
opened 2 weeks ago by JLuc · 2 comments
JLuc commented 2 weeks ago

Le besoin

Il arrive que l'autorisation ou la non autorisation ait pour conséquence l'affichage d'un message, et qu'on ait besoin pour cela de savoir la raison précise ayant conduit à cette autorisation ou non autorisation.

Par exemple pour les refus :

  • Cette partie du site est réservée aux visiteurs authentifiés. Veuillez vous connecter.
  • Votre abonnement est terminé depuis 17 jours, vous ne pouvez plus accéder à cette partie.
  • Passe ton bac d'abord !
  • Vous avez déjà posté 53 messages en moins d'une heure. On va laisser refroidir internet.

Le problème

Pour qu'un squelette SPIP fournisse ce message adapté, il doit connaître la raison précise qui motive l'autorisation ou le refus, et pour cela actuellement il faut reproduire en SPIP l'algoritme PHP déployée par autoriser et ses potentielles spécialisations et surcharges, ce qui peut donc être complexe, voire impossible puisque c'est surchargeable en PHP, et pas de base prévu en SPIP.

L'envie

Ce serait donc sympa et puissant de pouvoir savoir, en SPIP, la raison qui motive une autorisation ou une non autorisation, SANS devoir dupliquer en SPIP le code PHP qui a conduit a cette conclusion.

Les "explications" fournies pourraient être des chaines explicatives, mais aussi des noms de squelettes qui seraient chargés de fournir le feedback approprié avec sa mise en forme appropriée, [edit] ou des tableaux associatifs fournissant plus d'informations sur les circonstances qui justifient d'accorder ou non 'autorisation (détaillé plus loin.

[(#AUTORISER{voir, article, 2}|non) 
    <div class="refus">#AUTORISER_EXPLIQUER{voir,article,2}
    </div>]
[(#AUTORISER{voir, article, 2}|non) 
    <INCLURE{fond=feedback/#AUTORISER_EXPLIQUER{voir,article,2},env}>
]    

Lorsque la valeur mémorisée est un tableau associatif, cela permet d'y mettre les détails de l'expertise qui amène à finalement accorder ou non l'autorisation, comme un nouveau contexte, et de s'en servir pour délivrer le feedback sans refaire toute l'analyse (il peut rester des traitements pour la mise en forme, mais c'est simplifié).

[(#AUTORISER{voir, article, 2}|non) 
	#SET{explic,#AUTORISER_EXPLIQUER{voir,article,2}}
    <INCLURE{fond=feedback/#GET{explic/squelette},age_peremption=#GET{explic/age_peremption},type_proposition=#GET{explic/type_proposition}>
]

J'ai évoqué l'usage en SPIP mais potentiellement il peut y avoir besoin d'explications en PHP aussi.

Piste

  • le calcul d'une autorisation garde en mémoire ses résultats y compris une explication associée, fournie en plus, ou pas, par le code final qui comme actuellement renvoie true ou false.

  • une nouvelle valeur d'option de autoriser() et #AUTORISER permet de récupérer en SPIP l'explication associée à un appel précédent. Ou alors ce sont de nouvelles fonctions autoriser_expliquer() et #AUTORISER_EXPLIQUER avec la même signature que autoriser et #AUTORISER

  • c'est mémorisé dans une static locale comme $Memoization accédée via une fonction autoriser_explication().

  • Ça contient un tableau dont les index sont une signature de l'appel (un hash ?) et dont les valeurs sont un couple {résultat booléen, explication}.

  • c'est un objet avec des méthodes : set et get_explication principalement.

  • Avant de renvoyer un $ok true ou false comme actuellement, une autorisation qui veut pouvoir fournir des explications appelle autoriser_explication()->set($signature, $ok, $explication) pour mettre l'explication à disposition d'une éventuelle future demande d'explication.

  • #AUTORISER_EXPLIQUER appelle et renvoie autoriser_explication()->get_explication ($signature)

Yaurait des limites et responsabilité du squelette ou d'un PHP appelant :

  • Demander l'explication dans le même hit que l'autorisation, et faire en sorte que le résultat soit d'actualité (ou alors mémoriser de manière plus durable)
  • évidemment ça ne fournit une explication que pour les autorisations qui en fournissent une.

Nomenklatura : faut pas se mélanger entre les _expliquer et les _explication. Peut être ne retenir que _expliquer partout.

Cf initialement : https://discuter.spip.net/t/spip-zone-api-de-non-autorisation-presenter-un-refus/144812

### Le besoin Il arrive que l'autorisation ou la non autorisation ait pour conséquence l'affichage d'un message, et qu'on ait besoin pour cela de savoir la raison précise ayant conduit à cette autorisation ou non autorisation. Par exemple pour les refus : - Cette partie du site est réservée aux visiteurs authentifiés. Veuillez vous connecter. - Votre abonnement est terminé depuis 17 jours, vous ne pouvez plus accéder à cette partie. - Passe ton bac d'abord ! - Vous avez déjà posté 53 messages en moins d'une heure. On va laisser refroidir internet. ### Le problème Pour qu'un squelette SPIP fournisse ce message adapté, il doit connaître la raison précise qui motive l'autorisation ou le refus, et pour cela actuellement il faut reproduire en SPIP l'algoritme PHP déployée par autoriser et ses potentielles spécialisations et surcharges, ce qui peut donc être complexe, voire impossible puisque c'est surchargeable en PHP, et pas de base prévu en SPIP. ### L'envie Ce serait donc sympa et puissant de pouvoir savoir, en SPIP, la raison qui motive une autorisation ou une non autorisation, SANS devoir dupliquer en SPIP le code PHP qui a conduit a cette conclusion. Les "explications" fournies pourraient être des chaines explicatives, mais aussi des noms de squelettes qui seraient chargés de fournir le feedback approprié avec sa mise en forme appropriée, [edit] ou des tableaux associatifs fournissant plus d'informations sur les circonstances qui justifient d'accorder ou non 'autorisation (détaillé plus loin. ``` [(#AUTORISER{voir, article, 2}|non) <div class="refus">#AUTORISER_EXPLIQUER{voir,article,2} </div>] [(#AUTORISER{voir, article, 2}|non) <INCLURE{fond=feedback/#AUTORISER_EXPLIQUER{voir,article,2},env}> ] ``` Lorsque la valeur mémorisée est un tableau associatif, cela permet d'y mettre les détails de l'expertise qui amène à finalement accorder ou non l'autorisation, comme un nouveau contexte, et de s'en servir pour délivrer le feedback sans refaire toute l'analyse (il peut rester des traitements pour la mise en forme, mais c'est simplifié). ``` [(#AUTORISER{voir, article, 2}|non) #SET{explic,#AUTORISER_EXPLIQUER{voir,article,2}} <INCLURE{fond=feedback/#GET{explic/squelette},age_peremption=#GET{explic/age_peremption},type_proposition=#GET{explic/type_proposition}> ] ``` J'ai évoqué l'usage en SPIP mais potentiellement il peut y avoir besoin d'explications en PHP aussi. ### Piste - le calcul d'une autorisation garde en mémoire ses résultats y compris une explication associée, fournie *en plus*, ou pas, par le code final qui comme actuellement renvoie true ou false. - une nouvelle valeur d'option de `autoriser()` et `#AUTORISER` permet de récupérer en SPIP l'explication associée à un appel précédent. Ou alors ce sont de nouvelles fonctions `autoriser_expliquer()` et `#AUTORISER_EXPLIQUER` avec la même signature que `autoriser` et `#AUTORISER` - c'est mémorisé dans une static locale [comme $Memoization](https://git.spip.net/spip-contrib-extensions/memoization/src/branch/master/memoization_options.php#L234) accédée via une fonction `autoriser_explication()`. - Ça contient un tableau dont les index sont une signature de l'appel (un hash ?) et dont les valeurs sont un couple {résultat booléen, explication}. - c'est un objet avec des méthodes : `set` et `get_explication` principalement. - Avant de renvoyer un $ok true ou false comme actuellement, une autorisation qui veut pouvoir fournir des explications appelle `autoriser_explication()->set($signature, $ok, $explication)` pour mettre l'explication à disposition d'une éventuelle future demande d'explication. - `#AUTORISER_EXPLIQUER` appelle et renvoie `autoriser_explication()->get_explication ($signature)` Yaurait des limites et responsabilité du squelette ou d'un PHP appelant : * Demander l'explication dans le même hit que l'autorisation, et faire en sorte que le résultat soit d'actualité (ou alors mémoriser de manière plus durable) * évidemment ça ne fournit une explication que pour les autorisations qui en fournissent une. **Nomenklatura** : faut pas se mélanger entre les `_expliquer` et les `_explication`. Peut être ne retenir que `_expliquer` partout. Cf initialement : https://discuter.spip.net/t/spip-zone-api-de-non-autorisation-presenter-un-refus/144812
b_b added the
amélioration
label 2 weeks ago
b_b commented 2 weeks ago
Owner

Je ne colle pas de jalon mais je pense que c'est un truc pour la 5.0 ou plus tard, surtout car je n'ai pas vraiment compris le besoin et la manière d'y répondre.

L'exemple #AUTORISER{voir, article, 2} que tu donnes peut avoir autant d'explications que d'usages, suivant le site elle peut remplier au moins les deux conditions que tu donnes en exemple dans l'intro. Ce qui me fait penser que l'explication est dépedante de comment et pourquoi la personnne utilise l'autorisation dans son code. Mais, si le mécanimes que tu envisages permet de surcharger les explications, comme c'est le cas pour les autorisations, çe fera le job. Par contre, ça impliquerait de définir des explications pour toutes les autorisations existantes dans le core et les plugins, et en plus de les traduire, sacré chantier...

Je ne colle pas de jalon mais je pense que c'est un truc pour la 5.0 ou plus tard, surtout car je n'ai pas vraiment compris le besoin et la manière d'y répondre. L'exemple `#AUTORISER{voir, article, 2}` que tu donnes peut avoir autant d'explications que d'usages, suivant le site elle peut remplier au moins les deux conditions que tu donnes en exemple dans l'intro. Ce qui me fait penser que l'explication est dépedante de comment et pourquoi la personnne utilise l'autorisation dans son code. Mais, si le mécanimes que tu envisages permet de surcharger les explications, comme c'est le cas pour les autorisations, çe fera le job. Par contre, ça impliquerait de définir des explications pour toutes les autorisations existantes dans le core et les plugins, et en plus de les traduire, sacré chantier...
Poster

OUI ça dépend complètement du code sur un site donné, et c'est donc aux squelettes d'un site, aux surcharges des autorisations standards ou aux nouvelles autorisations définies, de mettre en définir ces explications et de les utiliser. Ou aux plugins qui définissent des autorisations, lorsque c'est approprié.

Pour spip-dist, les situations d'autorisations sont simples et trés facile à traiter en SPIP. Il suffit d'un [(#AUTORISER{article,voir,2}|non) Désolé non pas vous], il n'y a donc pas de raison d'utiliser ce mécanisme et donc NON ça n'implique pas de définir des explications pour les autorisations du core et des plugins et de les traduire.

Mais l'examen PHP d'une demande d'autorisation est parfois complexe et requière la prise en compte de plusieurs facteurs et conditions, seuils, statuts, taux, âges, dates, etc. Et pour fournir l'explication au résultat de ce calcul actuellement, cf plus haut : « il faut reproduire en SPIP l'algoritme PHP déployée par autoriser et ses potentielles spécialisations et surcharges, ce qui peut donc être complexe, voire impossible puisque c'est surchargeable en PHP, et pas de base prévu en SPIP. ». Alors dans ce cas d'autorisations non triviales, c'est intéressant de ne pas refaire en SPIP ce même examen.

Pour les squelettes concernés, l'évaluation de ces autorisations passe nécessairement par la création de nouvelles autorisations ou par la surcharge des autorisations -dist, ce qui permet à cette même occasion d'utiliser le mécanisme de mémorisation de l'explication pour la réutiliser dans le squelette qui en a besoin.

OUI ça dépend complètement du code sur un site donné, et c'est donc aux squelettes d'un site, aux surcharges des autorisations standards ou aux nouvelles autorisations définies, de mettre en définir ces explications et de les utiliser. Ou aux plugins qui définissent des autorisations, lorsque c'est approprié. Pour spip-dist, les situations d'autorisations sont simples et trés facile à traiter en SPIP. Il suffit d'un `[(#AUTORISER{article,voir,2}|non) Désolé non pas vous]`, il n'y a donc pas de raison d'utiliser ce mécanisme et donc NON ça n'implique pas de définir des explications pour les autorisations du core et des plugins et de les traduire. Mais l'examen PHP d'une demande d'autorisation est parfois complexe et requière la prise en compte de plusieurs facteurs et conditions, seuils, statuts, taux, âges, dates, etc. Et pour fournir l'explication au résultat de ce calcul actuellement, [cf plus haut](https://git.spip.net/spip/spip/issues/4983#user-content-le-probl%C3%A8me) : « il faut reproduire en SPIP l'algoritme PHP déployée par autoriser et ses potentielles spécialisations et surcharges, ce qui peut donc être complexe, voire impossible puisque c'est surchargeable en PHP, et pas de base prévu en SPIP. ». Alors dans ce cas d'autorisations non triviales, c'est intéressant de ne pas refaire en SPIP ce même examen. Pour les squelettes concernés, l'évaluation de ces autorisations passe nécessairement par la création de nouvelles autorisations ou par la surcharge des autorisations -dist, ce qui permet à cette même occasion d'utiliser le mécanisme de mémorisation de l'explication pour la réutiliser dans le squelette qui en a besoin.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.