ProxyEPN

Modifications publiées sur le svn (r393) :

Principe de fonctionnement¶

En cas de mot de passe oublié, un formulaire demande à l'utilisateur de saisir l'identifiant ou l'email de son compte EPN, afin que le système puisse retrouver le compte correspondant.

Une clé aléatoire unique est ensuite générée et associée au compte EPN. Elle est stockée dans la base de données avec une durée de validité (60mn) et envoyée par email à l'utilisateur.

Dans l'email reçu, la clé est présentée dans un lien. Il suffit à l'utilisateur de cliquer dessus pour se retrouver authentifié sur l'application, il peut alors modifier son mot de passe dans ses préférences.

A noter :

• L'adresse email doit nécessairement être renseignée dans le compte EPN, sans quoi cette fonctionnalité est impossible.
• La demande ne fait que générer une clé temporaire pour accéder au compte, aucun changement du mot de passe n'est effectué.
• L'unicité de la clé est assurée par les 8 premiers caractères correspondant au timestamp de sa génération, les 32 caractères suivants étant le md5 d'une chaine aléatoire.
• La clé est à validité réduite et à usage unique : dès qu'elle est utilisée (utilisation du lien et authentification sur l'interface) elle est ensuite supprimée.

Mise en place dans la base de données¶

Une nouvelle table est nécessaire dans la BdD pour stocker les clés générées :

--
-- Structure de la table `sf_guard_recovery_key`
--

CREATE TABLE IF NOT EXISTS `sf_guard_recovery_key` (
  `user_id` int(11) NOT NULL,
  `recovery_key` varchar(40) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ip_address` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  `created_at` datetime DEFAULT NULL,
  PRIMARY KEY (`user_id`),
  UNIQUE KEY `recovery_key` (`recovery_key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

--
-- Contraintes pour la table `sf_guard_recovery_key`
--
ALTER TABLE `sf_guard_recovery_key`
  ADD CONSTRAINT `sf_guard_recovery_key_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `sf_guard_user` (`id`) ON DELETE CASCADE;

Les objets correspondants sont générés par Propel (sfGuardRecovery et sfGuardRecoveryPeer).
Quelques méthodes y sont ajoutées pour gérer la création d'une clé, sa récupération, son expiration.

Intégration au module sfGuardAuth¶

La classe actions du module est personnalisée dans la partie app/frontend/modules/sfGuardAuth/actions/.

• "password" est l'action utilisée pour afficher le formulaire (saisie de l'identifiant ou email), l'essentiel se situe donc dans le template
• "recovery" est la nouvelle action après validation du formulaire : elle récupère l'identifiant ou email, recherche le compte associé, génère une clé et l'envoie par email.
• "recovery" est également l'action utilisée pour l'authentification à partir de la clé (par le lien fourni dans l'email) : si un paramètre key est présent, il est recherché dans la BdD, s'il est trouvé et valide alors l'authentification avec le compte correspondant est effectuée et la clé est supprimée de la BdD.

Note : tous les controles nécessaires sont effectués, avec en cas d'erreur une redirection avec message d'erreur :

• Utilisateur déjà authentifié (action réservée aux utilisteurs anonymes)
• Identifiant ou Email non fournis
• Aucun compte correspondant à l'identifiant ou à l'email
• Compte correspondant ne disposant pas d'adresse email
• Clé de récupération non valide (inexistante dans la BdD : erronée ou déjà utilisée)
• Clé de récupération expirée

Une nouvelle route est ajoutée pour l'action "recovery" :

sf_guard_recovery:
  url:   /recovery_password
  param: { module: sfGuardAuth, action: recovery }

Composition de l'email envoyé¶

Le message de l'email est composé à partir du modèle data/html/mail_recovery.html.

Le modèle doit contenir un tag #RECOVERY_LINK# qui sera automatiquement substitué par le lien web complet, contenant la clé, qui permettra à l'utilisateur de s'authentifier sur l'application.

L'adresse de l'expéditeur est celle spécifiée dans la configuration de l'application (mail_from dans app.yml).
Le sujet est en dur dans le code de l'action.

TODO¶

• Unicité de l'email : si l'utilisateur choisit d'indiquer l'email de son compte plutot que son identifiant, rien n'assure que celui-ci est unique... il faut donc traiter le cas ou plusieurs comptes EPN correspondraient à l'email donné.
• Configuration : cette fonctionnalité pourrait être activée/désactivée dans la configuration de l'application, de plus un paramètre comme la durée de validité des clés devrait aussi s'y trouver.
• Personnalisation de l'email : permettre l'édition via l'interface du modèle, permettre des modèles spécifiques aux GEPN/EPN, permettre davantage de tags pour insérer des valeurs dynamiques (nom de l'EPN, nom de l'usager, etc...) -> à voir avec un système générique pour tout type d'email envoyé par l'application

Modifications publiées sur le svn (r399) :

Paramétrage dans app.yml¶

Une clé de configuration nommée recovery_delay est ajoutée dans la section existante pour sf_guard_plugin :

all:
  sf_guard_plugin:
    routes_register:     false
    success_signout_url: @homepage
    recovery_delay:      60

Elle permet de déterminer la durée de validité des clés générées et envoyées par email pour se connecter à son compte sans son mot de passe (durée indiquée en minutes). Cette valeur de configuration remplace la valeur précédement placée en variable dans la classe. Le template de l'email accepte le motif #RECOVERY_DELAY# pour indiquer la valeur à l'usager.

De plus son usage est double, puisqu'une valeur de 0 désactive cette fonctionnalité si elle n'est pas souhaitée par l'administrateur. Bien qu'une telle valeur rend de fait impossible l'action (les clés devenant expirées dès leur création), les accès aux actions et les liens sont également désactivés.

Unicité des emails¶

Si la demande est effectuée en spécifiant une adresse email mais que plusieurs comptes usagers correspondants sont trouvés, alors aucune action n'est effectuée. Un message d'erreur s'affiche en retour, informant l'utilisateur et lui demandant de spécifier alors l'identifiant.

Conclusion¶

La réalisation de cette fonctionnalité est jugée suffisament complète à ce stade. Une interface de gestion des templates d'emails fera l'objet d'une autre demande plus générale. Le système de mot de passe oublié pourrait être renforcé/étendu par d'autres procédés (fournit davantage d'information sur le compte, question secrète, etc...) mais l'actuel est déjà valable, ces extensions seraient alors des évolutions futures.