Produits Entr'ouvert » Authentic 2

Push your branch.

Tu ne peux pas vérifier le niveau d'authentification par rapport à l'utilisateur, c'est une donnée transitoire ça doit venir de la session, après l'utilisateur peut avoir un niveau d'authentification minimum mais c'est uniquement pour bloquer l'authentification.

Benjamin Dauvergne a écrit :

Tu ne peux pas vérifier le niveau d'authentification par rapport à l'utilisateur, c'est une donnée transitoire ça doit venir de la session, après l'utilisateur peut avoir un niveau d'authentification minimum mais c'est uniquement pour bloquer l'authentification.

J'avais fait l'erreur au début, mais normalement ce n'est plus le cas, après c'est pas exclu qu'il reste un morceau de code égaré qui le laisse penser. (si le pb c'était que c'est transitoire encore il y aurait des moyens de contournement, mais le vrai pb c'est qu'un utilisateur peut avoir plusieurs sessions, et là c'est vraiment foutu)
Tu dois pas en être encore à ce commit mais ce qu'il se passe c'est que j'annote request.user avec le niveau d'auth qui est dans la session via un décorateur, donc l'attribut user.auth_level dans django_rbac vient bien de la session.

Mise à jour avec un peu de nettoyage et des gros bouts qu'il manquait.

Valentin Deniaud a écrit :

Ce qu'il reste à faire :

• réfléchir au mécanisme qui permettra d'activer l'authentification forte au niveau utilisateur comme dit dans le ticket

Fait. La manière dont c'est implémenté : un utilisateur est libre d'aller activer un facteur d'auth supplémentaire à tout moment dans son profil a2. Si il tombe sur une page qui déclenche une montée d'auth et qu'il a configuré un facteur qui lui permet de l'effectuer, c'est bon. Sinon, il est redirigé vers son profil, obligé de configurer un nouveau facteur puis de s'authentifier avec valider l'activation. Puis redirection vers la page initiale une fois fini.

• faire en sorte qu'on puisse associer facilement via l'interface d'admin des backends à un niveau d'authentification (là le niveau d'un backend est codé en dur, c'est nul)

J'ai essayé et c'est pas super joli (tout tient dans a3b17be0). Peut-être que vouloir faire ça sert pas à grand chose au final, et qu'on peut se contenter de faire cette association de manière plus statique dans un fichier de conf ?

• tests, traductions, logging, pep8
• améliorations de l'interface

Avant de m'attaquer à ces deux derniers points, dont l'achèvement doit conduire à commencer à merger des trucs, il faudrait que l'on me dise si les nouveaux mécanismes mis en place dans ce ticket conviennent (que je n'écrive pas des tests pour du code qui sera jeté au final, par ex).
Notamment le moment où on effectue la vérification du niveau d'authentification d'un utilisateur bien profond dans django_rbac (93f12678, accompagné de 94766b5c).

Un autre truc qu'il reste à faire, auquel je m'attaque en attendant, c'est de gérer la multitude de cas où il faut peut-être afficher un bouton, peut-être pas, idéalement sans ajouter 400 if/else.

il faudrait que l'on me dise si les nouveaux mécanismes mis en place dans ce ticket conviennent.

Sur ce ticket précis je n'ai pas regardé.

Mais sur l'ensemble, ceci est mon opinion, les intrusions dans le code des autres applications m'ennuient. Ça n'empêche pas qu'il y a utilité à avoir dans authentic la gestion de multi-facteurs, mais à mon sens plutôt comme ça peut exister ailleurs, pour offrir à l'usager la possibilité de sécuriser ses accès.

C'est-à-dire, par rapport à ce que tu écris, "Si il tombe sur une page qui déclenche une montée d'auth", que cette partie resterait de côté pour le moment, que "aller activer un facteur d'auth supplémentaire à tout moment dans son profil a2" serait + "et demander à ce que facteur soit demandé lors des connexions à son compte".

Bref, pour redire la même chose encore une fois, il y a une partie multi-facteurs qui serait super et pourrait être utile dans authentic, mais la partie dans les autres applications est une trop grosse fiction aujourd'hui pour aller y faire des changements.

Répondu dans #32786 (btw le présent ticket ne concerne que le fonctionnement interne à a2).