Utilisez ce guide pour résoudre les problèmes courants dans la fenêtre de la console du navigateur liés au message d’erreurAccess-Control-Allow-Origin. Vous trouverez ci-dessous des exemples de messages d’erreur. 

  • Échec du chargement... Aucun en-tête Access-Control-Allow-Origin
  • Demande Cross-Origin bloquée : La politique en matière de même origine interdit la lecture de la ressource à distance ... Raison : En-tête CORS « Access-Control-Allow-Origin » manquant
  • Échec du chargement... La réponse à la demande de contrôle en amont n’a pas franchi la vérification de contrôle d’accès : pas d’en-tête Access-Control-Allow-Origin pour la ressource demandée. L’accès à l’origine... n’est pas autorisé

Cet article contient les sujets ci-dessous.

  • Questions de dépannage
  • Étapes suivantes possibles

Causes des erreurs

Une application Web basée sur le navigateur (peut-être une application Apps Framework) tente de faire un appel de « différentes origines » pour obtenir une « ressource partagée » provenant d’un service Web externe. Ceci est appelé une demande CORS (Cross-Origin-Resource-Sharing).

Il existe une norme CORS basée sur le navigateur qui gère ces appels de différentes origines. Quand certaines conditions ne sont pas remplies, des erreurs peuvent se produire.

Il est possible qu’il ne s’agisse pas d’une erreur mais d’un cas d’utilisation qui n’est pas autorisé intentionnellement par l’application Web de l’utilisateur et le service externe distant.

lorsqu’une origine (www.origin1.com) appelle une autre origine (www.origin2.com), c’est une demande de différentes origines. Certaines conditions doivent être mises en place pour que cette demande fonctionne. Le service externe appelé (www.origin2.com) doit renvoyer dans sa réponse à l’en-tête HTTP Access-Control-Allow-Origin.

Si le service externe ne renvoie pas cet en-tête, l’adhésion du navigateur à la spécification CORS arrête la demande et l’une des erreurs ci-dessus est retournée.

Questions de dépannage

  • Quelle est l’URL de départ de l’appel (ou l’origine) ?
    Cela est parfois dans le message d’erreur lui-même.
  • Comment appelle-t-on l’URL du service externe ?
    Cela se trouve parfois dans le message d’erreur de la console.
  • Qu’est-ce qui est récupéré et pourquoi ? Est-ce un fichier PNG ? Un script, un fichier CSS ou un fichier de police ? Qu’est-ce qui est récupéré exactement et à quoi cela sert-il ?
    Ces éléments peuvent apporter des indications concernant le cas d’utilisation, ainsi que quant à l’importance des ressources de cet emplacement distant.
  • Cette ressource externe nécessite-t-elle une authentification ?
    Si une redirection est nécessaire, il est possible que l’en-tête de réponse Access-Control-Allow-Origin ne soit pas renvoyé, de sorte que l’appel échouera. Copiez l’URL de la ressource directement dans un nouvel onglet de navigateur incognito. Cela peut être un bon test pour savoir s’il est possible d’y accéder dans des circonstances générales, mais cela ne garantit pas qu’il fonctionnera dans le code de l’application Web.
  • Pouvez-vous voir l’appel de la méthode HTTP OPTIONS dans l’onglet Réseau du navigateur ?
    Lorsque des en-têtes de demande, une authentification ou d’autres conditions personnalisées existent dans la requête d’origines croisées, le navigateur effectue un appel HTTP supplémentaire. On parle aussi d’appel en amont. Le code de l’application Web n’y figure pas explicitement. Le navigateur en arrière-plan le crée et en fait partie, car il appartient à la norme de spécification CORS.
    Lorsque cet appel OPTIONS est effectué, certaines valeurs doivent figurer dans la réponse de cet appel pour que cela réussisse et pour l’appel HTTP réel de la ressource. Si l’appel OPTIONS échoue, la ressource n’est pas récupérée et une erreur CORS devrait apparaître dans la console du navigateur. Notez si vous voyez un appel OPTIONS. Notez également si vous voyez un appel de redirection (état 302) se déroulant juste avant l’appel OPTIONS. Si une redirection est en cours pour un appel OPTIONS, l’appel OPTIONS échouera probablement. Cela signifie que l’appel pour obtenir la ressource échouera également et déclenchera une erreur CORS.
  • À quoi sert d’obtenir une ressource externe ?
    Découvrez pourquoi cette ressource externe est récupérée en premier lieu. Cela peut être important pour trouver des solutions ou des changements nécessaires.
  • Générez un fichier HAR.
    Obtenir un aperçu de l’appel ayant échoué et de ce qui s’est produit immédiatement avant et après peut aider à résoudre le problème et à éviter que l’utilisateur n’ait à le reproduire. Les en-têtes des demandes et des réponses peuvent être consultés, ainsi que l’identification des appels OPTIONS et des redirections.

