Cela serait une bonne réponse pour moi, sauf que je n’arrive pas à faire fonctionner l’authentification par en-têtes, alors j’essaie de le faire avec des formulaires et je rencontre aussi un problème CSRF. Une solution ? J’essaie de créer un nouveau sujet en utilisant l’API.
Nous aurons besoin de plus d’informations pour pouvoir vous aider. Pouvez-vous partager un extrait de code montrant comment vous essayez d’utiliser l’authentification basée sur les en-têtes ?
Le problème que je rencontre provient principalement du fait que, chaque fois que j’essaie de faire un appel avec une authentification par en-têtes, les en-têtes acceptés sont toujours « User-Api-Key » et « User-Client-Id » au lieu de « Api-Key » et « Api-Username », ce qui me provoque des erreurs CORS. Je ne pense pas avoir besoin de clés basées sur l’utilisateur. J’essaie simplement d’effectuer une requête authentifiée simple pour créer un nouveau sujet. Si j’essaie d’utiliser « User-Api-Key », j’obtiens une erreur 403.
Voici un exemple de code (Angular TypeScript), mais il devrait être similaire pour d’autres configurations :
createNewTopic(postBody: any) {
let url = "myserver.com/posts.json";
let CATEGORY_ARTICLES = 6;
let topicContent = `
<p>Un contenu
</p>
<p>Est-ce que cela a fonctionné ?</p>
`;
let post = {
"title": "Tdk Test 1",
"raw": topicContent,
"category": CATEGORY_ARTICLES,
"target_usernames": "tdekoekkoek",
"archetype": "",
"created_at": new Date()
}
let headers = new HttpHeaders()
.set("Accept", "application/json")
.set("User-Api-Key", DISCOURSE_API_KEY)
.set("User-Key", "system")
.set("Content-Type", "application/x-www-form-urlencoded")
let options = {headers: headers};
return this.http.post(url, post, options);
}
user-api-key et user-client-id constituent une méthode d’authentification complètement différente. Les clés API standard ne fonctionneront pas avec ces en-têtes. Que se passe-t-il lorsque vous utilisez les noms d’en-têtes corrects ? (api-key et api-username)
Je rencontre une erreur CORS car le serveur attend l’en-tête User-Api-Key. J’examine les en-têtes attendus dans la réponse OPTIONS et c’est bien ce qui y est indiqué. Il existe un sujet similaire ailleurs sur ce forum où un utilisateur rencontrait ce problème lors d’un appel depuis une application JavaScript.
Ah, vous essayez donc d’effectuer cette requête depuis une application JavaScript côté client ? Cela n’est pas autorisé pour de nombreuses raisons. Par exemple, si vous incluez une clé API d’administration dans le code source de votre application JavaScript, n’importe quel utilisateur pourrait obtenir un accès complet d’administrateur à votre forum. Voici un sujet précédent sur le sujet.
Oui, c’est bien ce que j’essaie de faire. Cela devrait être documenté plus clairement. C’est toute ma stratégie depuis que j’ai commencé avec Discourse. Je vous remercie pour votre aide. Je me bats avec ce problème depuis des jours en lisant la documentation. Je vais devoir repenser toute mon approche, car je suis en train de construire une application sans serveur, bien que j’aie accès à un serveur Node.js.
Ce n’est pas une restriction propre à Discourse : en général, il est déconseillé d’inclure des identifiants d’administration dans le code source d’un site web.
Si vous pouvez effectuer un appel à l’API Discourse depuis votre serveur Node.js, ce serait probablement la meilleure solution. Si votre application doit être entièrement côté client, demander des clés API spécifiques à l’utilisateur est une option, bien que leur configuration soit beaucoup plus complexe : User API keys specification
À vrai dire, l’accès aux API depuis des applications clientes avec CORS activé est extrêmement courant et standard. Je ne peux pas croire qu’il n’existe pas de méthode plus sécurisée pour le faire. Toute une industrie tourne autour d’API hébergées accessibles depuis différents domaines. En ce qui concerne l’accès avec une clé API utilisateur, j’ai vu comment les créer, mais je ne suis pas clair sur les identifiants réels. J’obtiens toujours une erreur 403 (accès refusé) lorsque j’utilise cette méthode.
Je pense que je me trouve dans une situation similaire.
Quelques précisions sur le cas d’usage :
J’utilise Discourse comme backend et je développe le frontend en VueJS. Je compte n’utiliser que l’API REST. Pour chaque utilisateur de notre plateforme, j’ai créé une clé API utilisateur et j’utilise les deux en-têtes (Api-Key et Api-Username) pour l’authentification.
Chaque utilisateur s’authentifie de manière sécurisée auprès de nos serveurs, puis reçoit son jeton Discourse pour l’authentification. Ensuite, nous souhaitons utiliser ce jeton (dans un frontend VueJS) pour envoyer des requêtes API (publier des sujets, des messages, éditer, etc.).
Rien n’est codé en dur ; tous les jetons sont obtenus après une authentification appropriée.
Le problème :
Je reçois un message d’erreur CORS, même si je l’ai activé dans app.yml et configuré dans la section Sécurité des paramètres d’administration.
L’erreur : Le champ d'en-tête de requête api-key n'est pas autorisé par Access-Control-Allow-Headers
Est-ce que je rencontre l’erreur CORS pour la même raison ? Pourquoi les requêtes CORS sont-elles bloquées lors de l’utilisation des en-têtes « Api-Key » et « Api-Username » ? Je dois mal comprendre leur cas d’usage.
EDIT :
J’ai une théorie concernant mon incompréhension. Lorsque je crée une clé API utilisateur via le point de terminaison « Générer une clé API pour un utilisateur » de l’API REST, cette clé dispose-t-elle de permissions administratives ? N’est-ce pas simplement une clé utilisateur pour publier et commenter ? Si c’est le cas, alors je comprends la restriction.
Merci de me corriger si nécessaire.
@david Discourse ne pourrait-il pas simplement faire signer un secret de session par le serveur avec un HMAC, et ce secret de session pourrait à son tour être utilisé pour signer des éléments dans la session donnée ? S’il était volé, alors le cookie de session ou le nonce CSRF ne le seraient probablement pas non plus. C’est un peu comme une chaîne de certificats : vous n’avez pas à mettre la clé racine dans le navigateur.
Ceux-ci sont uniquement pour l’API d’administration. La façon dont je l’ai compris, c’est que pour les clients JavaScript, vous devez, comme mentionné ci-dessus, consulter User API keys specification.