Je rencontre un problème avec l’intégration de Discourse sur notre site intranet.
La documentation de l’API indique que la requête Discourse nécessite les en-têtes « API-Key » et « Api-Username » pour s’authentifier et accéder au flux. Cependant, la vérification préalable (pre-flight) indique que « User-API-Key » et « User-Api-Client-Id » sont les valeurs autorisées.
Lorsque l’appel n’est pas effectué via un navigateur, tout fonctionne comme prévu. Mais lorsqu’il est effectué via un navigateur, le serveur indique qu’il nécessite « User-API-Key » et « User-Api-Client-Id ».
J’ai vérifié que la connexion de base fonctionnait avec Postman, ce qui se comporte conformément à la documentation de Discourse.
Si nous transmettons les en-têtes de la documentation, le navigateur bloque la requête en raison de la vérification préalable et renvoie une erreur CORS (Access-Control-Allow-Headers).
Si nous transmettons les en-têtes que le serveur accepte, nous obtenons une erreur « non autorisé » car l’application attend des valeurs nommées différemment.
J’ai essayé d’ajouter des en-têtes à la configuration Docker, mais cela ne semble pas s’appliquer. CORS est activé et l’origine est définie sur « * » dans la configuration.
Nous disposons de deux systèmes d’authentification API différents, ce qui peut prêter à confusion.
Ces éléments concernent l’« API d’administration », décrite sur docs.discourse.org. Elle n’est pas conçue pour être utilisée par des clients JavaScript.
Ces éléments proviennent de la spécification de l’« API utilisateur », qui peut être utilisée par un client JavaScript (et prend donc en charge CORS). Vous trouverez plus de détails à ce sujet ici : User API keys specification
@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.
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).
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 ?
