Project

General

Profile

Development #67986

Valeurs prédéfinies pour les conditions d'affichage des moyens d'authentification

Added by Frédéric Péters 12 days ago. Updated 7 days ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05 August 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Aujourd'hui on a une saisie libre d'une condition et le jeu est de chercher dans quelques déploiements pour copier/coller une condition qui correspond, type 'backoffice' in login_hint or remote_addr in dnsbl('ddns.entrouvert.org').

Je pense qu'on pourrait gagner à avoir au niveau de l'interface des valeurs prédéfinies, "accès back uniquement", "accès front uniquement", en plus d'une option "autre:" qui serait la saisie libre.

Je me dis que ça pourrait passer par deux fonctions supplémentaires, que les conditions pourraient ainsi être écrites is_for_backoffice() / is_for_frontoffice(), et ces fonctions regarderaient dans les settings pour avoir la condition à tester; ex:

A2_WHATEVER = {
   "backoffice": "'backoffice' in login_hint or remote_addr in dnsbl('ddns.entrouvert.org')",
   "frontoffice": "'backoffice' in login_hint or remote_addr in dnsbl('ddns.entrouvert.org')",
}

Ça permet

  • 1/ comme paramètre d'avoir très souvent quelque chose de simple et unique, is_for_backoffice(),
  • 2/ et donc dans l'UI d'avoir ces deux cas gérés via <select>,
  • 3/ d'adapter la condition quand ce qui nous correspond évolue, par exemple si on veut ajouter or 'X-Entrouvert' in headers.
  • 4/ d'enfin obtenir une configuration identique partout.

History

#1

Updated by Benjamin Dauvergne → en congés jusqu'au 29/08 12 days ago

Ça me semble un peu compliqué d'introduire des fonctions avec des noms qu'on sera les seuls à connaître. Je suis plutôt pour le même setting mais avoir directement une combo box [Backoffice, Frontoffice, Condition libre...] avec condition libre qui active l'affichage du charfield actuel, un peu comme dans w.c.s. pour le même genre de chose.

(Je comprends du point 2/ que c'est l'idée mais au point 1/ l'introduction de ce is_for_backoffice() m'a perdu)

#2

Updated by Frédéric Péters 12 days ago

Mon idée de la fonction était ainsi de ne pas toucher au modèle de données, que ça pouvait se gérer totalement côté UI.

Sinon, tes choix "front" / "back", il sont inscrits comment dans la db ?

Si ça n'est pas un nouveau champ dans le modèle, que ça stocke juste la valeur posée en settings, ex: 'backoffice' in login_hint, comme ça évolue tout seul quand on modifie les settings ?

(j'ai peut-être une frilosité à la modification des modèles que tu n'as pas).

#3

Updated by Benjamin Dauvergne → en congés jusqu'au 29/08 12 days ago

Frédéric Péters a écrit :

Mon idée de la fonction était ainsi de ne pas toucher au modèle de données, que ça pouvait se gérer totalement côté UI.

Sinon, tes choix "front" / "back", il sont inscrits comment dans la db ?

Je ne pense pas qu'on ait besoin de toucher au modèle de donnée, au sens schéma des modèles, il suffit de mettre une chaîne qui soit une expression invalide en python genre '=is_in_backoffice'.

(j'ai peut-être une frilosité à la modification des modèles que tu n'as pas).

Non j'ai la même.

#4

Updated by Frédéric Péters 7 days ago

Je ne pense pas qu'on ait besoin de toucher au modèle de donnée, au sens schéma des modèles, il suffit de mettre une chaîne qui soit une expression invalide en python genre '=is_in_backoffice'.

Mais ça oblige de retomber sur du grep à la recherche de l'expression qu'il faudrait quand on veut combiner, pour par exemple écrire 'backoffice' not in login_hint and 'hobo-tao-thononagglo' not in service_ou_slug", qui aurait pu s'écrire is_for_frontoffice() and 'hobo-tao-thononagglo' not in service_ou_slug".

Perso je vois un attrait à pouvoir se dire que toujours la valeur de show_condition sera une expression, ne pas avoir à y ajouter une gestion de certaines valeurs "magiques".

Also available in: Atom PDF