Étapes suivantes possibles

  • Qui est propriétaire du serveur externe ? Le serveur peut éventuellement être modifié pour respecter la norme CORS et renvoyer l’Access-Control-Allow-Originen-tête. Cependant, même si le serveur est sous contrôle interne, ce n’est pas nécessairement la panacée. Il peut y avoir de bonnes raisons qui expliquent qu’un service externe particulier ne veuille pas partager une ressource. Si le serveur externe n’est pas contrôlé en interne, il est possible de travailler avec ce fournisseur ou de trouver une autre solution de contournement, en supposant que le cas d’utilisation soit considéré comme valable.
  • L’application est-elle écrite en utilisant Zendesk App Framework ? Un serveur proxy principal est disponible par l’appel client.request(). Utilisez ce proxy en configurant cors:false dans les paramètres de client.request. Notez que « false » est également la valeur par défaut du paramètre. Étant donné que le service proxy est un service principal, il n’est pas nécessaire de respecter la spécification CORS basée sur le navigateur, l’appel d’origine croisée peut éventuellement réussir en utilisant le proxy.
    Ce n’est pas toujours la panacée. Le service proxy ne supporte pas la récupération de fichiers binaires ou d’informations binaires provenant de services externes. Il peut y avoir d’autres raisons spécifiques pour l’application, ce n’est pas une solution.
  • La ressource peut-elle être incorporée directement dans l’application Web ? Au lieu d’utiliser une origine croisée pour obtenir une ressource, pensez à l’inclure à l’application Web. Cela évite que l’appel provienne de toutes les sources (car il s’agit désormais d’une ressource locale) et que les problèmes CORS disparaissent. Ce n’est cependant pas toujours une solution. Parfois, les URL de ressources externes ne sont pas connues à l’avance, ou la ressource est trop volumineuse pour tenir lieu de ressource locale, ou la ressource change trop souvent pour être téléchargée en tant que ressource statique locale.
  • Quelle est la version du navigateur ? Bien que la spécification CORS soit une norme, les messages d’erreur renvoyés par les navigateurs peuvent être différents. Chrome renvoie des messages de console différents de ceux de Firefox. 
  • Parfois, il n’y a pas de solution. Parfois, une demande de ressource provenant d’un service externe n’est pas destinée à être partagée dans le contexte d’une application Web de navigateur. Le propriétaire de la ressource décide s’il partage la ressource ou non. Ce n’est pas du ressort de l’application Web. Ce comportement peut être tel que vous l’avez conçu.

Pour en savoir plus, consultez ces ressources :

  • Article de Wikipedia : Partage de ressources d’origines multiples
  • Article de Web.Dev : Partage de ressources d’origines multiples (CORS)
  • Article de Mozilla : Partage de ressources d’origines multiples (CORS)
  • Article de Mozilla : OPTIONS
  • Article de Fetch : Fetch
  • Article de Fetch : Protocole CORS
Réalisé par Zendesk