Vérification d’adresse électronique

Extension payante. Un formulaire peut exiger qu’une adresse soit confirmée par un lien avant que ses effets n’aient lieu : création de compte, confirmation adressée à cette boîte.

Ce document décrit ce que le module garantit et ce qu’il refuse. Le guide utilisateur en donne la version courte, dans la section « Confirmer une adresse ».

La soumission est toujours enregistrée

C’est la décision structurante. Il aurait été plus simple de refuser la soumission jusqu’à confirmation ; ce serait perdre une demande à chaque courriel qui n’arrive pas — et les courriels n’arrivent pas, régulièrement, pour des raisons qui ne tiennent ni au site ni au visiteur.

L’entrée est donc créée normalement, active, consultable. Ce qui en découle attend. Et les alertes internes partent immédiatement : une demande ne doit pas rester invisible parce qu’une adresse n’est pas confirmée.

Le réglage vit sous email_verification :

{
  "email_verification": {
    "enabled": true,
    "field": "email_1"
  }
}

Un seul réglage. La durée du lien — vingt-quatre heures — et le plafond de renvois — trois par jour — ne sont pas réglables : ils protègent le propriétaire de la boîte, qui n’est ni le visiteur qui saisit l’adresse ni l’administrateur qui règle le formulaire.

Seul un champ d’adresse se vérifie. Vérifier un champ texte reviendrait à envoyer un lien à ce que quelqu’un y aura écrit, et le formulaire deviendrait un relais d’envoi vers n’importe quoi.

Le jeton

Le lien porte un rang et un secret — 12.a3f…. La base ne conserve qu’un HMAC-SHA256 du secret, dont la clé est le sel du site.

Une table de jetons en clair serait une table de clés : qui la lit — une sauvegarde, une injection SQL, un export mal rangé — pourrait valider n’importe quelle adresse sans jamais accéder à la boîte correspondante. L’empreinte, elle, ne permet rien.

La comparaison passe par hash_equals : celle d’une chaîne ordinaire s’arrête au premier octet qui diffère, et ce temps-là se mesure — sur un jeton, cela se traduit par une reconstitution octet par octet.

La forme du lien est close avant toute requête : des chiffres, un point, soixante-quatre caractères hexadécimaux. Une charge forgée ne donne pas même lieu à une interrogation de la base.

Le jeton n’encode ni l’adresse, ni la soumission, ni sa date d’expiration : tout cela vit dans la ligne. Un jeton qui porterait ses propres conditions serait vérifiable sans la base, donc rejouable après une révocation — qui n’existe que là.

Un usage, et un seul

La vérification est écrite par une condition portée par la requête : verified_at IS NULL. Deux ouvertures simultanées du même lien — un client de messagerie qui précharge, un antivirus qui suit les liens — ne déclenchent les effets qu’une fois : le premier UPDATE touche une ligne, le second zéro, et c’est le nombre de lignes qui tranche.

Le renvoi remplace

entry_id est unique : un renvoi écrit par-dessus le jeton précédent, qui cesse de valoir à l’instant même. Deux liens valides pour une même adresse voudraient dire qu’un lien révoqué reste utilisable par son jumeau, et la révocation ne révoquerait rien.

Un envoi qui échoue consomme tout de même sa tentative. Le jeton est fabriqué avant d’être mis dans le lien, et le lien avant d’être mis dans le message : au moment où l’expédition échoue, le jeton précédent est déjà remplacé. La tentative est perdue, et c’est le prix d’une garantie qui compte davantage.

Les réponses publiques sont neutres

Lien invalide, expiré, déjà employé, révoqué : tous conduisent au même refus, qui ne dit pas lequel. Distinguer « expiré » de « inexistant » renseignerait quiconque essaie des liens au hasard sur ce qui existe — et sur ce qui a existé.

L’état réel se lit dans le détail de la soumission, par qui a déjà le droit de la lire.

Le retour ne laisse rien derrière lui

Le lien est suivi, puis le visiteur est redirigé immédiatement vers la page d’où il a envoyé le formulaire. Rendre une page à l’adresse du lien y laisserait le secret affiché : dans l’historique, dans la barre d’adresse, dans le journal d’accès du serveur et dans l’en-tête Referer de tout ce que la page chargerait ensuite.

L’adresse de retour vient de la base — elle a été relevée à la soumission — et elle est donc traitée comme non fiable : wp_validate_redirect() la confronte aux hôtes autorisés, et retombe sur l’accueil sinon. Sans cela, une valeur écrite en base ferait du lien de vérification une redirection ouverte, c’est-à-dire un lien du site qui conduit ailleurs.

Le courriel ne contient aucune réponse

Il part vers une adresse qu’on n’a précisément pas encore confirmée. Y recopier les réponses enverrait la saisie de quelqu’un à une boîte dont rien ne dit qu’elle lui appartient.

Quels effets attendent

La règle est l’adresse, non le rôle. Une notification est retenue si l’un de ses destinataires — to, cc ou bcc, après résolution des jetons — est l’adresse en cours de vérification.

On aurait pu retenir celles dont le destinataire est un jeton de champ, et laisser partir celles qui visent une adresse en dur. C’est une approximation : une alerte interne peut viser {field:responsable}, et une confirmation peut viser une adresse écrite en dur. La question exacte est « ce message part-il vers l’adresse qu’on vérifie ? », et elle donne gratuitement ce que le plan demande.

À la libération, la même comparaison est prise dans l’autre sens : seules les notifications retenues repartent, sans quoi les alertes déjà parties partiraient une seconde fois.

La création de compte consulte le même garde. Le filtre solis_forms_pro_entry_effects_allowed vaut vrai quand personne ne répond : un site sans vérification se comporte exactement comme avant. C’est ce qui rend la dépendance facultative pour de bon — le module de comptes ne connaît pas la vérification, et la vérification ne connaît pas les comptes ; ils ne partagent qu’un vocabulaire, DeferredEffects.

Le provisionnement rejoué est idempotent, donc une libération qui arriverait deux fois ne crée pas deux comptes.

Purge

Les vérifications expirées sans suite sont effacées une semaine après leur expiration. Celles qui ont abouti sont conservées : elles disent qu’une adresse a été confirmée, et c’est ce que l’administrateur consulte des mois plus tard.

Supprimer une soumission efface sa vérification.

Ce que le module ne fait pas

Ni SMS, ni validation de domaine, ni double opt-in marketing, ni changement d’adresse d’un compte connecté. Et il ne vérifie pas les réservations de créneaux : ce module n’existe pas encore, et le garde l’attendra sans rien changer à son fonctionnement quand il arrivera.