CORS Settings for AWS Lambda via API Gateway - aws-lambda

Am getting the following error:
Access to fetch at 'https://...' from origin 'https://...' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
p.s. from blazor wasm web api call

Enabling CORS support for Lambda or HTTP non-proxy integrations and AWS service integrations
For a Lambda custom (non-proxy) integration, HTTP custom (non-proxy) integration, or AWS service integration, you can set up the required headers by using API Gateway method response and integration response settings. When you enable CORS by using the AWS Management Console, API Gateway creates an OPTIONS method and attempts to add the Access-Control-Allow-Origin header to your existing method integration responses.
This doesn’t always work, and sometimes you need to manually modify the integration response to properly enable CORS. Usually this just means manually modifying the integration response to return the Access-Control-Allow-Origin header.
exports.handler = async (event) => {
const response = {
statusCode: 200,
headers: {
"Access-Control-Allow-Headers" : "Content-Type",
"Access-Control-Allow-Origin": "https://www.example.com",
"Access-Control-Allow-Methods": "OPTIONS,POST,GET"
},
body: JSON.stringify('Hello from Lambda!'),
};
return response;
};
Have you tried the following?

make sure to set
Access-Control-Allow-Origin
*
Access-Control-Allow-Headers
*
Access-Control-Allow-Methods
*
p.s.
you may need to make the above more restrictive e.g. to your apps domain
also don't forget to clear your browsers cache
https://console.aws.amazon.com/apigateway/main/develop/cors

Related

API Gateway CORS: How to get path and body into AWS Lambda?

I am having trouble getting the path and body into an AWS Lambda using AWS API Gateway. It works on Chrome with security disabled, but once I deploy the front end to S3, the path and body do not show up in the event that is sent to the Lambda. Here is the log from when I send locally:
And here is the log from when I send it with Chrome security enabled:
With Chrome security enabled, I get the following response:
"Access to XMLHttpRequest at 'https://1jlcspd2re.execute-api.us-east-1.amazonaws.com/genecab-bracket-optimizer' from origin 'http://www.genecab.com.s3-website-us-east-1.amazonaws.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status."
The JSON payload looks the same on both requests. Here are the headers and payload from when I send with Chrome security disabled:
And with Chrome security enabled:
I have the following CORS configuration on the AWS API Gateway:
Any help would be appreciated.
After searching extensively, I discovered that I have to return an Access-Control-Allow-Origin header when the httpMethod=OPTIONS on the request. Here is my java code:
MyLambdaResponse lambdaResponse = new MyLambdaResponse();
Map<String, String> headers = new HashMap<>();
headers.put("Access-Control-Allow-Origin", "*");
lambdaResponse.setHeaders(headers);
if (input!=null) {
if(input.toString().contains("httpMethod=OPTIONS")) {
return lambdaResponse;
}
}

CORS policy error with AWS API Gateway in React

