Project

General

Profile

Development #27823

Avertir par courriel l'utilisateur lorsqu'il demande la suppression de son propre compte

Added by Paul Marillonnet 9 months ago. Updated 2 days ago.

Status:
En cours
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
07 Nov 2018
Due date:
% Done:

0%

Patch proposed:
No
Planning:
No

Description

Avec donc une suppression en deux temps :
- l'usager demande la suppression de son compte.
- l'usager reçoit par courriel une URL opaque de confirmation de la suppression de son compte.

La validité de l'URL pourrait être limitée dans le temps, par exemple 48h.


Related issues

Related to Authentic 2 - Development #26910: La suppression d'un utilisateur par lui même doit provoquer l'envoi d'un mail de notification Solution déployée 02 Oct 2018

History

#1 Updated by Paul Marillonnet 9 months ago

  • Related to Development #26910: La suppression d'un utilisateur par lui même doit provoquer l'envoi d'un mail de notification added

#2 Updated by Thomas Noël 9 months ago

A noter qu'actuellement on demande le mot de passe pour valider la suppression, cette étape devra être supprimée (parce que si la personne a accès à son mail, elle peut changer le mot de passe, donc cette vérif du pass devient inutile)

#3 Updated by Paul Marillonnet 3 days ago

Je verrais bien un nouveau modèle pour stocker cette information relative à la demande de suppression de son propre compter par l'usager.

Ce modèle devrait donc contenir :
- Une clé étrangère vers le modèle utilisateur.
- Le code opaque de confirmation de la suppression, de 63 caractères alphanumériques. Ce code opaque servirait à retrouver l'objet à partir du format d'urls. Je vois plutôt d'un paramètre d'urls au sens Django (par exemple /validate-deletion/(?P<opaque_code>|A-Za-z0-9]+)/) plutôt qu'un paramètre de querystring. Ce premier choix est davantage ce qui me vient à l'esprit quand on parle d'URL opaque.
- La date de création de l'objet. Cette date serait utilisée, lorsque la vue de suppression est servie, à vérifier que cet objet a été créé depuis moins de 48h.

#4 Updated by Thomas Noël 3 days ago

Mes 2 cents : s'inspirer plutôt du système utilisé lors de l'enregistrement, cf authentic2/utils.py::build_activation_url . L'URL contient des infos datées et signées, et hop.

#5 Updated by Paul Marillonnet 3 days ago

Ah bein oui, c'est moi qui vaux 2 cents pour ne pas y avoir pensé.
Je vais regarder ça et adapter le code si nécessaire, merci bien.

#6 Updated by Paul Marillonnet 2 days ago

  • Status changed from Nouveau to Information nécessaire

Ce qui m'embête un peu si on s'inspire du code d'activation, c'est qu'on ne stocke plus l'information relative à la demande de suppression.
On vérifierait que le jeton déchiffré correspond à une clé primaire d'usager existant et à un horodatage valide (inférieur à 48h), mais on s'expose à des attaques par force brute dans lesquelles a2 testerait la validité de jetons correspondant potentiellement à des usagers n'ayant jamais émis de demande de suppression de leur compte.

Est-ce que c'est grave docteur ?

#7 Updated by Thomas Noël 2 days ago

Faut calculer l'entropie, comme dirait l'autre. En vrai je n'en sais rien, peut-être que tu soulèves un vrai problème...

#8 Updated by Paul Marillonnet 2 days ago

Le truc évident, discuté de vive voix avec Thomas et Frédéric, c'est de vérifier que l'usager connecté est bien celui dont la clé primaire apparaît dans la signature.

#9 Updated by Paul Marillonnet 2 days ago

  • Status changed from Information nécessaire to En cours

Also available in: Atom PDF