I have a non-simple cross-origin HTTP request to my POST method in API Gateway.
I have set up CORS support as per : https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html
The POST request succeeds from Postman/AWS console but fails from a local development server where the origin is of type localhost.
After browsing through many answers and trying to debug i have concluded that all the required headers are present on the integration response of both POST and OPTIONS. However when making a call to OPTIONS from postman i see that it returns 500 Internal server error. This looks like a configuration issue with OPTIONS. How do i fix it? I don't have a serverless yaml, the gateway has been configured manually. Any way of resolving this via the console ?
Related
I have a django backend and a Vue 3 frontend.
For handling some request, my backend needs an 'Id-Client' header in the headers of the request.
Developing my BE everything worked like a charm, but now that I'm writing the FE I'm encountering some issues.
As I said before, I need to append an header to my headers in every request.
So the first step was the following:
// Note that the idClient is dynamic and can change.
this.$axios.setHeader('Id-Client', idClient)
const data = await this.$axios.$get(url)
But I can't get it to work, if I try to send that request, my GET request becomes (I don't know why) a OPTIONS request and I get the error "cross origin resource sharing error: HeaderDisallowedByPreflightResponse"
Instead if I remove the set header
// this.$axios.setHeader('Id-Client', idClient)
const data = await this.$axios.$get(url)
The server just respond me correctly giving me the error that the request is missing the 'Id-Client' in the header.
I also have a few request that don't need the 'Id-client' header and those request work, so I don't think is a CORS problem.
Well but is looks like CORS issue. CORS policies are not triggered by simple requests. By adding custom header, your requests are no longer simple and trigger CORS policies (sending OPTIONS before GET)
Your only option is to configure your backend server to reply to OPTIONS requests with the correct headers - Access-Control-Allow-Origin and Access-Control-Allow-Headers (server telling the browser "yes, im ok to accept particular custom header")
IF (and only if) you are planning to serve your Vue SPA from the same API server in production (same origin), you can avoid similar CORS issues during development by using Webpack Dev server Proxy - your SPA will send API requests to Webpack Dev Server (used for developing SPA) and Proxy will route it to your Django dev server. That way all request from your SPA are to the same origin and you don't need to care about CORS at all...
I have a custom domain name in AWS API gateway. I am using the same domain for 2 separate API stages. One API stage is REST API, and the other HTTP API.
When I test out my setup, everything works for the REST API. However, the mapping path for HTTP API is not working and I get status-code = 404 Not Found, with 0kb body.
references used:
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-mappings.html
https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mappings.html
From my testing in postman, i get the following result when calling the custom domain.
1. {{api.gateway.custom.domain.url}}/foobar - works
2. {{api.gateway.custom.domain.url}}/this-no-work/foobar - 404
3. {{api.gateway.custom.domain.url}}/this-works/foobar - works
does anyone know why (2) gives 404? api-gateway REST API with mapping works while api-gateway HTTP API will return 404 with 0kb body. Is there something I am missing?
note: the (none) path mapping has been added for a sanity check, and I was able to get the expected response.
I had the same problem.
The problem is in the configuration of routers of your application.
When you configure one API mapping in AWS API Gateway, the configured path (this-no-work) is passed to your web application as a prefix of routes.
SO ... if you have one route like this:
/api/foobar
you need configure one more route with the prefix point to the same action:
/this-no-work/api/foobar
A good one is to make one global configuration to your web app.
You can note it enabling the cloudwatch logs of your API Gateway stage and looking into the cloudwatch logs the path property passed from API Gateway to the Web application.
Thanks to answer from #gean-ribeiro, I was able to figure why my HTTP API was returning 404 Not Found.
Turns out it was not an issue with HTTP API. The error 404 Not Found with 0kb body was coming from the API integration sitting behind APIG. Specifically, it was a load balancer using rules based on HTTP path pattern.
By default, any unmatched path pattern will return 404 with text/plain body. this-no-work was a new HTTP API I added, and it did not have the necessary listener rules.
Once I added a new listener rule for HTTP Path pattern is /this-no-work/*, it worked as expected..
when default endpoin is created in my case it uses this pattern
https://{api_id}.execute-api.{region}.amazonaws.com/
an answer might be: Disable the default endpoint for an HTTP API
more details here
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-disable-default-endpoint.html
I'm almost complete with a new web app, however, I'm getting a 403 error from AWS's API Gateway due to a CORs issue.
I'm creating a Vue app and using Vue's axios library. CORs is enabled and the request works with API Key Required option turned off in AWS's API Gateway by sending the following:
axios
.get('My-URL-Endpoint',{headers: {})
.then(response => (this.passports = response.data ));
When I turn on API Key Required functionality inside AWS's API Gateway. It works when I use Postman along with including x-api-key: My-API-Key. However, using Vue's axios it does not work and returns error 403:
axios
.get('My-URL-Endpoint', {headers: {
'x-api-key': 'My-API-Key'
}})
.then(response => (this.passports = response.data ));
My first instinct is that the problem is related to how Axios is sending the request through the browser. From what I can gather it looks like the pre-flight check is failing because I am receiving the following error within the browser:
Access to XMLHttpRequest at 'My-URL' from origin 'http://localhost:8080' 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.
Sure enough it looks like there is no access-control-allow-origin key in the response. So I added access-control-allow-origin to the response of the 403 message and got a new error "It does not have HTTP ok status"
I've been trying nearly everything to get this to work! I came across stackoverflow answer where it seems like the person was suggesting that API Key Required Key functionality can't work with CORs. This kind of seemed like that cannot be true. It would be a pretty crippling restriction.
So my question is how to get the browser's pre-flight check to work along with CORs and API Key capability inside AWS's API Gateway?
Thank you!
If you have enabled cors on your api gateway, the next place to look is the application code such as lambda. Make sure the Lambda is returning the correct cross origin headers in both successful and failure scenarios.
First of all you can check if the request is reaching the lambda from the cloud watch logs. Another way to check this is to temporarily point the Api gateway target to the Mock end point.
If the mock endpoint works, then the problem is the application code. otherwise the problem is in your api gateway end point.
Also note that any headers you use should be white listed in the Access-Control-Allow-headers section when you enable to cors for your method/resource.
In my use case, API Gateway serves as an HTTP proxy, using default settings following official tutorial.
It's tested working in test console or via curl. But if I access the link in browser or make an AJAX call, I'll get ERR_CONTENT_DECODING_FAILED.
It seems that API Gateway corrupt the content. Related issue.
Is there a way to forbid API Gateway changing my content? I set Content Handling to passthrough, but clearly it's changing my content.
Add a static integration request header Accept-Encoding with value 'identity', so that AWS won't tamper your request.
I want to set a 404 response code in API Gateway based on error message from Lambda function, here's integration response mapping:
And here's testing output:
The issue is that when making request in browser, I still don't get 404 status code, but rather the default one. What could the issue be here?
On your method execution configuration, you need to set 404 as a status both on your Method Response and both at your Integration response.
First you set it on your Method Response configuration and the you proceed in configuring the Integration response for 404.
When invoking the deployed API's URL from the browser, the behavior should be the same as invoking from API Gateway console (as shown in above screenshot). Please make sure you have deployed to the stage that you are invoking, after you made all the configuration changes to the API.