Le WordPress d'aujourd'hui, décodé pour les développeurs

Extensions

Un nonce vérifié qui échoue pourtant après un changement d’heure serveur

Un formulaire fonctionnait la veille et rejette désormais toutes les soumissions avec une erreur de sécurité. Le coupable : une horloge serveur décalée après une migration.

Par WordPress Développement • 19 avril 2021 • 4 min de lecture • Aucun commentaire
Un nonce vérifié qui échoue pourtant après un changement d'heure serveur

« Les liens ou formulaires que vous avez utilisés ont expiré. » Ce message, familier de tout développeur WordPress, s’affichait pourtant sur un formulaire qui fonctionnait parfaitement la veille, sans qu’aucun code n’ait changé entre les deux. Le seul événement survenu entre-temps : une migration vers un nouvel hébergeur, effectuée durant la nuit.

Le diagnostic a demandé d’écarter d’abord les causes habituelles – un cache de page qui sert une version figée du nonce, une extension de sécurité trop agressive – avant de remonter jusqu’à la véritable origine du problème : l’horloge du nouveau serveur n’était pas synchronisée correctement.

Symptôme : un rejet systématique, y compris pour des formulaires soumis immédiatement

Le point qui a orienté le diagnostic dans la bonne direction : même un formulaire rempli et soumis en quelques secondes échouait, ce qui écartait d’emblée une expiration normale liée à la durée de vie du nonce, fixée à 24 heures en deux tics de 12 heures chacun par la constante DAY_IN_SECONDS divisée en deux.

Diagnostic : comparer l’heure du serveur à l’heure réelle

date -u
# puis comparer avec une source fiable, par exemple :
curl -sI https://www.google.com | grep -i ^date:

Sur le serveur concerné, l’écart affichait plusieurs minutes de retard par rapport à l’heure réelle, un décalage suffisant pour perturber la génération d’un nonce sur un site à fort trafic où plusieurs requêtes s’enchaînent rapidement.

L'essentiel à retenir : Un nonce dépend du temps courant, pas seulement d'une clé secrète ; Une horloge décalée invalide silencieusement les jetons en cours ; date().timezone et NTP à vérifier après toute migration

Comprendre pourquoi un nonce dépend du temps

La fonction wp_create_nonce() génère un jeton à partir d’un identifiant utilisateur, d’une action et d’un « tic » temporel calculé par wp_nonce_tick(), qui divise le temps courant par une fenêtre de douze heures. Deux appels à wp_create_nonce() effectués dans la même fenêtre produisent le même jeton pour une action et un utilisateur donnés.

function wp_nonce_tick( $action = -1 ) {
    $nonce_life = apply_filters( 'nonce_life', DAY_IN_SECONDS, $action );
    return ceil( time() / ( $nonce_life / 2 ) );
}

Si l’horloge du serveur qui génère le nonce (au chargement de la page) diffère de celle qui le vérifie ensuite (à la soumission), le calcul du tic temporel peut produire deux valeurs différentes, invalidant le jeton alors même que rien d’anormal ne s’est produit du point de vue du visiteur.

Correctif : synchroniser l’horloge via NTP

  1. Vérifier la présence et l’état du service de synchronisation (timedatectl sur une distribution Linux récente)
  2. Activer la synchronisation automatique si elle est désactivée
  3. Confirmer le fuseau horaire configuré côté serveur, distinct du réglage Général > Fuseau horaire de WordPress qui n’affecte que l’affichage des dates
  4. Redémarrer les services concernés si la synchronisation nécessite un redémarrage
timedatectl status
timedatectl set-ntp true

Prévention : surveiller la dérive après chaque migration

Une migration d’hébergeur reste le moment le plus propice à ce type de décalage, en particulier quand le nouveau serveur repose sur une infrastructure virtualisée dont l’horloge dépend de l’hôte physique. Ajouter une vérification simple de la date système à la checklist de recette post-migration évite de découvrir le problème plusieurs heures après la mise en production, via des retours de visiteurs plutôt que des tests internes.

VérificationCommandeFréquence
Heure systèmedate -uAprès chaque migration
Synchronisation NTPtimedatectl statusAprès chaque migration
Fuseau horaire WordPressRéglages > GénéralÀ la mise en production

Un nonce qui échoue sans raison apparente mérite toujours qu’on vérifie l’horloge du serveur avant de suspecter le code : c’est un réflexe qui a évité plus d’une régression fantôme.

En résumé

Un nonce WordPress repose sur un calcul temporel, ce qui le rend sensible à toute dérive d’horloge serveur, un point rarement documenté dans les guides de migration classiques. Face à un rejet systématique de formulaire sans changement de code récent, comparer l’heure système à une source fiable devrait figurer tôt dans la liste des vérifications, avant de plonger dans le code applicatif.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi