Since last week I have been struggling to fix this problem but still its not resolved. I have deployed my Django code on AWS lambda and configure the API gateway to serve all api and admin section.
All http method are working fine from rest client/postman but when I am trying to integrating the api in AngularJS then try to perform the POST request to the api but Chrome sends a default OPTION request to the server but every time CloudFront returns an error with 500 status.
"Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource."
Please help me to resolve the issue as I need to move my product to production.
Thanks,
AbdulWahid
Thanks to Michael-sqlbot's comment, I finally succeed to get 200 response from AWS Lambda. Just enable CORS for your Method in API Gateway then it will work.
Related
I am using AWS Cloudfront to serve static html and images from a private s3 bucket. I need an authentication layer and have a requirement to use Microsoft SSO. To trigger the authentication check, I have a Lambda function connected to a Cloudfront Viewer Request.
From what I understand, I need to return the Request in a callback method when I want to get past the viewer request (after authentication). My issue is that the Microsoft SSO redirect's to the Cloudfront URL using an HTTP POST. If I return the request, Cloudfront attempts to POST to an S3 (or sends a MethodNotAllowed when I disable POST). I need this to be a GET request, but do not know how I can change it. According to the docs, the HTTP of the request object is read only.
I have tried redirecting to the Cloudfront URL when posting or serving a simple HTML that links to the html I want, but these both result in the Viewer Request being called again.
Has anyone handled a similar situation?
You should be able to return a redirect, but set the status code to 303 instead of one of the other 3xx codes. This is See Other which results in the browser following the redirect but using GET on the second request. There is no way to trick CloudFront into believing the method changed -- a redirect is required.
I'm trying to send a POST request to a REST service via AWS API Gateway.
The content-type of the request should be 'application/x-www-form-urlencoded'. It's an authentication service that I'm trying to access. I'm sending 'username' and 'password' in my request body.
When I send the the request via Postman, it works ( It's giving me the proper response ).
But I want to create an API from the API Gateway to access this endpoint.
When I create a POST method in the API Gateway and try to test it without specifying any content-type, the back-end server tells me to send the request by using the content-type 'application/x-www-form-urlencoded'.
Then when I try to put the content-type in 'Mapping Template' section in the 'Integration Request' of the API, the request doesn't even hit the backend. There's an error ( a JSON response ) comes when I test it, saying 'Unsupported Media Type'.
Does anyone out here knows any workaround for this?
I found the solution.
In order to access a POST service using the content-type ‘application/x-www-form-urlencoded’ in API Gateway, make sure you are doing the following in the API console.
Make sure you have enabled the ‘Use HTTP Proxy integration’ as the following in the ‘Integration Request’ section.
When you test the request, make sure you are putting the content type ‘application/x-www-form-urlencoded’ inside the Header’s box as in the following.
And the request body should be like the following as well.
username=user#wellcomww.com.au&password=123456
I am trying to call an API with axios from my ReactJS application (Mac). But I keep getting this error message,
Access to XMLHttpRequest at 'https://api_url/' from origin 'https://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.
I referred other stackoverflow answers but the error is still coming. I don't know where I made a mistake whether It is in AWS backend or Frontend. If anyone has an idea or solution please share.
Thanks in advance,
This is due to Cross Origin Resource Sharing (CORS) being disabled by default.
Your React app comes from a different domain (e.g https://localhost:3000) and therefore cannot call remote servers by default (e.g 'https://api_url/).
See Wikipedia and enable-cors for great explanations.
This must be enabled explicitly.
AWS API Gateway will let you do this from the UI.
Select your API in the UI
In the actions dropdown choose "Enable CORS"
Follow the forms to enable and you should be good to go!
Whenever I begin to use the AWS_IAM authorizer on my function, my API GET request - which is being made from a web client - receives a No 'Access-Control-Allow-Origin' header is present on the requested resource. and I'm getting a 403 status code. When I remove the aws_iam authorizer, the API request - made via the same web client - succeeds. So I'm pretty sure it's not actually a CORS error since I've double checked that my API has cors enabled. I'm not sure if I'm using the AWS Javascript SDK wrong or if I'm not generating proper roles for AWS_IAM in my serverless.yml config.
When I run the request from postman with my personal access keys from AWS, the request succeeds. When I console.log the keys from the AWS.config.credentials and use those in postman, the request receives an invalid token error message. Maybe I haven't generated the proper role for my federated identity pool?
I'm using aws4 on the front-end to sign the request, and I use axios to make the request.
Any ideas?
Axios will make a pre-flight request. It's an OPTIONS type and expects a 200 response before it will make the GET request. It also needs to return the CORS header:
Access-Control-Allow-Origin: *
Postman won't make the same call automatically but you can use it to test that request. Ensure that your API is accepting OPTIONS request methods for that route and that it returns an empty 200 response with the CORS header and I think you'll be good to go.
AFAIK, the OPTIONS request needn't be authenticated. Just give a green light. It may be the case that your client is making calls to this endpoint as OPTIONS requests that are being authenticated, adding a second layer of confusion, or you may need to add an Access-Control-Allow-Headers to allow an Authorisation type header if AWS is using one.
Hard to give more information without debugging but I would start with an OPTIONS request.
I am trying to Integrate SurveyMonkey with my backend.
This is the flow:
(1) We create a webhook(https://developer.surveymonkey.com/api/v3/#webhooks) using POST method from PHP, with Subscription url as an AWS API Gateway.
(2) When user completes a survey, SurveyMonkey invokes the subscription Url (API Gateway), which in turn calls a Lambda function to update the database.
The problem is when i try to give a API Gateway url as the subscription Url, SurveyMonkey returns a Bad Request response. If i use a general .php page, the webhook is getting created successfully.
In the conversation with SurveyMonkey Support Team, they say, the API Gateway should return a 200 response for HEAD request. I am not sure how to set this up in AWS.
Can anyone who has implemented / integrated, API Gateway with SurveyMonkey please guide me on how to solve this issue?
Here is the conversation with SurveyMonkey Support Team:
Thanks for getting back in touch. I just spoke with my colleagues on
the development team and they noted that there shouldn't be an issue
in using a lamda function for your subscription_URL. As long as it
accepts HEAD and POST requests and returns a 200. I hope this helps
you out; of course, please let me know if I can assist further.
Thanks for getting back in touch. I wanted to confirm that the lambda
function needs to return a 200 to a HEAD request in order for us to
enable the webhook properly. This isn't done after the webhook is
cerated, but as the webhook is created. It still seems like the
lambda function isn't responding, or responding correctly, as it is
created, so it will continue to fail. I hope this helps clarify;
please let me know if I can assist further.
One way or another, you need to get the API Gateway to respond to HEAD requests. There are a lot of ways to do this. You could add a HEAD method to the resource of your URL. You can do that in the API Gateway console under the resource section when you're editing you api. You can send the HEAD requests to a lambda function and have that function return a 200 status code for appropriate HEAD requests. You can set up a mock return in the api integration request, but you'll need to set up the correct integration details. You can also just set ANY lambda proxy integration and deal with everything on the lambda side.
Once you have something setup you should be able to test with curl:
curl -I http://yourUrl.example.com