Framework: Vue.js
Sending DELETE request(axios) to aws api gateway, that triggers a lambda function.
In API Gateway, I have created the DELETE method
screenshot
I have created/configured the OPTIONS method, where Gateway Responses DEFAULT 4XX AND DEFAULT 5XX are checked. Methods: DELETE and OPTIONS are checked, Access-Control-Allow-Headers: 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token' and Access-Control-Allow-Origin were manually set. i.e. a list of origins.
I confirm configuration was saved by taking a look at Gateway Responses
screenshot
Lambda Function created, responds with the following headers.
screenshot
Code on client side
screenshot
Executing program - Request Response does not include the Access-Control-Allow-Origins.
I've been stuck for a couple of days now, I don't know where else I should look into.
I have tried adding headers to request e.g. Access-Control-Allow-Origin: '*' ,and tried the list of specific origins that will ping the api.
set Access-Control-Allow-Origin in api gateway to '*'
uncheck Lambda Proxy Integration in Delete Method, Any Method in api gateway
lambda function response with 'Access-Control-Allow-Methods': 'list of methods'
use fetch
Related
My API includes various GET, POST and DELETE endpoints set up in AWS API Gateway. Each endpoint is integrated with Lambda and calls its own Lambda python function.
I have set up authorization manually (not through AWS authorizers): I call the endpoints with a bearer token in the "Authorization" header, and the Lambda functions access event["headers"]["Authorization"] to obtain the token. This works fine for POST and DELETE endpoints. However, when calling GET endpoints, the "Authorization" header is missing from the event["headers"] object (only other headers added by AWS are present).
I have tried calling the GET endpoints through various methods. Also worth mentioning that this is not a case sensitivity issue - the token I provide is not found anywhere in the events object.
All my endpoints are configured like this in API Gateway:
Method Request:
Integration Request:
Does API Gateway or Lambda remove the "Authorization" automatically for GET calls?
As you've mentioned that you use CloudFront in front of your API gateway, I believe I know what the problem is.
By default, CloudFront strips away params and headers from the request before forwarding it to origin. You need to modify your cache behaviour to forward the Authorization header to origin.
Go to your CloudFront distribution, and edit the behaviour for that distribution. Then, scroll down to 'Cache key and origin requests'.
You need to create a new cache policy that forwards the Authorization header, like so:
I have scoured over 25 SO posts about this but cannot find a solution to my problem. I have an API Gateway with an HTTP API + route that utilizes a Lambda function integration. From SO posts and AWS documentation, I am reading conflicting information:
From the AWS documentation, I see
If you configure CORS for an API, API Gateway automatically sends a response to preflight OPTIONS requests, even if there isn't an OPTIONS route configured for your API. For a CORS request, API Gateway adds the configured CORS headers to the response from an integration.
If you configure CORS for an API, API Gateway ignores CORS headers returned from your backend integration.
This is exactly what I did; I configured my CORS as follows:
photo
However, I still get the errors:
Access to fetch at 'https://domain.execute-api.aws-region.amazonaws.com/dev/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.
From Cloudwatch, I can see the requests being sent to the API, but for some reason the header isn't properly configured. I do not understand this because I thought API Gateway should handle OPTIONS pre-flight requests for HTTP APIs. I cannot find out what I'm doing wrong.
I had a similar issue, the preflight response had no CORS headers. I noticed that the preflight request included the header: Access-Control-Request-Headers: Content-Type
As soon I added Content-Type to the list of Access-Control-Allow-Headers in the HTTP API configuration it worked for me.
If you configure CORS for an API, API Gateway automatically sends a
response to preflight OPTIONS requests
I think that rule doesn't work for the POST method, because I met the same issue. Then I tried to add an OPTIONS route manually, everything works well.
Route image
I have an aws lambda setup using nodejs to basically receive a request with query parameters, trigger another https request and then send the response back.
Configuration for this otherwise is essentially default.
I have then added a trigger to this lambda in the form of an api gateway HTTP api (not REST api).
I have managed to get the api itself to work however I am getting blocked with the usual CORS issues. (i verified the path with Moesif CORS and origin changer to make sure everything else works and it does).
My CORS configuration in the api gateway is basically set to have
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *
Access-Control-Expose-Headers: No Expose Headers are allowed
Access-Control-Max-Age: 0 seconds
Access-Control-Allow-Credentials: No
I keep finding different pages explaining how to enable cors and so on but mostly seem to be either for an old version of the configuration or for REST api's which look to be quite different.
As it stands, I get this error so i never am allowed to use my api:
Access to fetch at 'https://path.to.my.api?query1=a' from origin 'http://localhost:3000' has been blocked by CORS policy: 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.
I would want to either allow all origins or disable CORS completely for this really.
Disclaimer: I am quite new to the whole aws infrastructure so some terminology related to it might still be not yet understood.
Edit 1:
After some more digging. I have realised that the call that is failing with the cors error is the first of the two calls happening.
That is to say, this is the call that is ending up on my google domain (which normally would redirect temporarily to my aws gateway - this was setup following instrctions on aws to make a "synthetic record" on the domain settings to return a 302 to the execute-api.eu-central-1.amazonaws.com url), not the call that returns the actual data.
Edit 2:
I have tried adding a route in my api gateway for OPTIONS on the same path, pointed to my lambda which returns the appropriate headers when triggered, however this doesn't seem to get called at all in this case. So i imagine api gateway is trying to handle it on its own but failing somehow
We have an Angular SPA front end, which communicates through an AWS API Gateway to a .Net Web API hosted in a Lambda function. This configuration mandates that our API Gateway uses proxy intgeration with the Lambda.
Generally, this works well. We have enabled CORS in our API, and normal requests and responses flow as expected.
However, when something happens that breaks the API Gateway or .Net Lambda Wrapper, such as exceeding the Gateway's (non-configurable) 30-second timeout, or exceeding Lambda's max response size, the response message from the API Gateway does not contain a CORS header. As a result, regardless of the actual error, our front end registers a CORS error.
Is there some way to configure the API Gateway to always return a default CORS header?
Please note that this is happening outside of our code - there is nothing I can do inside of the C# lambda function, as this relates to errors happening above that level.
Yes, you can set it at AWS API Gateway Level
Login to AWS Console, Open API Gateway Service, Select your desired gateway.
On the left-hand side panel, select "Gateway Responses" (this will appear under your selected gateway)
now on the right-hand side, select "Default 5XX"
Add Default Headers for Cors like Access-Control-Allow-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Origin
Save the changes and re-deploy the gateway.
Please refer this image to navigate to the desired section
Hope it helps.
I have a problem with cloudfront.
Here is my scenario:
1) I have a beanstalk url pointing to my get service in java. So far so good and I can see the result by calling : beanstalk url/users/1
2) I added my beanstalk to api gateway as a http and again So far so good and I can see the result by calling : api gateway url/users/1
3) now I want to create a custom domain name for my api gateway so I followed the following :
how to set custom domain for api gateway
I followed that and now I have a cloudfront endpoint poitng to my apigateway deployed stage with a certificate. Please look at the image:
Now when I try this:
https://de90lotxxxxxx.cloudfront.net/users/1
I get :
Failed to load https://de90lotelw3hx.cloudfront.net/users/1: Response to
preflight request doesn't pass access control check: No 'Access-Control-
Allow-Origin' header is present on the requested resource. Origin
'https://s.codepen.io' is therefore not allowed access. The response had
HTTP status code 403.
Just to clarify I did check the api gateway deployed url and I did not get this error so this means that cors are enabled in apigateway. SO when I use cloudfront and certificate do I need to attach any header? any idea?
It sounds like you don't have the CORS headers enabled in api gateway.
Select the resource (/users/{id}), click the Actions button, and select Enable CORS from the drop down. The default settings (shown in the screen capture) is wildcard / all domains. Click the "Enable CORS.." button to confirm.
This will send the CORS headers in the response and allow the cross domain request to s.codepen.io from the web application.
Last, don't forget to deploy the stage after making changes.