I’m using AWS API Gateway at https://console.aws.amazon.com/apigateway/home
I did all of the steps to set up a proxy for http://foo.com (example)
I deployed it and the URL is http://bar.com (example)
When I go to http://bar.com/hello, it redirects me to http://foo.com/hello
I want it to stay at http://bar.com/hello, but deliver the contents from http://foo.com/hello like a normal proxy service
Note: My primary intent is to get around CORS issues with a service
It seems to me that whatever service you're using is forcing the redirect like #Steve's comment mentioned. They might be forcing HTTP_REFERER to be a certain domain.
Since I don't know what service you're calling this is just a guess.
Related
I have a custom domain example.com that is redirecting to my API gateway api-example.com, but it doesn't seem to pass the user-agent field, all my user-agent values are AmazonAPIGateway_5rfp2g9h9b.
If I call directly the api-example.com then it works fine, but if I call example.com, doesn't work.
Any idea on how I could pass the correct user-agent HTTP Header?
Thanks
It’s not clear what you mean by redirect or the domains you have listed, so you have two custom domains ? And if so how did you do that, Cloudfront with a custom origin? And what type of integration request do you have? Is this a REST or HTTP API? Probably why you are getting down voted because you don’t have any detail and the domains don’t make sense.
Either way in your API make sure you have the user-angent field defined where it is applicable:
Request Part of your API, and make sure your integration request is forwarding this header
Likewise make sure Cloudfront forwards the ‘user-agent’ header, that it is also whitelisted if you are using Cloudfront
Note this header comes from your Web browser or SDK being used sometimes sets this too. So if you don’t set this header for whatever reason that could be a problem, I don’t know if for example when you say from this domain that means you are using a hosted website, and another means making a request from Postman, etc.
Short answer: Validate the contents of your header
Ref AWS user-agent redirect here.. as listed below.
Redirects and HTTP user-agents:
..Programs that use the Amazon S3 REST API should handle redirects either at the application layer or the HTTP layer. Many HTTP client libraries and user agents can be configured to correctly handle redirects automatically; however, many others have incorrect or incomplete redirect implementations.
Before you rely on a library to fulfill the redirect requirement, test the following cases:
Verify all HTTP request headers are correctly included in the redirected request (the second request after receiving a redirect) including HTTP standards such as Authorization and Date.
Verify non-GET redirects, such as PUT and DELETE, work correctly.
Verify large PUT requests follow redirects correctly.
Verify PUT requests follow redirects correctly if the 100-continue response takes a long time to arrive.
HTTP user-agents that strictly conform to RFC 2616 might require explicit confirmation before following a redirect when the HTTP request method is not GET or HEAD. It is generally safe to follow redirects generated by Amazon S3 automatically, as the system will issue redirects only to hosts within the amazonaws.com domain and the effect of the redirected request will be the same as that of the original request...
Optional/Additional help, I was trying to understand your description, if you're going across domains, thats CORS.
Please consider CORS which you seem to be missing, please see configuration
here.
Also very important you Enabling CORS support for a resource and its methods does not recursively enable it for child resources and their methods.
If you want to setup your custom header for
user-agent
Setup CORS in Console
How to setup from console under the resources enable the CORS.
Setup your Headers
As a last step you have to REdeploy to a stage, for the settings to take effect!
I'm developing an Angular Universal serverless app in AWS Lambda/Api gateway. The app works perfectly using the standard api url ( {api-id}.execute-api.{region}.amazonaws.com/{stage}/) but now I'm trying to deploy it in a human-readable url using Api Gateway's Custom domain names.
For that I followed the docs and troubleshooted using other stackoverflow's questions, but now I'm faced with a problem and can't find another question that looks like my problem.
I have already setup the API, the custom domain name (which created a cloudfront distribution) and a Route53 A-type ALIAS routing to this new cloudfront distribution and the routing kind of works.
The problem I'm facing is that when I'm using the new domain name, the angular app cant find assets like CSS, Icons,etc. All of them works fine using the standard api url but not with the custom.
To do some debugging I configured Api Gateway to log requests to CloudWatch, and I can see that when I'm using the standard url, the resource path log is like this:
HTTP Method: GET, Resource Path: /main.4d57a71fd195330e8ee9.js
But when I use the custom URL the same log is like this:
HTTP Method: GET, Resource Path: /development/main.4d57a71fd195330e8ee9.js
I'm guessing it has something to do with the base URL in the custom domain name configuration of Api Gateway, I tried changing it to everything I could think of but nothing fixed it.
Here is a screenshot of my Api Gateway configuration.
Api gateway - Custom Domain Names configuration
Tell me if you need anything more and sorry if bad english.
Thanks in advance.
EDIT: I should make clear that I'm trying to point to the "development" stage of my api
I believe you simply need to reconfigure your custom domain. It should be sufficient for you to change the following;
In "Base Path Mappings" section change Path from "/development" to just "/"
I had similar problem. The only workaround for me is to set baseHref to "/" in environment.serverless.ts and have one single mapping in custom domain name from "/" to "{YOUR-API}:production".
This breaks direct url access to the API but access via custom domain name works fine.
So I have this problem and I am a bit confused on where to start. I have a Django REST API currently running on a VPS (with apache) and start with djangos runserver command (I know, I know, not the best way) so it is currently accessed via http://example.com:8000/api.
I am now moving to AWS and using Elastic Beanstalk to run my newly created Django REST API. I want to keep the domain something like example.com/api or api.example.com. Now this should be fine for me to set up but the problem I now have is I want to forward all old requests using the old API to the new API. What is the best way to do this?
Any help will be appreciated! :)
There are two ways to do this.
Rewrite
Redirect
Rewrite:
With rewrite you read the contents using the old api and serve on the same request.
Redirect:
With redirect you send a 302 with the redirect location to your new API url.
Any request to http://example.com:8000/api/something will be responded with a http status code 302 and location as http://example.com/api/something or http://api.example.com/something
If you do not wish you to use the old API, then it is better to redirect to the new destination.
If changing the URL on the client side is possible, then you can abondon mantaining the old endpoint or any of these process.
Hope it helps.
I am aware that many similar questions have been posted and answered here but none of them is quite the same with what I am experiencing.
I have a Lambda function that handles incoming requests (GET and POST). I also set up an api gateway as public facing endpoint. Additionally, I set up custom domain following Set up Custom Domain Name for API Host Name
The testing call works in both of lambda and api gateway console. Everything also works using the invoke URL but not with the custom domain I've set up.
Here are some more details:
Invoke URL (Works) :
https://{api gateway id}.execute-api.us-west-2.amazonaws.com/prod/endpoint
Custom domain endpint (Doesn't work):
https://api.{my domain}.com/endpoint
Base Path Mapping:
/endpoint endpoint:prod
All Method Auth:
Authorization None
API Key Not required
Route53:
A record as alias that points api.{my domain}.com to the cloudfront distribution domain name as alias target.
I'd really appreciate if anyone knows what's going out here.
I had met the same question several years ago and solved it by removing the 'stage' name from the URL.
the URL of gateway API seems like the following:
https://{id}.execute-api.{region}.amazonaws.com/{stage}/todos
if you have routed a custom domain https://api.xxx.com to gateway API {apiName}:{stage}, it seems like the following:
https://api.xxx.com
path: /
target: {apiName}:{stage}
Finally, the correct way to call it is to remove the stage name:
// **remove stage name!!!!**
// Right
https://api.xxx.com/todos
// Wrong
https://api.xxx.com/{stage}/todos
I found the issue is misunderstanding of how base path mapping works.
All my configurations are correct.
My API resource is not under / but under /endpoint
To use the custom domain, instead of visiting https://api.{my domain}.com/endpoint, it needs to go to https://api.{my domain}.com/endpoint/endpoint
Of course this is silly and redundant.
I have two options. I either set up the base path mapping to / instead of /endpoint or I can just user the API resource / instead of /endpoint.
I go with the latter because if base path mapping is set to /, my api.{my domain}.com will only be able to host just one API (I can still use resources under the same API, but why wasting the extra layer of abstraction?).
This seems dump but I am still glad I figured it out.
Another reason for this can be that your user, although admin, does not have a bloody CloudFrontFullAccess permissions! I just spent a couple of hours on it as I relied on serverless to do it for me and it worked perfectly on another project with different credentials, though. So double check the article! https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html
Step 1: Map the A record from subdomain.yourdomain.com to API Custom domain/API Gateway domain name(API Gateway -> Custom domain names -> tab Configuration/Endpoint Configuration).
Step 2: From API Gateway/ API Custom domain - add the api mapping. Leave "path" empty.
End point format:
Original endpoint: https://{api gateway id}.execute-api.us-west-2.amazonaws.com/prod/endpoint
Endpoint with API custom domain: https://api.yourdomain.com/**endpoint**
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.