Changement d'email par un utilisateur
Diagramme d'état
2 états :
5 événements :
- faire une demande
- expiration d'une demande
- confirmation d'une demande
- confirmation incorrecte
- réclamation auprès des admins
+--------+ +---------+
| | Faire demande | | Faire une
+--+ +----------------->| +--+ demande.
Expiration | | | | | | On remplace
impossible +->| Normal | Expiration | Demande |<-+ l'ancienne.
| |<-----------------+ en |
| | | cours |
Confirmations | | Confirmation ok | | Confirmation
génèrent +--+ |<-----------------+ +--+ incorrecte.
erreurs | | | | | | Elle est
+->| | Réclamation | |<-+ ignorée
| |<-----------------+ |
| | => Suppr demande | |
+-+------+ +---------+
| ^
+----+
Réclamation, à traiter
en fonction de l'historique
Description du fonctionnement
L'utilisateur fait une demande de changement de mail. Son mot de passe lui est demandé à ce moment-là. Une ligne est ajoutée dans la table
emailChanges
. L'ancien mail n'est pas modifié et est toujours valide. Un mail est envoyé à la nouvelle adresse, avec le nom du compte et une URL qui contient la clé. Suivre cette URL permet l'activation de la nouvelle adresse à la place de l'ancienne, et passe le
status
dans la table
emailChanges
à
done
. Cet URL n'est valide que durant une période de 24h après la date de la demande. La page affichée en suivant l'URL indique si le changement de mail est bon, ou bien si une erreur s'est produite. Un mail est aussi envoyé à l'ancienne adresse pour information. Ce mail contient le nom du compte, la nouvelle adresse email, et un lien vers
cds-question@unistra.fr
permettant une réclamation.
Certaines contraintes prises en compte :
- on demande le mot de passe pour s'assurer que c'est pas un inconnu qui change l'adresse email, par exemple dans le cas où le poste de travail est laissé accessible. Avoir l'adresse email permet d'obtenir une demande de changement de mot de passe. C'est donc une information sensible.
- on permet le changement de mail, même si on n'a plus accès à l'ancienne email.
- on envoie un mail à l'ancienne adresse, au cas où quelqu'un essaye de s'approprier le compte, en changeant son email.
En cas de réclamation, un administrateur du CDS doit regarder l'historique des demandes de changement d'email, pour décider de ce qu'il faut faire. Si la réclamation est valide, il faut effacer une éventuelle demande en cours dans la table
emailChanges
, et remettre la bonne adresse email dans la table
users
. Si la réclamation viens d'une adresse mail qui n'a jamais été associée au compte, il faut faire très attention avant de faire un changement.
Table dans la base de donnée
Une table nommée
emailChanges
est ajoutée à la base de donnée. Elle contient les demandes en cours, avec le status
asked
. Et l'historique des demandes qui ont été confirmées, avec le status
done
. Les demandes qui ont expirées (status
asked
et 24h révolus après la
date
) sont supprimées de la table par une tâche qui tourne chaque nuit.
Colonne |
Description |
idRef |
Identifiant de l'utilisateur dans la table users |
oldEmail |
Email actuel de l'utilisateur |
newEmail |
Nouvel email demandé par l'utilisateur |
key |
La clé qui permet de valider la nouvelle adresse |
date |
Date de la demande, utilisé pour savoir si la demande a expiré |
status |
Valeurs possibles : asked , done |
Voici la requête SQLite pour créer la table. La table est créée par l'outil de conversion de la base de yaml vers SQLite.
create table emailChanges (
idRef integer not null,
oldEmail text not null,
newEmail text not null,
key text not null,
date integer not null,
status text not null
);
--
PascalWassong - 2017-01-26