Centre de Données astronomiques de Strasbourg

Difference: CdsLoginEmailChange (2 vs. 3)

Revision 32017-02-08 - ThomasBoch

META TOPICPARENT	name="CdsLoginProjet"

Changement d'email par un utilisateur

Diagramme d'état

2 états :

normal
demande en cours

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

Changed:

<
< 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 question@unistra.fr permettant une réclamation.

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

Deleted:

<
<

View topic | History: r3 < r2 < r1 | More topic actions...