En-têtes CORS de l'API incorrects

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 « J'aime »

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

Thanks,
Jessica

1 « J'aime »

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 « J'aime »

@david J’utilise l’authentification unique (SSO) et je souhaite déconnecter l’utilisateur de Discourse lorsqu’il se déconnecte de l’application. Actuellement, j’utilise l’« API d’administration » pour récupérer l’ID de l’utilisateur via /users/by-external/${id}.json, mais je rencontre des erreurs CORS. Je ne souhaite pas activer l’« API utilisateur » pour tous les utilisateurs uniquement pour ce processus de déconnexion. Que me conseillez-vous ?

Qui effectue la requête vers l’API d’administration ? Du JavaScript dans votre application cliente ?

Vous ne devriez pas inclure une API d’administration dans une application cliente JavaScript, car cela signifierait que tout utilisateur de cette application pourrait obtenir un accès administrateur à votre site.

3 « J'aime »

Oui, c’est du JavaScript dans mon application. Je comprends. Alors, quelle est l’alternative ? Puis-je ajouter une « API utilisateur » pour un seul utilisateur et l’utiliser pour effectuer l’appel pour tous les utilisateurs ?

Si vous utilisez l’API utilisateur, vous devez le faire par utilisateur. Vous ne devez pas partager les clés.

Mais la chose la plus courante ici serait de gérer cela côté serveur de votre application. Votre serveur peut envoyer une requête en utilisant les clés API administrateur sans problèmes de CORS et avec moins de préoccupations de sécurité (tant que c’est implémenté de manière sécurisée).

2 « J'aime »

Merci @david. C’est utile, je vais régler ça de cette façon. Merci encore.

2 « J'aime »

Bonjour @david, j’ai essayé de mettre en œuvre une solution backend, mais lorsque j’appelle https://example.com/users/by-external/{EXTERNAL_USER_ID}.json?api_key={DISCOURSE_API_KEY}&api_username=system, la réponse que je reçois est le HTML de la page de connexion (je suppose qu’il y a une redirection). J’ai activé l’option « Connexion requise » et lorsque je la désactive, je reçois la bonne réponse JSON. Je souhaite garder ce paramètre activé — avez-vous une idée de ce qui se passe ?

Vous devez utiliser les en-têtes pour la clé API et le nom d’utilisateur. Consultez http://docs.discourse.org/ pour plus de détails.

5 « J'aime »

Ça a résolu le problème, merci encore. :+1:

3 « J'aime »