Development #38079
Forcer l'authentification sur un brouillon auquel un utilisateur est attaché.
0%
Fichiers
Demandes liées
Historique
Mis à jour par Nicolas Roche il y a plus de 4 ans
- Fichier 0001-forms-force-authentication-on-user-drafts-38079.patch 0001-forms-force-authentication-on-user-drafts-38079.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Première version :
ne pas autoriser un utilisateur non connecté à charger un code de suivi associé à un utilisateur.
Mis à jour par Nicolas Roche il y a plus de 4 ans
- Fichier 0002-forms-enforce-authentication-on-user-drafts-38079.patch 0002-forms-enforce-authentication-on-user-drafts-38079.patch ajouté
- Statut changé de En cours à Solution proposée
dans #37095 :
Il restera le cas d'un brouillon commencé non connecté et repris en mode connecté
Pour moi tout ça découle d'un cas plus général :
celui d'un brouillon repris en mode connecté par un autre utilisateur que celui qui l'a commencé (connecté ou pas).
Sauf que cela entraîne une régression :
les agents utilisant un code de suivi pour accéder à une demande sont à présent redirigés en backoffice.
Mis à jour par Nicolas Roche il y a plus de 4 ans
- Lié à Development #38077: Accès aux brouillons via le code de suivi ajouté
Mis à jour par Thomas Noël il y a plus de 4 ans
- je suis connecté wcs via SSO, donc j'ai une session sur l'IDP
- je veux aller sur un brouillon qui appartient à qqun d'autre
- je suis renvoyé sur login (dans l'idée que je dois changer de user)
- login me renvoie vers l'IdP
- j'ai une session sur l'IdP : il répond immédiatement et me renvoie sur le formulaire
- et donc je reviens sur l'étape 2 : ça boucle
Bref, le seul cas où ça marche c'est quand je ne suis pas encore loggué (le cas codé actuellement).
Mis à jour par Nicolas Roche il y a plus de 4 ans
Effectivement, le login ne force pas les utilisateurs déjà authentifiés à se reloguer.
La redirection est mise en place dans wcs/forms/root.py::TrackingCodeDirectory::load(). Ce que je constate à l'usage (entre 2 usagers) c'est :
- je suis connecté wcs via SSO, donc j'ai une session sur l'IDP
- je veux aller sur un brouillon qui appartient à qqun d'autre (appel à load)
- je suis renvoyé sur login (dans l'idée que je dois changer de user)
- login me renvoie vers l'IdP
- j'ai une session sur l'IdP : il répond immédiatement et me renvoie sur le formulaire
- j'accède directement à la ressource
- l'accès m'est interdit : page d'interdiction WCS qui invite à retourner sur l'acceuil
Mis à jour par Thomas Noël il y a plus de 4 ans
Nicolas Roche a écrit :
Effectivement, le login ne force pas les utilisateurs déjà authentifiés à se reloguer.
La redirection est mise en place dans wcs/forms/root.py::TrackingCodeDirectory::load(). Ce que je constate à l'usage (entre 2 usagers) c'est :
- je suis connecté wcs via SSO, donc j'ai une session sur l'IDP
- je veux aller sur un brouillon qui appartient à qqun d'autre (appel à load)
- je suis renvoyé sur login (dans l'idée que je dois changer de user)
- login me renvoie vers l'IdP
- j'ai une session sur l'IdP : il répond immédiatement et me renvoie sur le formulaire
- j'accède directement à la ressource
- l'accès m'est interdit : page d'interdiction WCS qui invite à retourner sur l'acceuil
C'est exactement ce que j'ai décrit ci-dessus, hein. Donc, faut rien faire, juste refuser l'accès dans ce cas.
Mis à jour par Nicolas Roche il y a plus de 4 ans
oui et non,
<<< 6. et donc je reviens sur l'étape 2 : ça boucle --- 6. j'accède directement à la ressource >>>
il y a bien un aller retour sur l'IDP mais pas de boucle
Mis à jour par Thomas Noël il y a plus de 4 ans
Nicolas Roche a écrit :
oui et non,
[...]
il y a bien un aller retour sur l'IDP mais pas de boucle
Je veux dire : ça change pas le user. On revient sur wcs sans que rien n'ai changé. Bref, on peut pas changer de user, et comme dit en réunion de lundi, sur les brouillons, c'est pas grave, c'est même mieux. Un brouillon attaché à un user ne doit rester accessible qu'à celui-ci (donc soit il est déjà loggué et ça passe, soit il n'est pas loggué et on force le log avec un retour vers le formulaire). On revient donc à l'essence du ticket : forcer l'auth sur un brouillon auquel un utilisateur est attaché.
Mis à jour par Nicolas Roche il y a plus de 4 ans
- Fichier 0001-forms-force-authentication-if-anonymous-use-user-tra.patch 0001-forms-force-authentication-if-anonymous-use-user-tra.patch ajouté
rebasé, pour alimenter la discussion sur le problème de pré-remplissage des champs.
(juste pour information, ce patch n'est pas sensé être poussé en l'état)
Si la demande a été initialisée par un utilisateur, on force la connexion avec cet utilisateur ; si un autre utilisateur est déjà logué, alors on affiche une page d'erreur : "Accès interdit".
Si la demande a été initialisée anonymement, pas de changement : on pré-rempli avec les champs de l'utilisateur actuellement en session.
(et donc potentiellement avec des données propres aux agents)
Mis à jour par Nicolas Roche il y a environ 4 ans
- Fichier 0003-tracking_code-correct-tests-on-formdata-access-38073.patch 0003-tracking_code-correct-tests-on-formdata-access-38073.patch ajouté
- Fichier 0002-forms-force-authentication-if-using-another-user-s-t.patch 0002-forms-force-authentication-if-using-another-user-s-t.patch ajouté
- Fichier 0001-tracking_code-add-tests-on-formdata-access-38073.patch 0001-tracking_code-add-tests-on-formdata-access-38073.patch ajouté
Rebasé en retirant mes tests : seul 0002 sera éventuellement poussé.
Mis à jour par Frédéric Péters il y a environ 4 ans
(tu peux ne pas attacher les patchs qui sont à ignorer)
Mis à jour par Nicolas Roche il y a environ 4 ans
- Fichier 0001-forms-force-authentication-if-using-another-user-s-t.patch 0001-forms-force-authentication-if-using-another-user-s-t.patch ajouté
ok
Mis à jour par Frédéric Péters il y a plus de 3 ans
- Statut changé de Solution proposée à Fermé
Je ferme tout ça parce que mélangé sur cinq tickets, se partageant plus de 50 commentaires, et que je ne vois pas où ça mène.