Estoy teniendo un problema al incrustar Discourse en nuestro sitio de intranet.
La documentación de la API indica que la solicitud a Discourse requiere los encabezados “API-Key” y “Api-Username” para autenticarse y acceder al feed. Sin embargo, la verificación previa (pre-flight) indica que los valores permitidos son “User-API-Key” y “User-Api-Client-Id”.
Cuando se llama fuera de un navegador, funciona como se espera. Pero al llamarlo desde un navegador, el servidor indica que se requieren “User-API-Key” y “User-Api-Client-Id”.
Verifiqué que la conexión básica funciona con Postman, y se comporta según lo descrito en la documentación de Discourse.
Si enviamos los encabezados según la documentación, el navegador bloquea la solicitud debido a la verificación previa y obtiene un error CORS de Access-Control-Allow-Headers.
Si enviamos los encabezados que el servidor acepta, obtenemos un error de “no autorizado” porque la aplicación espera valores con nombres diferentes.
He intentado agregar encabezados a la configuración de Docker, pero parece que no se aplican. CORS está habilitado y el origen está configurado como ‘*’ en la configuración.
Tenemos dos sistemas de autenticación de API diferentes, lo cual puede resultar confuso.
Estos son para la ‘API de administración’, descrita en docs.discourse.org. No están diseñados para ser utilizados desde clientes de JavaScript.
Estos provienen de la especificación de la “API de usuario”, que puede ser utilizada desde un cliente de JavaScript (y por lo tanto, soporta CORS). Hay más detalles sobre esto aquí: User API keys specification
@david Estoy utilizando SSO y quiero cerrar la sesión del usuario en Discourse cuando cierre la sesión en la aplicación. Actualmente estoy usando la ‘API de administración’ para obtener el ID del usuario mediante /users/by-external/${id}.json, pero estoy recibiendo errores de CORS. No quiero habilitar la ‘API de usuario’ para todos los usuarios solo para este proceso de cierre de sesión. ¿Qué me sugieres?
¿Qué está realizando la solicitud a la API de administrador? ¿JavaScript en tu aplicación cliente?
No debes incluir una API de administrador en un cliente de JavaScript, ya que significa que cualquiera que use el cliente podría obtener acceso de administrador a tu sitio.
Sí, es JavaScript en mi aplicación. Lo entiendo. Entonces, ¿cuál es la alternativa? ¿Puedo agregar una ‘API de usuario’ para un solo usuario y usarla para realizar la llamada en nombre de todos los usuarios?
Si utilizas la API de usuario, debes hacerlo por usuario. No debes compartir las claves.
Pero lo más habitual en este caso es gestionarlo en el lado del servidor de tu aplicación. Tu servidor puede enviar una solicitud utilizando claves de la API de administrador sin problemas de CORS y con menos preocupaciones de seguridad (siempre que se implemente de forma segura).
Hola @david, he intentado implementar una solución en el backend, pero al llamar a https://example.com/users/by-external/{EXTERNAL_USER_ID}.json?api_key={DISCOURSE_API_KEY}&api_username=system, la respuesta que obtengo es el HTML de la página de inicio de sesión (supongo que está redirigiendo allí). Tengo activada la opción «se requiere inicio de sesión» y, cuando la desactivo, obtengo la respuesta JSON correcta. Quiero mantener esa configuración activada: ¿alguna idea de qué está pasando?
