Résultats API anormaux

Soutien
1

Salut !

J’essaie d’exécuter un appel API pour créer un nouveau sujet. Discourse API Docs

Avec Postman, j’envoie la clé API, le nom d’utilisateur et le type de contenu dans les en-têtes, et les données JSON dans le corps.

J’ai vérifié que le nom d’utilisateur et la clé API sont corrects, mais l’appel API renvoie le HTML de notre page de connexion.

C’est normal ? Comment puis-je contourner cela ?

2

Pourriez-vous s’il vous plaît coller la version cURL de l’appel API que vous essayez d’effectuer ?

3

Bien sûr…

curl -X POST 'https://staging-discuss.newrelic.com/posts.json' \
     -H 'Api-Username: RyanVeitch' -i \
     -H 'Api-Key: My-API-Key' -i \
     -H 'Content-Type: application/json' \
     -d \
'{
    "title": "Mon titre élégant",
    "raw": "Un texte aléatoire pour remplir mon sujet",
    "category": 212,
    "created_at": "2020-06-22"
}'

Dans le terminal, j’obtiens cette sortie :

HTTP/1.1 307 Redirection temporaire
Proxied-By: Service Gateway
Strict-Transport-Security: max-age=31536000; includeSubDomains
Location: https://staging-login.newrelic.com/login?return_to=https%3A%2F%2Fstaging-discuss.newrelic.com%2Fposts.json
content-type: text/plain;charset=UTF-8
content-length: 138

Redirection vers un URI différent : https://staging-login.newrelic.com/login?return_to=https%3A%2F%2Fstaging-discuss.newrelic.com%2Fposts.json%
4

Fais-moi savoir si tu as besoin de quoi que ce soit de ma part pour t’aider dans le dépannage :smiley:

5

Il semble que vous ayez une configuration très personnalisée avec un proxy intermédiaire.

Ce n’est pas un comportement standard de Discourse, il semble donc que cela soit causé par votre proxy spécial.

Peut-être existe-t-il un en-tête spécial que vous pouvez envoyer pour contourner le proxy ? Il faut vérifier la documentation de ce produit.

6

Super ! Merci @Falco - je vais creuser avec notre équipe de développement :slight_smile:

7

Salut @Falco, j’ai réussi à passer le proxy, mais je rencontre maintenant des erreurs 403 BAD CSRF.

Je vois que ce sujet semble être resté inachevé…

As-tu des idées sur la façon de contourner ces erreurs ?

8

Je viens de tester votre exemple de commande curl en local et il fonctionne parfaitement de mon côté, donc la syntaxe est correcte. Serait-il possible que le proxy supprime certains en-têtes ? Cela pourrait expliquer pourquoi vous rencontrez des erreurs CSRF INVALID, car il ne peut plus lire ou accéder aux identifiants de l’API.

9

Merci @blake

Notre proxy est entièrement personnalisé, développé en interne, et constitue la première couche face au public.

Je suis connecté via VPN à notre réseau interne et je ne touche pas l’URL publique, mais l’URL du backend (derrière le proxy). Par conséquent, les requêtes ne devraient pas passer par le proxy.

Notre instance Discourse de staging est en version 2.3.10.

L’API se comporte-t-elle différemment sur cette version ?

10

Non, la version 2.3.10 contient toujours tout le système d’authentification basé sur les en-têtes, donc son comportement ne devrait pas être différent.

Vous tombez sur cette ligne :

ce qui signifie que votre requête est malformée d’une manière ou d’une autre et qu’il n’est pas possible de détecter qu’il s’agit d’une requête API.

11

Comme il s’agit d’une instance de préproduction et non d’un environnement local, nginx ou un autre serveur web sera exécuté avant que les requêtes n’atteignent Discourse. Il est possible que nginx supprime certains en-têtes en fonction de votre configuration. Cela peut apparaître dans les journaux de nginx.

Voici la ligne où les identifiants API sont lus à partir des en-têtes de la requête. Vous pouvez également ajouter des instructions de débogage dans ce fichier pour vérifier si les en-têtes parviennent jusque-là.

12

@blake

Merci ! Je vais en discuter avec notre équipe de développement :smiley:

Je vous remercie pour votre aide