Message d'erreur : l'erreur n'est pas une URI pouvant faire l'objet d'un proxy

Question

Comment faire une demande API à partir d'une application personnalisée installée dans mon compte vers l'API d'un autre compte sans recevoir le message d'erreur ci-dessous ?

error n'est pas un URI pouvant faire l'objet d'un proxy

Réponse

Le comportement par défaut declient.request est d'envoyer la demande par le biais de la couche proxy de Zendesk, le 403 n'est donc pas une réponse d'URI pouvant fairel'objet d'un proxy .

Pour envoyer une demande client.request à l'API d'un autre compte Zendesk à partir d'une application personnalisée de votre compte, cors: truedans l'objet d'options de la demande. Cela permettra à la demande de contourner la couche proxy de Zendesk, ce qui empêche d'effectuer des demandes HTTP d'un Zendesk à un autre.

// make a request from a custom app in one Zendesk to the API of another Zendesk
 
 function newRequest(){
 var options = {
 url: 'https://subdomain.zendesk.com/api/v2/....',
 headers: { "Authorization": "Bearer OAUTH_TOKEN"},
 type: 'POST',
 data: JSON.stringify({my:"json", values:"go here"}), 
 contentType: "application/json",
 cors: true 
 } 
 client.request(options).then(
 function(response) {
 console.log(response);
 });
 }

Remarque sur les demandes côté client et les demandes côté serveur

Chacun de nos points de terminaison API implémente CORS. Par conséquent, si la demande de l'application provient du côté client, elle échouera avec les réponses CORS, sauf si OAuth est utilisé. Si seule la lecture des données (GET) est requise, définissez le token OAuth pour l'accès en lecture seule à des ressources spécifiques et implémentez-le côté client.

Si la demande de l'application à l'autre API Zendesk consiste à écrire des données (PUT, POST), cette option n'est pas sécurisée car le token est exposé au trafic réseau. Dans la plupart des autres workflows, des paramètres sécuriséspeuvent être utilisés pour empêcher l'exposition du token.

Cependant, les paramètres sécurisés ne fonctionnent pas pour ce workflow, car ils nécessitent que la demande passe par la couche proxy de Zendesk. Si l'écriture de données est nécessaire, envisagez des solutions côté serveur, dans lesquelles la demande à l'autre API Zendesk est traitée côté serveur et la réponse est renvoyée à l'application.

Dégagement de responsabilité : cet article est fourni à titre informatif uniquement. Zendesk ne fournit pas l’assistance pour le code et ne le garantit pas. Publiez tout problème que vous rencontrez dans la section des commentaires ou essayez de rechercher une solution en ligne.

Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.

Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.