La Passerelle API de la SCRO: pas de "Access-Control-Allow-Origin' en-tête
Bien que la SCRO a été mise en place par Passerelle API et le Access-Control-Allow-Origin
en-tête est réglé, j'ai toujours l'erreur suivante lorsque vous tentez d'appeler l'API de l'AJAX dans google Chrome:
XMLHttpRequest ne peut pas charger http://XXXXX.execute-api.us-west-2.amazonaws.com/beta/YYYYY. Pas de "Access-Control-Allow-Origin' en-tête est présent sur la ressource demandée. Origine 'null' est donc pas autorisé à accéder. La réponse avait le code d'état HTTP 403.
J'ai tenté de récupérer l'URL par le biais de Facteur et il montre l'entête ci-dessus est réussi:
Et dans les OPTIONS de la reponse:
Comment puis-je appeler mon API à partir du navigateur sans revenir à l'JSON-P?
- L'avez-vous mis en place sur le S3? Si oui, pourriez-vous mettre en place la
Bucket Policy
? Assurez-vous que vous disposez de la méthode dans votre politique - Pas de @iSkore il est mis en place sur un autre serveur pour le test. J'ai aussi essayé lors de l'accès au fichier localement à partir de mon PC et par d'autres serveurs. Est-il quelque chose que je dois configurer sur la page d'hébergement de serveur pour permettre l'utilisation de la SCRO? Ma compréhension est que seul le serveur d'API nécessite des paramètres modifiés pour la SCRO.
- Donc, avez-vous ajouté un CORS de la politique de votre API si? Et qu'entendez-vous sur la page d'hébergement de serveur"? Juste un serveur ou un serveur statique
- Oui, par le biais de la "Activer la SCRO" options de Passerelle API AWS
- Gotcha, et avez-vous inclure une politique avec qui?
- Cela peut ou ne peut pas aider mais a trouvé ce lien: stackoverflow.com/questions/10636611/...
- L'appel OPTIONS réussir? Pouvez-vous poster les résultats de l'appel OPTIONS? C'est le résultat qui vous permettrait de voir si les OPTIONS d'échec de l'appel en raison d'authentification ou d'autres erreurs
- J'ai ajouté les OPTIONS résultat de la question
- Alors, quels sont exactement vous essayez de faire? OBTENIR les données ou trouver quelles OPTIONS de connexion sont disponibles. Aussi, si vous êtes en utilisant CloudFront, parfois, il faut un certain temps pour faire livrer vos fichiers à la CAN. Ceci s'applique uniquement si vous avez configuré le CloudFront dans la dernière heure ou deux.
- Hey le vérifier sur trop. Ce mec est à l'aide d'AJAX trop. stackoverflow.com/questions/20035101/...
- La Passerelle API équipe ici... Si vous utilisez l'option " Activer la SCRO, la fonction dans la console, la configuration devrait être correct. Ma meilleure supposition est que vous n'êtes pas en invoquant le bon chemin d'accès aux ressources dans votre API en JavaScript, le navigateur est en cours d'exécution. Si vous essayez de faire un appel API pour une inexistant méthode/ressources/étape, vous recevrez un générique 403 avec aucun de la SCRO en-têtes. Je ne vois pas comment le navigateur n'a pu manquer de le Access-Control-Allow-Origin-tête si vous appelez le droit de ressources étant donné que les OPTIONS d'appel en Facteur clairement contient tous les CORS des en-têtes.
- J'ai vérifié que la ressource chemin d'accès est correct et a réussi à accéder à la méthode directement via l'URL dans le navigateur Chrome. Aussi, le message d'erreur mentionne explicitement l'absence de l '"Access-Control-Allow-Origin' en-tête.
- La plupart du temps ce trompeuse message d'erreur est dû à la faute avec une erreur 404 ou une erreur 403. Dans ces cas, la SCRO en-têtes ne sont pas renvoyées par le service. Le client est-il de la signature de la demande avec les informations d'identification et la politique IAM pour ces informations d'identification autorisé à appeler l'API/méthode? Pouvez-vous confirmer que l'URL utilisée par le client est-il correct?
- le client n'est pas la signature de la demande parce que l'API est authentifié par la ressource que l'on appelle à l'aide spécifique à un utilisateur de jeton, de sorte que les informations d'identification ne sont pas un facteur. Je peux appeler l'API en visitant l'URL directement dans le navigateur et je reçois la réponse appropriée.
- Avez-vous trouvé une solution pour cela? Je suis donc passé par le même problème ici.
- Je pense que j'ai enlevé l'API et rajouté, puis activé la SCRO et il a travaillé pour moi. Je ne sais pas encore exactement ce qui a changé, l'amenant à travailler.
- Ah, je l'ai juste essayé, et ça marche pour des raisons étranges. J'ai des centaines de ressources et de méthodes, et il va être un enfer d'une tâche de recréer tous. Cela peut également être réalisé en spécifiant manuellement l'en-tête dans l'Intégration de Réponse. De toute façon, c'est beaucoup de travail. Merci pour l'aide.
- Mes méthodes et de la scène ont été générés automatiquement par Lambda. J'ai activé la SCRO après le fait. Même les erreurs que l'OP. J'ai explosé l'auto généré des trucs, créé une nouvelle API et des méthodes, déployé à une nouvelle étape, et il a bien fonctionné.
- juste essayé ce, avec pas de chance 🙁
- Voir ma réponse ici, il pourrait être lié à la clé API problème, stackoverflow.com/questions/34325009/...
- Nous avons besoin de voir les en-têtes de la réponse de la requête ajax qui est en train de jeter ladite erreur. Facteur résultats ne sont pas vraiment tout ce qui utile. Les états d'erreur qui dit d'en-tête n'existe pas, je suis plus enclin à croire qu'il n'existe pas qu'une erreur est levée indiquant que quelque chose n'existe pas quand il fait réellement.
The response had HTTP status code 403
spécifiquement conseils que vous recevez une réponse d'erreur, et l'erreur de réponse ne devrait pas avoir dit de la scro-tête.- Ma solution a été de supprimer la Passerelle API et en Créer un nouveau, enble de la scro. Merci!!!
Vous devez vous connecter pour publier un commentaire.
J'obtiens le même problème. J'ai utilisé 10 heures pour trouver.
https://serverless.com/framework/docs/providers/aws/events/apigateway/
Si quelqu'un d'autre est en cours d'exécution dans la toujours j'ai été en mesure de traquer la cause de racine de mon application.
Si vous utilisez l'API de Passerelle avec la coutume Approbateurs - API-Passerelle envoyer un 401 ou 403 en arrière avant qu'il n'arrive jusqu'à votre serveur. Par défaut, l'API Gateway n'est PAS configuré pour la SCRO lors du retour 4xx d'une coutume de l'autorisateur.
Aussi - si vous arrive d'être l'obtention d'un code d'état de
0
ou1
à partir d'une demande en cours d'exécution à travers la Passerelle API, c'est probablement votre problème.À fixer - dans l'API de configuration de la Passerelle - aller à la "Passerelle des Réponses", développez "par Défaut 4XX" et ajoutez un CORS de configuration de l'en-tête là. c'est à dire
Assurez-vous de re-déployer votre passerelle - et le tour est joué!
aws apigateway update-gateway-response --rest-api-id "XXXXXXXXX" --response-type "DEFAULT_4XX" --patch-operations op="add",path="/responseParameters/gatewayresponse.header.Access-Control-Allow-Origin",value='"'"'*'"'"'
1) j'avais besoin de faire la même chose que @riseres et quelques autres changements.Ce sont mes en-têtes de réponse:
2) Et
Selon cette documentation:
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html
Lorsque vous utiliser de proxy pour les lambda fonctions sur la Passerelle API de configuration, la méthode post ou get n'ont pas ajouté des en-têtes, seules les options ne. Vous devez le faire manuellement dans la réponse(serveur ou lambda réponse).
3) Et
A côté de cela, j'avais besoin de désactiver la "Clé API Nécessaires" option dans ma passerelle API méthode post.
Reçu mon échantillon de travail: je juste inséré "Access-Control-Allow-Origin': '*', à l'intérieur de en-têtes:{} dans le générés nodejs fonction Lambda. J'ai fait pas changements pour le Lambda-API générée couche.
Voici mon NodeJS:
Voici mon appel AJAX
J'ai eu le mien de travail, après j'ai réalisé que le lambda authoriser a défaut et pour une raison inconnue, qui était en cours de traduction dans une de la SCRO erreur. Une solution simple à mon authoriser (et certains authoriser les tests que j'aurais ajouté en premier lieu) et cela a fonctionné. Pour moi, la Passerelle API action "Activer la SCRO" était nécessaire. Cet ajout de tous les en-têtes et d'autres paramètres que j'ai besoin dans mon API.
Si vous avez essayé tout ce qui concerne ce problème, en vain, vous finirez où je l'ai fait. Il s'avère, Amazon existantes de la SCRO instructions d'installation fonctionnent très bien... juste assurez-vous que vous n'oubliez pas de redéployer! De la SCRO assistant d'édition, même avec toute son joli petit coches vertes, ne pas faire de mises à jour en direct de votre API. Peut-être évident, mais il perplexe moi pour une demi-journée.
Je suis en cours d'exécution
aws-serverless-express
, et dans mon cas nécessaires pour modifier lessimple-proxy-api.yaml
.Avant de la SCRO a été configuré pour
https://example.com
, j'ai juste échangé en mon nom du site et redéployés parnpm run setup
, et il mis à jour mon lambda/pile.Dans mon cas, depuis que j'ai été en utilisant AWS_IAM que la méthode d'Autorisation, j'avais besoin d'accorder mon rôle IAM autorisations de frapper le point de terminaison.
Une autre cause de ce problème est peut-être une différence entre HTTP/1.1 et HTTP/2.
Symptôme: Certains utilisateurs, pas tous d'entre eux, a rapporté à obtenir une de la SCRO d'erreur lors de l'utilisation de notre Logiciel.
Problème: La
Access-Control-Allow-Origin
en-tête manquait parfois.Contexte: Nous avons eu un Lambda en place, dédié à la gestion
OPTIONS
demande et répondant avec le correspondant de la SCRO en-têtes, commeAccess-Control-Allow-Origin
correspondant à une liste blancheOrigin
.Solution: La Passerelle API semble transformer tous les en-têtes de bas-de-casse pour HTTP/2 appels, mais maintient la capitalisation pour HTTP/1.1. De ce fait, les accès à
event.headers.origin
à l'échec.Vérifier si vous rencontrez ce problème aussi:
En supposant que votre API est situé à
https://api.example.com
, et votre front-end est àhttps://www.example.com
. Utilisation de CURL, faire une demande à l'aide de HTTP/2:La sortie de la réponse devrait inclure l'en-tête:
< Access-Control-Allow-Origin: https://www.example.com
Répétez la même opération à l'aide de HTTP/1.1 (ou avec une minuscule
Origin
en-tête):Si le
Access-Control-Allow-Origin
en-tête est manquante, vous pourriez vouloir vérifier le respect de la casse lors de la lecture de laOrigin
en-tête.Dans mon cas, j'ai été tout simplement écrit à la demande de récupération de l'URL de mal. Sur
serverless.yml
, vous définissezcors
àtrue
:puis sur le lambda gestionnaire vous envoyer les en-têtes, mais si vous en faites la demande de récupération de mal sur le frontend, vous n'allez pas vous faire que d'en-tête de la réponse et vous obtenez cette erreur. Donc, vérifiez vos URL de la requête sur le devant.
J'ai trouvé une solution simple à l'intérieur de
Passerelle API > Sélectionnez votre API endpoint > Sélectionnez la méthode (dans mon cas c'était le POST)
Maintenant, il y a une liste déroulante ACTIONS > Activer la SCRO .. le sélectionner.
Maintenant, sélectionnez le menu déroulant ACTIONS de nouveau > Déployer des API (re-déployer)
Il a travaillé !