I am trying to set up an API Gateway to call another lambda function that will upload an image to S3. The feature works well when I am using an app like POSTMAN, however when I run the browser using React I am getting the following error.
Access to fetch at 'https://.../upload' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
In my API Gateway I have the following configuration for that method
Gateway Responses for UserUpload API: default 4XX (not checked), default 5XX (not checked)
Methods: post (checked), options (checked)
Access-Control-Allow-Methods: options, post
Access-Control-Allow-Headers: '*'
Access-Control-Allow-Origin: '*'
This API uses an authorizer, I am using the one provided by Auth0 and have not edited the code at all.
And the function that my authorizer calls returns the response like the below (eg happy path):
exports.handler = async (event) => {
//do data checks and upload to s3
return {
headers: {
"Content-Type": "application/json",
"Access-Control-Allow-Methods": "*",
"Access-Control-Allow-Origin": "*",
},
statusCode: 200,
body: JSON.stringify({ message: "success" }),
};
This is my first time setting up both a lambda function, authorisation provider and API Gateway so I might be missing something obvious. I have also tried added mode: no-cors to my fetch POST requests however they still fail in a very similar way.
From what I can tell by looking at the logs of the authorizer and the lambda function that uploads the images, is that they are not even being called. So it appears the CORS error is with the API Gateway.
I have seen in a few tutorials that in their aws template yaml files they add an option AddDefaultAuthorizerToCorsPreflight as False. I can't see this anywhere in the API Gateway console.
Update: I have tested my function with the custom authoriser turned off and it works. So I know that CORS works for the options method, and for the returned request on the lambda function. It is the custom authoriser that is the problem.
The flow is currently:
Method Request - Auth: my-auth-0-authorizer
Integration Request - Type: Lambda_proxy
Lambda function
Integration response - [greyed out Proxy integrations cannot be configured to transform responses]
Method Response: HTTP Status: Proxy (with Access-Control-Allow-Origin in the response headers)
What do I have to do differently or change to allow my authoriser to respect the CORS config?
Update: After leaving my API Gateway for a day, successful responses are now working (using the flow mentioned above). I am not sure if there was a glitch in the system or there was unexpected occurring but it is now working. I am still getting a CORS issue but now only with bad responses.
The custom authoriser fails by return context.fail("Unauthorized"); and when this occurs my browser gets a CORS error. Do I have to set up special gateway responses for 4XX responses?

AWS API Gateway : CORS and Empty Event Object

I have been struggling with setting up AWS API Gateway to pass Query string parameters to my Lambda function.
If I set to API to use Lambda proxy integration, I get a CORS error at the Web client
[index.html:1 Access to XMLHttpRequest at 'https://g2kza1o79f.execute-api.eu-west-2.amazonaws.com/prod/gettest8' from origin 'null' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.]
( - even when I have set the API with CORS enabled.
If I set the API to not use Lambda proxy integration, and CORS enabled, the API call works (no CORS error), but the event object received in my Lambda function is empty( hence no query string parameters).
In both cases I am using the GET method.
I can see in the Method Response Header the Access-Control-Allow-Origin option is present, but cannot access the Integration Response
Question: How can I set-up my API to pass query string parameters through to my Lambda function without getting the CORS error? I will also be wanting to set up APIs for POST requests to other Lambda functions.
I believe it is related to First Enable CORS Then Deploy API.
A good thread could be found here.
API Gateway CORS: no 'Access-Control-Allow-Origin' header

POST request to AWS API Gateway access

I have a AWS Lambda function that is triggered via AWS API Gateway. When I test my function on Lambda it is working. When I send a POST request to the API url via ajax, I get a 502 bad gateway error.
XMLHttpRequest cannot load https://xxxxxxxx.execute-api.us-east-1.amazonaws.com/prod/myLambdaFunction. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'mywebsite.com' is therefore not allowed access. The response had HTTP status code 502.
Obviously this was a CORS issue, so I thought I could change the CORS settings in my AWS API Gateway URL which I did, but I am still getting an error for this.
What do I have to change on AWS side or my own to be able to POST to the URL?
Unfortunately there is a known issue with many classes of 4xx and 5xx errors where CORS headers will not be sent, even if you've added CORS support via the console.
As noted in comments, the CORS error is a side effect of the fact that your API is returning a 502. This often occurs if you are using the LAMBDA_PROXY integration type and are returning invalid JSON from your Lambda function.
Please try either using the test invoke functionality from the console or enable logging in your API to debug further.
I solved that exact same problem by outputting the CORS header myself.
See below - and I hope that'll help.
Teebo
Amazon docs
function respond(context, responseData) {
var response = {
statusCode: 200,
body: JSON.stringify(responseData),
headers: {
"Content-Type": "application/json; charset=utf-8",
"Access-Control-Allow-Origin": "*"
}
};
context.succeed(response); }

Invoking JAX-WS web services from remote machine using JQuery and AJAX

I am new to Java SOAP web services. Recently I have created a web service using the JAX-WS specification. This is deployed in the WebLogic server I am using in my machine. Now when I want to invoke the web service from the web application written in JavaScript remote machine on another server, it giving me the following error.
I have also browsed for some other similar kind of posts like this
I am sending the request using JavaScript and SoapClient.js Library.
My invocation code is:
SOAPClient.invoke("http://inhydkvaranasi1:7001/TodoWS/TodoListService",
"getTodos", p1, true, function(data) {
$("#todolist").html('');
if (Object.keys(data).length < 1) {
$("#todolist").html(
"<h4>No Todos Available right now!</h4>");
} else {
Object.keys(data).forEach(
function(key) {
$("#todolist").append(
"<li>" + data[key]["task1"]
+ "(Priority "
+ data[key]["id0"]
+ ") </p>");
});
}
});
The request sent by the XMLHttpRequest() object did not get a response header as Access-Control-Allow-Origin in the XML response.
How could I solve this problem? So that my web service can be used publicly by any user from different domain on different server.
Look at the CORS HTTP headers (from codingpedia.org):
Client side HTTP request headers. These are headers that clients may use when issuing HTTP requests in order to make use of the cross-sharing feature:
Origin: URI indicating the server from which the request initiated. It does not include any path information, but only the
server name
Access-Control-Request-Headers: used when issuing a preflight request to let the server know what HTTP headers will be used when the
actual request is made
Access-Control-Request-Method: used when issuing a preflight request to let the server know what HTTP method will be used when the
actual request is made
Server side HTTP response headers. These are the HTTP headers that the server sends back for access control requests:
Access-Control-Allow-Origin: specifies the authorized domains to make cross-domain request (you should include the domains of your
clients or “*” if you want the resource public and available to
everyone – the latter is not an option if credentials are allowed
during CORS requests)
Access-Control-Expose-Headers: lets a server white list headers that browsers are allowed to access
Access-Control-Max-Age: indicates how long the results of a preflight request can be cached.
Access-Control-Allow-Credentials: indicates if the server allows credentials during CORS requests
Access-Control-Allow-Methods:
indicates the methods allowed when accessing the resource
Access-Control-Allow-Headers: used in response to a preflight request to indicate which HTTP headers can be used when making the
actual request

Resources