Skip to main content
Nous avons ajouté la validation de l’état à la version 3.6.0 du plugin WordPress Login by Auth0, que vous trouverez dans le dépôt GitHub auth0/wordpress. Cette mesure de sécurité aide à atténuer les attaques CSRF en veillant à ce que la réponse corresponde à une requête initiée par le même utilisateur. Pour en savoir plus, consultez Prévenir les attaques et rediriger les utilisateurs avec le paramètre state d’OAuth 2.0.

​
Fonctionnement de la validation de state

Le plugin effectue la validation de state en :
  1. définissant un cookie auth0_state dans le navigateur au moyen de Javascript lorsque le formulaire de connexion Lock est affiché (sur wp-login.php ou sur toute autre page lors de l’utilisation d’un shortcode ou d’un widget);
  2. transmettant cette valeur au formulaire de connexion intégré Lock afin qu’elle soit envoyée avec la requête d’authentification;
  3. recevant cette valeur en retour d’Auth0, inchangée, dans un paramètre d’URL state si la connexion Auth0 a réussi;
  4. validant que la valeur reçue correspond à la valeur envoyée et stockée dans le cookie auth0_state. Si elle est valide, le processus de connexion se poursuit. Sinon, le processus s’arrête et le message d’erreur « Invalid state » s’affiche;
  5. supprimant le cookie, qu’il soit valide ou non;
  6. utilisant les valeurs de l’objet décodé en base64 pour rediriger l’utilisateur ou effectuer d’autres actions de connexion, si elles sont valides.
Ce processus devrait être complètement opaque, tant pour l’utilisateur qui se connecte que pour l’admin du site. Le serveur Auth0 ne valide pas et n’exige pas de valeur state, et il la renvoie telle quelle à l’URL de rappel. Si le message « Invalid state » s’affiche, c’est que l’une des 4 premières étapes ci-dessus ne se produit pas.

​
Causes courantes de l’erreur d’état invalide

Vous trouverez ci-dessous quelques causes courantes de l’erreur d’état invalide, ainsi que des étapes de dépannage à suivre.

​
URL de rappel mises en cache

La cause la plus fréquente de l’erreur invalid state est la mise en cache de l’URL de rappel sur le serveur. Excluez la mise en cache sur votre serveur pour toutes les URL indiquées dans le champ Allowed Callback URLs dans Auth0 Dashboard > Applications > Applications > Settings, puis faites le Test de nouveau. De plus, excluez de la mise en cache l’URL du site (/index.php dans une installation standard) si elle comporte un paramètre URL Auth0. Vérifiez aussi que l’heure de votre serveur est correctement réglée. L’erreur BeforeValidException peut se produire lorsque le token semble avoir été généré avant l’heure actuelle, ce qui peut arriver si l’heure du serveur n’est pas exacte. Vous pouvez vérifier l’heure du serveur en utilisant echo current_time( 'c' ). Comme solution temporaire, vous pouvez aussi modifier le Plugin pour ajouter un décalage horaire si vous ne pouvez pas changer l’heure du serveur, mais cela devrait être corrigé pour la Production. Si cela ne règle pas le problème, poursuivez avec les étapes de dépannage ci-dessous.

​
Cookies mis en cache et paramètres d’URL

Si vous utilisez un hébergement géré comme WP-Engine, vous devrez peut-être communiquer avec son équipe de soutien pour obtenir de l’aide supplémentaire. Des problèmes d’accès aux cookies requis sur l’URL de rappel nous ont été signalés, ainsi que des problèmes lors de la vérification de l’authentification sur la page finale que les utilisateurs voient après s’être connectés. Plus précisément, demandez l’ajout d’exclusions de cache pour :
  • Cookie: auth0_state
  • Cookie: auth0_nonce
  • Arg/paramètre d’URL: auth0
  • Arg/paramètre d’URL: code
  • Arg/paramètre d’URL: state
  • Arg/paramètre d’URL: id_token

​
Actualisation de la page après un message d’erreur

Si vous actualisez la page après avoir vu un autre message d’erreur (vérification du courriel, etc.), le message invalid state s’affichera, puisque le système tente de valider de nouveau une valeur déjà utilisée. C’est normal. Certains hébergeurs, comme Pantheon, exigent l’utilisation de noms de cookies précis. Vous pouvez modifier le nom du cookie à l’aide du filtre auth0_state_cookie_name dans votre thème ou dans un plugin personnalisé. Pour en savoir plus sur le filtre auth0_state_cookie_name, consultez Étendre le plugin Login by Auth0 WordPress Plugin. Pour plus d’information, consultez l’issue GitHub connexe et découvrez le correctif correspondant.

​
Universal Login Page et création manuelle du lien

Si votre site utilise la page et que vous créez le lien vous-même dans un thème ou un plugin, vous devez :
  • Définir un cookie appelé auth0_state avec une valeur générée aléatoirement
  • Transmettre cette valeur dans le paramètre d’URL state.
Sinon, vous pouvez aller à Settings > Features tab > Universal Login Page et rediriger les demandes de connexion vers la page wp-login.php, où ce cookie et ce paramètre d’URL seront définis automatiquement.

