问题
Although CORS has been set up through API Gateway and the Access-Control-Allow-Origin header is set, I still receive the following error when attempting to call the API from AJAX within Chrome:
XMLHttpRequest cannot load http://XXXXX.execute-api.us-west-2.amazonaws.com/beta/YYYYY. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. The response had HTTP status code 403.
I attempted to GET the URL through Postman and it shows the above header is successfully passed:
And from the OPTIONS reponse:
How can I call my API from the browser without reverting to JSON-P?
回答1:
I get the same problem. I have used 10hrs to findout.
https://serverless.com/framework/docs/providers/aws/events/apigateway/
// handler.js
'use strict';
module.exports.hello = function(event, context, callback) {
const response = {
statusCode: 200,
headers: {
"Access-Control-Allow-Origin" : "*", // Required for CORS support to work
"Access-Control-Allow-Credentials" : true // Required for cookies, authorization headers with HTTPS
},
body: JSON.stringify({ "message": "Hello World!" })
};
callback(null, response);
};
回答2:
If anyone else is running into this still - I was able to track down the root cause in my application.
If you are running API-Gateway with custom Authorizers - API-Gateway will send a 401 or 403 back before it actually hits your server. By default - API-Gateway is NOT configured for CORS when returning 4xx from a custom authorizer.
Also - if you happen to be getting a status code of 0 or 1 from a request running through API Gateway, this is probably your issue.
To fix - in the API Gateway configuration - go to "Gateway Responses", expand "Default 4XX" and add a CORS configuration header there. i.e.
Access-Control-Allow-Origin: '*'
Make sure to re-deploy your gateway - and voila!
回答3:
1) I needed to do the same as @riseres and some other changes.This are my response headers:
headers: {
'Access-Control-Allow-Origin' : '*',
'Access-Control-Allow-Headers':'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token',
'Access-Control-Allow-Credentials' : true,
'Content-Type': 'application/json'
}
2) And
According to this documentation:
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html
When you use proxy for lambda functions on API Gateway config, the post or get methods have no added headers, only the options does. You must do it manually in the response(server or lambda response).
3) And
Beside that, I needed to disable the 'API Key Required' option in my API gateway post method.
回答4:
Got my sample working: I just inserted 'Access-Control-Allow-Origin': '*', inside headers:{} in the generated nodejs Lambda function. I made no changes to the Lambda-generated API layer.
Here's my NodeJS:
'use strict';
const doc = require('dynamodb-doc');
const dynamo = new doc.DynamoDB();
exports.handler = ( event, context, callback ) => {
const done = ( err, res ) => callback( null, {
statusCode: err ? '400' : '200',
body: err ? err.message : JSON.stringify(res),
headers:{ 'Access-Control-Allow-Origin' : '*' },
});
switch( event.httpMethod ) {
...
}
};
Here's my AJAX call
$.ajax({
url: 'https://x.execute-api.x-x-x.amazonaws.com/prod/fnXx?TableName=x',
type: 'GET',
beforeSend: function(){ $( '#loader' ).show();},
success: function( res ) { alert( JSON.stringify(res) ); },
error:function(e){ alert('Lambda returned error\n\n' + e.responseText); },
complete:function(){ $('#loader').hide(); }
});
回答5:
I got mine working after I realised that the lambda authoriser was failing and for some unknown reason that was being translated into a CORS error. A simple fix to my authoriser (and some authoriser tests that I should have added in the first place) and it worked. For me the API Gateway action 'Enable CORS' was required. This added all the headers and other settings I needed in my API.
回答6:
If you have tried everything regarding this issue to no avail, you'll end up where I did. It turns out, Amazon's existing CORS setup directions work just fine... just make sure you remember to redeploy! The CORS editing wizard, even with all its nice little green checkmarks, does not make live updates to your API. Perhaps obvious, but it stumped me for half a day.
回答7:
In my case, since I was using AWS_IAM as the Authorization method for API Gateway, I needed to grant my IAM role permissions to hit the endpoint.
回答8:
I am running aws-serverless-express, and in my case needed to edit simple-proxy-api.yaml.
Before CORS was configured to https://example.com, I just swapped in my site's name and redeployed via npm run setup, and it updated my existing lambda/stack.
#...
/:
#...
method.response.header.Access-Control-Allow-Origin: "'https://example.com'"
#...
/{proxy+}:
method.response.header.Access-Control-Allow-Origin: "'https://example.com'"
#...
回答9:
Another root cause of this problem might be a difference between HTTP/1.1 and HTTP/2.
Symptom: Some users, not all of them, reported to get a CORS error when using our Software.
Problem: The Access-Control-Allow-Origin header was missing sometimes.
Context: We had a Lambda in place, dedicated to handling OPTIONS request and replying with the corresponding CORS headers, such as Access-Control-Allow-Origin matching a whitelisted Origin.
Solution: The API Gateway seems to transform all headers to lower-case for HTTP/2 calls, but maintains capitalization for HTTP/1.1. This caused the access to event.headers.origin to fail.
Check if you're having this issue too:
Assuming your API is located at https://api.example.com, and your front-end is at https://www.example.com. Using CURL, make a request using HTTP/2:
curl -v -X OPTIONS -H 'Origin: https://www.example.com' https://api.example.com
The response output should include the header:
< Access-Control-Allow-Origin: https://www.example.com
Repeat the same step using HTTP/1.1 (or with a lowercase Origin header):
curl -v -X OPTIONS --http1.1 -H 'Origin: https://www.example.com' https://api.example.com
If the Access-Control-Allow-Origin header is missing, you might want to check case sensitivity when reading the Origin header.
回答10:
In addition to others comments, something to look out for is the status returned from your underlying integration and if the Access-Control-Allow-Origin header is returned for that status.
Doing the 'Enable CORS' thing only sets up 200 status. If you have others on the endpoint, e.g 4xx and 5xx, you need to add the header yourself.
回答11:
In my case, I was simply writing the fetch request URL wrong. On serverless.yml, you set cors to true:
register-downloadable-client:
handler: fetch-downloadable-client-data/register.register
events:
- http:
path: register-downloadable-client
method: post
integration: lambda
cors: true
stage: ${self:custom.stage}
and then on the lambda handler you send the headers, but if you make the fetch request wrong on the frontend, you're not going to get that header on the response and you're going to get this error. So, double check your request URL on the front.
回答12:
I found a simple solution within
API Gateway > Select your API endpoint > Select the method (in my case it was the POST)
Now there is a dropdown ACTIONS > Enable CORS .. select it.
Now select the dropdown ACTIONS again > Deploy API (re-deploy it)
It worked !
回答13:
In Python you can do it as in the code below:
{ "statusCode" : 200,
'headers':
{'Content-Type': 'application/json',
'Access-Control-Allow-Origin': "*"
},
"body": json.dumps(
{
"temperature" : tempArray,
"time": timeArray
})
}
来源：https://stackoverflow.com/questions/35190615/api-gateway-cors-no-access-control-allow-origin-header