Encabezados CORS de la API incorrectos

Soporte
1

Hi,

I am having an issue with embedding discourse in our intranet site.

The API documentation states the discourse request requires the headers “API-Key” and “Api-Username” to authenticate and gain access to the feed. However the Pre-flight check says that “User-API-Key”, “User-Api-Client-Id” are the allowed values.

When called not through a browser this work as expected. But when calling through the browser the server is claiming it requires “User-API-Key”, “User-Api-Client-Id”.

I checked basic connection worked with PostMan this behaves as per the discourse docs

If we pass the Headers from the Docs the browser blocks the request due to Pre-flight check and gets a Access-Control-Allow-Headers CORS error.

If we pass the headers the server will accept we get a “not authorised error” because the application expects differently named values.

I have tried adding headers to the docker config but it doesn’t seem to apply. The CORS enabled and origin of ‘*’ is in the config.

Can anyone advise?

Thanks,
Jessica

1 me gusta
2

Just wondering if there was any more info on the above? Is this a bug or something I’m doing wrong?

Thanks,
Jessica

1 me gusta
3

We have two different API authentication systems, which can be confusing.

These are for the ‘admin API’, which is described on docs.discourse.org. This is not designed to be used from javascript clients.

These are from the “User API” specification, which can be used from a javascript client (and therefore supports CORS). There are more details about this here: User API keys specification

5 Me gusta
4

@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?

5

¿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.

3 Me gusta
6

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?

7

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).

2 Me gusta
8

Gracias @david. Eso es útil, lo solucionaré de esa manera. Gracias de nuevo.

2 Me gusta
9

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?

10

Debes usar encabezados para la clave de API y el nombre de usuario. Consulta http://docs.discourse.org/ para obtener más detalles.

5 Me gusta
11

Eso lo solucionó, gracias de nuevo. :+1:

3 Me gusta