Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Partage des ressources entre origines multiples pour les API REST dans API Gateway
Le partage des ressources entre origines multiples (CORS)
Activation ou non de la prise en charge de CORS
Une demande HTTP cross-origin est une demande effectuée pour :
-
Un autre domaine (par exemple, de
example.comàamazondomains.com) -
Un autre sous-domaine (par exemple, de
example.comàpetstore.example.com) -
Un autre port (par exemple, de
example.comàexample.com:10777) -
Un autre protocole (par exemple, de
https://example.comàhttp://example.com)
Si vous ne parvenez pas à accéder à votre API et que vous recevez un message d'erreur contenant Cross-Origin Request Blocked, vous devrez peut-être activer CORS.
Les demandes HTTP cross-origin peuvent être réparties en deux types : les demandes simples et les demandes non simples.
Activation de CORS pour une demande simple
Une demande HTTP est simple si toutes les conditions suivantes sont réunies :
-
Elle est émise par rapport à une ressource d’API qui autorise uniquement les demandes
GET,HEADetPOST. -
S’il s’agit d’une demande de la méthode
POST, elle doit inclure un en-têteOrigin. -
Le type de contenu de la charge utile de la demande est
text/plain,multipart/form-dataouapplication/x-www-form-urlencoded. -
La demande ne contient pas d’en-têtes personnalisés.
-
Les exigences supplémentaires répertoriées dans la documentation CORS Mozilla pour les demandes simples
.
Pour les demandes de méthode POST cross-origin simples, la réponse de votre ressource doit inclure l’en-tête Access-Control-Allow-Origin: '*' ou Access-Control-Allow-Origin:.'origin'
Toutes les autres demandes HTTP cross-origin sont des demandes non simples.
Activation de CORS pour une demande non simple
Si les ressources de votre API reçoivent des demandes non simples, vous devez activer une prise en charge de CORS supplémentaire en fonction de votre type d’intégration.
Activation de CORS pour les intégrations autres que de proxy
Pour de telles intégrations, le protocole CORS
Pour créer une réponse en amont :
Créez une méthode
OPTIONSavec une intégration simulée.-
Ajoutez les en-têtes de réponse suivants à la réponse de la méthode 200 :
-
Access-Control-Allow-Headers -
Access-Control-Allow-Methods -
Access-Control-Allow-Origin
-
-
Définissez le comportement de transfert direct sur
NEVER. Dans ce cas, la demande de méthode d’un type de contenu non mappé sera rejetée en renvoyant une réponse HTTP 415 Type de support non pris en charge. Pour plus d’informations, consultez Comportement des demandes de méthode pour les charges utiles sans modèles de mappage pour REST APIs dans API Gateway. -
Entrez des valeurs pour les en-têtes de réponse. Pour autoriser toutes les origines, toutes les méthodes et les en-têtes communs, utilisez les valeurs d’en-tête suivantes :
-
Access-Control-Allow-Headers: 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token' -
Access-Control-Allow-Methods: 'DELETE,GET,HEAD,OPTIONS,PUT,POST,PATCH' -
Access-Control-Allow-Origin: '*'
-
Après avoir créé la demande en amont, vous devez renvoyer l’en-tête Access-Control-Allow-Origin: '*' ou Access-Control-Allow-Origin: pour toutes les méthodes compatibles CORS pour toutes les 200 réponses, au moins.'origin'
Activation de CORS pour les intégrations autres que de proxy à l’aide de la AWS Management Console
Vous pouvez utiliser la AWS Management Console pour activer CORS. API Gateway crée une méthode OPTIONS et ajoute l’en-tête Access-Control-Allow-Origin à vos réponses d’intégration de méthode existantes. Cela ne fonctionne pas toujours et vous devez parfois modifier manuellement la réponse d’intégration pour renvoyer l’en-tête Access-Control-Allow-Origin pour toutes les méthodes compatibles CORS pour toutes 200 réponses, au moins.
Si les types de médias binaires sont définis sur */* pour votre API, lorsqu’API Gateway crée une méthode OPTIONS, remplacez contentHandling par CONVERT_TO_TEXT.
La commande update-integration suivante modifie le paramètre contentHandling en CONVERT_TO_TEXT pour une demande d’intégration :
aws apigateway update-integration \ --rest-api-idabc123\ --resource-idaaa111\ --http-method OPTIONS \ --patch-operations op='replace',path='/contentHandling',value='CONVERT_TO_TEXT'
La commande update-integration-response suivante modifie le paramètre contentHandling en CONVERT_TO_TEXT pour une réponse d’intégration :
aws apigateway update-integration-response \ --rest-api-idabc123\ --resource-idaaa111\ --http-method OPTIONS \ --status-code 200 \ --patch-operations op='replace',path='/contentHandling',value='CONVERT_TO_TEXT'
Activation de la prise en charge de CORS pour les intégrations de proxy
Pour une intégration de proxy Lambda ou de proxy HTTP, votre backend est chargé de renvoyer les en-têtes Access-Control-Allow-Origin, Access-Control-Allow-Methods et Access-Control-Allow-Headers, car une intégration de proxy ne renvoie pas de réponse d’intégration.
Les exemples de fonctions Lambda suivants renvoient les en-têtes CORS requis :