No se pueden determinar los problemas de Passkey detrás del proxy de Cloudflare

Soporte
1

ACTUALIZACIÓN: ¡Resuelto!

Para resolver el problema, pude habilitar force_https, lo que solucionó todo. Resulta que las passkeys intentaban enrutar a http://, pero ese tráfico mixto no estaba siendo marcado por el navegador. Al final, Cloudflare no era el problema en absoluto. Espero que esto pueda ayudar a alguien más en el futuro.

Publicación Original:

El Problema

¡Hola! Recientemente moví mi instancia de Discourse detrás de un túnel de Cloudflare, y parece que todo funciona bien con la excepción de las passkeys. Tanto las inscripciones de passkeys existentes como las nuevas fallan, pero no creo que los registros de registro de actividad dejen muy claro POR QUÉ está fallando. Espero que alguien aquí pueda ayudarme a encontrar el resto de la información de solución de problemas que necesito para resolver esto:

Información Relevante

Sobre mi Configuración

  • Usando Discourse Docker para desplegar Discourse.
  • Postgres y Redis se implementan externamente.
  • Desplegado en Ubuntu en una instancia de AWS EC2.
  • Como se indicó anteriormente, el túnel de Cloudflare proporciona TLS y actúa como proxy.

Lo que he intentado

  • He revisado mi configuración para asegurarme de que Discourse espera el nombre de host de mis foros (forums.example.com)
  • Discourse ha sido configurado para el puerto 80 HTTP ya que Cloudflare maneja TLS.
  • Cuando HTTP no tuvo éxito, intenté forzar a Discourse a usar solo SSL proporcionando un certificado autofirmado y redirigiendo Cloudflare a Discourse en el puerto 443 usando el protocolo HTTPS.
  • Me aseguré de que Cloudflare esté pasando forums.example.com a mi sitio. Sé que lo está haciendo ya que cualquier otro encabezado de host provoca un 404 en el NGINX de Discourse.

Registros Relevantes

  • Esta parte es un poco complicada. Discourse no proporciona nada del lado del servidor (que haya visto) y ya sea que use Bitwarden, iCloud Keychain, Chrome o Firefox, el resultado es el mismo.
  • Los registros para la passkey en sí son casi inexistentes.
  • La parte más útil que encontré fue de la consola de herramientas de desarrollador de Firefox / Chrome al intentar crear una nueva passkey. Se devuelve lo siguiente:
{
  "errors": [
    "The origin of the authentication request does not match the server origin."
  ]
}

Esta es una indicación bastante clara de que hay algo mal entre el cliente y Discourse (también conocido como el proxy), pero estos registros no indican qué información se está pasando de un lado a otro para solucionar esto más a fondo.

¿Alguien puede ayudarme a descubrir alguna otra configuración o ubicación de registros para verificar, o tiene alguna otra recomendación para la solución de problemas? Encuentro poco probable, pero supongo que un error en la configuración de Nginx también podría ser un factor. Básicamente, tengo un doble proxy entre el cliente y Discourse con CloudFlare y Nginx en ejecución. ¿Debería reconsiderar alguna parte de esta configuración?

En términos de prioridad, ciertamente es bueno tenerlo arreglado, pero dado que solo tengo alrededor de 8 usuarios de unos pocos miles que usan passkeys (con otros métodos de inicio de sesión funcionando bien), no me estreso demasiado por ello.

2 Me gusta