Impossible de déterminer les problèmes de Passkey derrière le proxy Cloudflare

Soutien
1

MISE À JOUR : Résolu !

Pour résoudre le problème, j’ai pu activer force_https, ce qui a résolu le problème pour nous. Il s’avère que les passkeys tentaient de rediriger vers http://, mais ce trafic mixte n’était pas signalé par le navigateur. Il s’avère que Cloudflare n’était pas directement le problème du tout. J’espère que cela pourra aider quelqu’un d’autre à l’avenir.

Message original :

Le problème

Bonjour ! J’ai récemment placé mon instance Discourse derrière un tunnel Cloudflare, et tout semble fonctionner correctement à l’exception des passkeys. Les enregistrements de passkeys existants et nouveaux échouent, mais je ne pense pas que les journaux soient très clairs quant à la raison de cet échec. J’espère que quelqu’un ici pourra m’aider à trouver les informations de dépannage supplémentaires dont j’ai besoin pour résoudre ce problème :

Informations pertinentes

À propos de ma configuration

  • Utilisation de Discourse Docker pour déployer Discourse.
  • Postgres et Redis sont déployés en externe.
  • Déployé sur Ubuntu sur une instance AWS EC2.
  • Comme indiqué précédemment, le tunnel Cloudflare fournit le TLS et agit comme un proxy.

Ce que j’ai essayé

  • J’ai vérifié ma configuration pour m’assurer que Discourse attend le nom d’hôte de mes forums (forums.example.com)
  • Discourse a été configuré pour le port 80 HTTP car Cloudflare gère le TLS
  • Lorsque le HTTP n’a pas réussi, j’ai tenté de forcer Discourse à n’utiliser que le SSL en fournissant un certificat auto-signé et en redirigeant Cloudflare vers Discourse sur le port 443 en utilisant le protocole HTTPS.
  • J’ai veillé à ce que Cloudflare transmette forums.example.com à mon site. Je sais que c’est le cas car tout autre en-tête d’hôte provoque un 404 de la part du NGINX de Discourse.

Journaux pertinents

  • Cette partie est un peu délicate. Discourse ne fournit rien côté serveur (que j’ai vu) et que j’utilise Bitwarden, iCloud Keychain, Chrome ou Firefox, le résultat est le même.
  • Les journaux pour la passkey elle-même sont quasi inexistants
  • L’élément le plus utile que j’ai trouvé provenait de la console des outils de développement Firefox / Chrome lors de la tentative de création d’une nouvelle passkey. Ce qui suit est retourné :
{
  "errors": [
    "The origin of the authentication request does not match the server origin."
  ]
}

C’est une indication assez claire qu’il y a un problème entre le client et Discourse (alias le proxy), mais ces journaux n’indiquent pas quelles informations sont échangées pour dépanner davantage.

Quelqu’un peut-il m’aider à trouver d’autres paramètres ou emplacements de journaux à vérifier, ou avoir d’autres recommandations pour le dépannage ? Je trouve cela peu probable, mais je suppose qu’une erreur dans la configuration Nginx pourrait également être un facteur. J’ai essentiellement un double proxy entre le client et Discourse avec CloudFlare et Nginx en cours d’exécution. Dois-je reconsidérer un élément de cette configuration ?

En termes de priorité, c’est certainement agréable à résoudre, mais comme je n’ai qu’environ 8 utilisateurs sur quelques milliers qui utilisent des passkeys (les autres méthodes de connexion fonctionnant parfaitement), je ne stresse pas trop à ce sujet.

2 « J'aime »