Project

General

Profile

Development #38079

Forcer l'authentification sur un brouillon auquel un utilisateur est attaché.

Added by Nicolas Roche 8 months ago. Updated 5 months ago.

Status:
Solution proposée
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
29 Nov 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

reprend le patch proposé dans #37095

0001-forms-force-authentication-on-user-drafts-38079.patch View (5.85 KB) Nicolas Roche, 29 Nov 2019 03:01 PM

0002-forms-enforce-authentication-on-user-drafts-38079.patch View (3.78 KB) Nicolas Roche, 29 Nov 2019 05:18 PM

0001-forms-force-authentication-if-anonymous-use-user-tra.patch View (8.08 KB) Nicolas Roche, 08 Jan 2020 03:12 PM

0002-forms-force-authentication-if-using-another-user-s-t.patch View (4.56 KB) Nicolas Roche, 11 Feb 2020 02:27 PM

0003-tracking_code-correct-tests-on-formdata-access-38073.patch View (3.1 KB) Nicolas Roche, 11 Feb 2020 02:27 PM

0001-tracking_code-add-tests-on-formdata-access-38073.patch View (17.1 KB) Nicolas Roche, 11 Feb 2020 02:27 PM

0001-forms-force-authentication-if-using-another-user-s-t.patch View (4.55 KB) Nicolas Roche, 12 Feb 2020 12:05 PM


Related issues

Related to w.c.s. - Development #38077: Accès aux brouillons via le code de suivi Nouveau 29 Nov 2019

History

#1 Updated by Nicolas Roche 8 months ago

Première version :
ne pas autoriser un utilisateur non connecté à charger un code de suivi associé à un utilisateur.

#2 Updated by Nicolas Roche 8 months ago

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.

#3 Updated by Nicolas Roche 8 months ago

#4 Updated by Thomas Noël 8 months ago

Selon moi ça ne va pas marcher dans le cadre d'un SSO :
  1. je suis connecté wcs via SSO, donc j'ai une session sur l'IDP
  2. je veux aller sur un brouillon qui appartient à qqun d'autre
  3. je suis renvoyé sur login (dans l'idée que je dois changer de user)
  4. login me renvoie vers l'IdP
  5. j'ai une session sur l'IdP : il répond immédiatement et me renvoie sur le formulaire
  6. 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).

#5 Updated by Nicolas Roche 7 months ago

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 :

  1. je suis connecté wcs via SSO, donc j'ai une session sur l'IDP
  2. je veux aller sur un brouillon qui appartient à qqun d'autre (appel à load)
  3. je suis renvoyé sur login (dans l'idée que je dois changer de user)
  4. login me renvoie vers l'IdP
  5. j'ai une session sur l'IdP : il répond immédiatement et me renvoie sur le formulaire
  6. j'accède directement à la ressource
  7. l'accès m'est interdit : page d'interdiction WCS qui invite à retourner sur l'acceuil

#6 Updated by Thomas Noël 7 months ago

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 :

  1. je suis connecté wcs via SSO, donc j'ai une session sur l'IDP
  2. je veux aller sur un brouillon qui appartient à qqun d'autre (appel à load)
  3. je suis renvoyé sur login (dans l'idée que je dois changer de user)
  4. login me renvoie vers l'IdP
  5. j'ai une session sur l'IdP : il répond immédiatement et me renvoie sur le formulaire
  6. j'accède directement à la ressource
  7. 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.

#7 Updated by Nicolas Roche 7 months ago

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

#8 Updated by Thomas Noël 7 months ago

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é.

#9 Updated by Nicolas Roche 6 months ago

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)

#11 Updated by Frédéric Péters 5 months ago

(tu peux ne pas attacher les patchs qui sont à ignorer)

Also available in: Atom PDF