No tengo una instalación local de Discourse en este momento, así que no estoy seguro de cuánto puedo ayudar.
La respuesta 404 me hace preguntarme si Discourse Connect está realmente habilitado en tu sitio de Discourse:
Parece que estás probando esto con una aplicación Angular local y un sitio de Discourse en producción. Esperaría que eso aún funcionara, pero posiblemente esté causando un problema. Definitivamente deberías poder obtener algún tipo de respuesta que no sea un 404.
@simon gracias por tu respuesta,
eso lo he confirmado varias veces,
y también tengo un sitio de prueba de producción alojado en el dominio principal de este sitio de Discourse. Si puedes echar un vistazo a este [enlace redactado]
para probar el flujo de producción, he actualizado la URL de Discourse Connect a “https://domainsite.com/login”, siéntete libre de iniciar sesión con el proveedor de Google y hacer una prueba. En la consola de inspección verás el error y la respuesta que imprimí, que es 404.
Dado que solo estoy haciendo la Prueba de Concepto (POC), si no te importa, ¿podrías dejarme tu correo electrónico para poder configurarte como administrador y que investigues de cerca las configuraciones en mi sitio de Discourse? De nuevo, realmente aprecio tu tiempo y ayuda.
la única parte que no estoy seguro es la firma y el SSO, ¿lo estoy haciendo correctamente desde el código?
aparte de esta parte. La clave API intenté ambas, generando para todos y solo para el sistema, los resultados son iguales. si es posible, por favor proporcióname un ejemplo funcional para Postman o código basado en Angular
Me perdí esto cuando miré por primera vez la captura de pantalla de tu código:
mode: 'no-cors'
No estoy familiarizado con las aplicaciones de Angular, pero parece que estás intentando hacer una solicitud de API autenticada a Discourse desde el cliente. No estoy seguro de dónde ocurre en el código de Discourse, pero entiendo que Discourse bloquea las solicitudes de API de administrador que se realizan desde el cliente. Esto se debe a que no hay forma de hacer la solicitud sin exponer la clave de API en el cliente. Relacionado con eso, deberías cambiar tu clave de API ahora.
Gracias por señalar esto,
se siente como avanzar un paso más.
También estoy intentando enviar la solicitud desde Postman.
Si crees que el bloqueo desde el lado del cliente “mode: ‘no-cors’” ya que Discourse se negó a aceptar la llamada con claves API desde el frontend, entonces creo que debería estar bien enviarlo desde Postman, ¿es correcto? pero el resultado es el mismo
Incluso intenté iniciar un servidor y luego activar el servidor para enviar la solicitud con la apikey en el lado del servidor, lo que da el mismo resultado, lo que me hace sentir que me faltan algunas configuraciones en el sitio de Discourse.
Conseguir que esto funcione desde Postman, o incluso desde la línea de comandos, es una buena idea. Por la captura de pantalla que publicaste, parece que tienes el api-username y la api-key en el cuerpo de la solicitud. Esos parámetros deben estar en la cabecera de la solicitud. El cuerpo de la solicitud debe contener los pares clave/valor sig y sso. Si te sirve de ayuda, así es como lo maneja el plugin WP Discourse: wp-discourse/lib/plugin-utilities.php at main · discourse/wp-discourse · GitHub.
¡Guau! Aquí vamos,
¡ahora está funcionando!
1000 gracias @simon
el problema era justo lo que mencionaste:
sso y sig deben ser los únicos dos pares de claves en el cuerpo
api-key y api-username deben estar en las cabeceras
¿Cómo se comportará esto si lo activo en un sitio que actualmente no usa external_id? ¿Podrá iniciar sesión en los usuarios basándose únicamente en su correo electrónico?
En términos más generales, dado que email y external_id son los 2 campos obligatorios en la carga útil, ¿podría aclarar cómo se utilizan en el lado de Discourse (al recibir la carga útil del sitio de autenticación) para determinar qué cuenta de usuario iniciar sesión?
external_id con el correo electrónico durante la creación del usuario? ¿Usará el correo electrónico y luego asociará el external_id con este correo electrónico para futuros inicios de sesión?email y external_id (cada uno está asociado con una cuenta de Discourse diferente)? ¿Usará external_id o email para determinar qué usuario iniciar sesión? ¿O generará un error?¡Gracias!
Creo que tu pregunta principal es sobre el campo external_id. Necesitas establecer un campo external_id en la carga útil de DiscourseConnect. El valor del campo debe ser una cadena de texto asociada al usuario que nunca cambiará. Supongo que tu aplicación tiene una tabla de usuarios. La clave principal de la entrada de un usuario en esa tabla sería buena para usarla como valor del campo external_id.
Si un usuario creó una cuenta en Discourse antes de que agregaras la autenticación de DiscourseConnect desde tu sitio web, la primera vez que inicie sesión en Discourse a través de DiscourseConnect, Discourse intentará encontrar al usuario basándose en la dirección de correo electrónico que se encuentra en la carga útil de DiscourseConnect. Después de encontrar al usuario, se agregará un registro a la base de datos de Discourse que contiene el external_id de la carga útil de DiscourseConnect. La próxima vez que el usuario inicie sesión, será encontrado por el external_id en lugar de por la dirección de correo electrónico. (Ten en cuenta que esto no funciona si estableces el parámetro require_activation en la carga útil de DiscourseConnect en true.)
Discourse tiene buenos mecanismos de recuperación para la mayoría de los casos extremos. Hay problemas relacionados con usuarios que tienen varias cuentas y direcciones de correo electrónico que pueden generar errores. Aquí tienes algunos detalles sobre cómo tratar esos casos: Depurar y solucionar problemas comunes de DiscourseConnect.
¡Muy útil, gracias! Parece que todo funciona como esperaba 
Hemos estado usando DiscourseConnect con WordPress como proveedor con éxito durante varios años y no hemos cambiado las configuraciones de Discourse ni de WP. Hoy noto lo que creo que es un nuevo comportamiento.
Cuando cierro sesión, solía llevarme a la pantalla de inicio de sesión de WordPress. Ahora me lleva a la pantalla de inicio de sesión de Discourse. Si intento iniciar sesión con la pantalla de Discourse, obtengo un Error desconocido, pero el punto es que no debería estar allí en absoluto, debería estar en el inicio de sesión de WP.
Tenga en cuenta que tengo inicios de sesión locales habilitados (no estoy seguro de por qué, ya que uso WP). Si deshabilito los inicios de sesión locales e intento iniciar sesión, dice que no hay métodos de inicio de sesión disponibles. Así que supongo que no le gusta mi conexión WP, pero de nuevo, no he cambiado las configuraciones en ninguno de los extremos. He confirmado que Discourse Connect está habilitado, la URL de conexión es correcta y el secreto es el mismo en ambos extremos.
Actualizado a 3.5.0.beta5-dev. También el plugin WP Discourse está actualizado.
me está pasando también, voy a jugar con él para ver si puedo encontrar el problema.
Nosotros también estamos usando DiscourseConnect y experimentando el mismo problema.
Lo tenemos en funcionamiento desde hace unos años y todo funcionó sin problemas. Actualizado hoy a 3.5.0.beta8-dev [e91024a221]
Básicamente, la devolución de llamada del sistema sso a la URL de Discourse añade https://discourse.domain.ext/login y tenemos la misma pantalla que @markschmucker
También notamos que al hacer clic en el logotipo del encabezado, aterrizamos en https://discourse.domain.ext/ y el inicio de sesión es exitoso (solo se necesita un clic en un botón)
Parece que en la versión anterior, el controlador de sesión se comportaba de manera diferente, probablemente entendiendo que la llamada fue iniciada por sso externo y la estaba manejando de la manera correcta.
Noté que en el último mes @zogstrip realizó algunos cambios que podrían estar relacionados (no estoy 100% seguro) con el mal funcionamiento.
Por ahora, hemos aplicado una solución alternativa en el método de devolución de llamada que agregaba /login a la URL de Discourse y todo parece funcionar correctamente.
Si me falta algo, como alguna documentación que diera consejos sobre un cambio potencialmente disruptivo en esta porción de código, háganmelo saber.
Gracias a todos por su apoyo.
@markschmucker, @jimkleiber y @marco.palumbo, ¿tienen el mismo problema que se describe en No login methods when using Discourse Connect only?
Si es así, la solución es asegurarse de que la configuración del sitio “autenticar inmediatamente” esté habilitada.
Tengo habilitado "autenticar inmediatamente".
Gracias por tu ayuda con esto @zogstrip. Desafortunadamente, si habilito “autenticar inmediatamente”, pierdo la capacidad de tener una página de “bienvenida” para usuarios anónimos.
Parece que no es posible eliminar un nombre o avatar_url usando DiscourseConnect SSO. He intentado establecer los campos como una cadena vacía (confirmado, por ejemplo, que avatar_url= termina en el parámetro sso base64), pero supongo que el código ignora los campos vacíos.
Los nombres y las imágenes son opcionales en mi sistema, pero tal como funciona ahora, una vez establecidos, nunca se pueden anular, solo reemplazar. ¿Hay alguna posibilidad de que esté haciendo algo mal? (Si no, ¿quizás esto podría solucionarse?)
[Editar]: Ya había buscado una respuesta, pero por supuesto, en cuanto publiqué lo anterior, intenté buscar diferentes palabras clave y encontré Allow name removal using SSO - #9 by mentalstring. Le di un voto positivo, pero no me hago muchas ilusiones. 
Tengo el mismo problema de redirección de inicio de sesión que @markschmucker, @jimkleiber y @marco.palumbo describen arriba, que descubrí hace unas semanas y sabía que había estado funcionando correctamente en algún momento de mayo. Leer lo que han dicho al respecto me convence de que es una regresión en Discourse introducida en alguna actualización de mayo, porque nos afectó a todos al mismo tiempo, todos teníamos código SSO que funcionaba y no compartimos ningún código SSO en común.
He publicado un informe de error con la esperanza de que podamos solucionarlo.
El problema de redirección está solucionado para mí en 3.6.0-beta1.
@markschmucker y @marco.palumbo
Parece que esto se arregló hace un par de semanas y debería estar funcionando correctamente de nuevo en v3.6.0.beta1.