​
Accéder directement à l’URL de rappel

Si vous accédez directement à votre URL de rappel (généralement yourdomain.com/index.php?auth0=1) ou si vous y accédez une deuxième fois après l’échange du code d’autorisation, l’erreur invalid state peut s’afficher. Cela indique que le state a déjà été vérifié et supprimé.

​
Résoudre les erreurs « invalid state »

Notez que certaines des étapes ci-dessous exigent d’interrompre le processus de connexion pendant l’opération (comme indiqué) :
  1. Après vous être déconnecté de WordPress et d’Auth0, accédez à la page de connexion à tester.
  2. Vérifiez si le cookie auth0_state est défini (dans Chrome, View > Developer > JavaScript Console > onglet Application > Storage à gauche > Cookies > domain à tester; cherchez un cookie auth0_state dont la valeur n’est pas vide).
    • Si cette valeur n’est pas définie, vérifiez s’il y a des erreurs dans la console JS et assurez-vous que votre navigateur accepte les cookies (la connexion ne fonctionnera pas sans cookie).
    • Si la valeur est définie, copiez-la et affichez le code source de la page (dans Chrome, View > Developer > View Source). Recherchez la valeur; elle devrait apparaître comme la valeur associée au paramètre wpAuth0LockGlobal.settings.auth.params.state (voir un exemple de JSON). Prenez cette valeur en note (vous en aurez besoin dans une étape suivante).
  3. Si la valeur y apparaît et que le formulaire Lock se charge normalement, c’est que les étapes 1 et 2 de la première liste ci-dessus fonctionnent correctement.
  4. Avant de vous connecter, ajoutez cet extrait de code au début de votre wp-config.php afin de faire une installation de test. WARNING : cela empêchera la connexion au site WordPress testé, alors utilisez-le uniquement sur une installation hors production.
  5. Connectez-vous normalement.
  6. Une fois redirigé vers l’URL de rappel de votre site, le processus s’arrêtera. Vous devriez voir une sortie semblable à celle du Gist lié à l’étape #4 ci-dessus. Si vous voyez quelque chose comme Array() sans valeurs supplémentaires, l’une des deux situations suivantes peut se produire :
    • L’URL de rappel de WordPress est mise en cache. La mise en cache des pages peut se produire de nombreuses façons; nous ne pouvons donc pas fournir d’étapes précises ici. Vérifiez les extensions de mise en cache que vous avez peut-être installées; elles offrent généralement un mécanisme d’exclusion d’URL intégré. Vérifiez aussi auprès de votre hébergeur, car la mise en cache peut être automatique et nécessiter l’intervention du soutien.
    • Le serveur ne lit pas le cookie Auth0. Pour une solution possible, consultez l’issue GitHub connexe et examinez son correctif.
  7. Si les valeurs sont présentes, vérifiez les en-têtes de réponse de l’URL de rappel chargée (dans Chrome, View > Developer > JavaScript Console > onglet Network, cliquez sur le premier « document » affichant un statut 500 et cherchez « Response Headers »). Recherchez tout indice de mise en cache, comme un Cache-Control avec un max-age non nul, un x-cache autre que MISS, ou tout autre signe indiquant que cette page est servie à partir d’un cache.
  8. Toujours dans les en-têtes de réponse, vérifiez que set-cookie inclut une directive comme auth0_state=deleted pour confirmer que le processus de validation a bien lieu.
  9. Assurez-vous que le paramètre state dans l’URL correspond à celui consigné à partir du cookie défini à l’étape #3 ci-dessus.
  10. S’il n’y a aucun indice de mise en cache, retirez l’extrait de débogage de wp-config.php et actualisez l’URL de rappel. Vous devriez voir réapparaître le message « Invalid state ». Si des changements liés à la mise en cache ont été apportés, reprenez le processus de connexion du début à la fin (assurez-vous d’effacer vos cookies et le cache du navigateur pour le site avant de tester).
Les étapes de troubleshooting suivantes nécessitent des modifications de l’extension qui interrompront le processus de connexion et devront être annulées une fois terminées. Ces étapes doivent être effectuées sur un serveur de test ou de staging.
  1. Nous devons ensuite vérifier pourquoi le state est transmis, mais ne correspond pas à la valeur stockée.
  2. Dans lib/WP_Auth0_LoginManager.php, affichez les valeurs du state stocké et retourné, puis arrêtez le processus. Juste avant la ligne 148, ajoutez :
  1. Encore une fois, assurez-vous d’être déconnecté et terminez le processus de connexion.
  2. Vous devriez voir des valeurs s’afficher lors de la redirection vers l’URL de rappel WordPress.
  3. Vérifiez si la valeur state dans $_REQUEST existe et correspond à la valeur auth0_state dans $_COOKIE.
  • Si c’est différent, cela devrait correspondre à la valeur d’origine consignée à l’étape #3 ci-dessus. Cela signifie que la valeur de state dans $_COOKIE a changé quelque part dans le processus.
Si aucune des étapes ci-dessus ne résout le problème, veuillez recueillir les résultats de ces étapes et contacter le soutien ou publier dans la Community avec l’étiquette wordpress. Veuillez aussi inclure :