API Gateway Proxy to VPC Link - aws-api-gateway

I am trying to use API Gateway to route traffic to an internal network load balancer.
All routes to the base path (/) are working, so I know the VPC Link is up and reachable.
I added a proxy resource (/{proxy+}), with ANY http method. In the ANY "Integration Request" I selected:
Integration Type: VPC Link
Use Proxy Integration
Method: ANY
VPC Link: My-VPC-link (abcdefg)
Endpoint URL: (i.e. http://abcd1234.cloudfront.net/{proxy})
I can see that the my web server responds with a redirect:
(b9d0c629-31ec-11e8-b452-0f13c3c62b81) Endpoint response body before
transformations: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: http://abcd1234.cloudfront.net/api/. If not click the link.
(b9d0c629-31ec-11e8-b452-0f13c3c62b81) Method completed with status: 301
The web page shows:
{"message":"Forbidden"}
Also, if I try to directly link to the CloudFront URL I get the same error.
In addition to the CloudFront URL, I've also tried the following:
Custom Domain Name
403 Forbidden
The URL of my deployed stage
{"message": "Internal server error"}
What URL should be in the 'Endpoint URL' field in the integration request?

It turns out that the API-Gateway must call the VPC Link with 'http' not 'https' for the VPC Link URL.

Everything seems to be in order in your configuration of API Gateway, including the endpoint URL.
My guess is that you are messing something with the redirections. Is it possible that your server is redirecting to the same place again and again, or that the redirection rules always apply?
To be sure that the problem is at your server's side, try a simpler set up. Try making an API call to somewhere that doesn't redirect, just return a simple response.

Related

Cloudfront and ALBs - Redirecting an HTTP request of a URL that is not on the SSL certificate. HTTP not HTTPS

I have a ALB set up behind a cloudfront distro. I have a rule to redirect an HTTP request to URL A to URL B which is not on AWS infrastructure.
When I query the ALB directly for URL A, the load balancer properly redirects to URL B. When I query a cloudfront endpoint for URL A, I get a 403 error back. Per the troubleshoot 403s aws doc, it seems the issue is that I don't have an alternate CNAME configured for URL B. However, since it's not on my SAN certificate that's associated with my CloudFront distro, I can't add it to the list of alternate CNAMES. is there a workaround to allow requests to URL A to properly travel through my cloudfront distro and get redirected? It doesn't make sense to me that I can't do this for an HTTP request.
verified that the ALB can be queried directly and redirect works
tried to add an alternate cname for http domain
removed wacl on alb to make sure that wasn't blocking it

Change location header in redirect responses from HTTP to HTTPS in Kong API Gateway

I have the following setup
User Request --> AWS ELB Application load balancer --> Kong Gateway --> Integration
The SSL termination happens at application load balancer.
One of my endpoint makes the Integration respond a redirect URL with a code 302. Ex. when I make a request to https://api.domain.my/a/b/c should make the integration return a redirect path /x/y/z
This redirect request with a status of 302 reaches the API gateway which should add a location header to the response with the complete URL i.e. https://api.domain.my/x/y/z
But the response I get in the header on my browser is http://api.domain.my/x/y/z in the location header. I am guessing this is happening because my SSL termination happens at the ELB and hence Kong is just returning http:// in the location header.
Is there a workaround for this? How can I use the response transformer maybe to achieve this?
Is there any better way to achieve this?

Static webpage redirect http to https using Google loadbalancer

I'm trying to implement URL redirects from http to https as described by [https://cloud.google.com/load-balancing/docs/https/setting-up-traffic-management][1] but I'm getting ERR_TOO_MANY_REDIRECTS
I have a storage bucket with a very simple HTML page.
I have an external HTTP load balancer in front of it. Static IP address. SSL cert. I managed to connect everything so that both http and https requests for the site load the contents of the bucket.
I tried to add the HTTP redirect as per the document:
Changes 'Host and path rules' from 'Simple' to 'Advanced...'.
The default route still points to the bucket
I added a new route. Host is 'www.example.com. The default path rule points to the bucket. The second path rule matches /* and does a prefix/HTTPS redirect as described in the above link.
Once the config is saved, either http or https requests to www.example.com results in ERR_TOO_MANY_REDIRECTS
What am I doing wrong? Really appreciate any help you can provide.
[Backend configuration][2]
[Frontend configuration][3]
[Host and path rules][4]
[Redirect path rule][5]
[1]: https://cloud.google.com/load-balancing/docs/https/setting-up-traffic-management
[2]: https://i.stack.imgur.com/lkhUF.png
[3]: https://i.stack.imgur.com/FYst0.png
[4]: https://i.stack.imgur.com/zsTOX.png
[5]: https://i.stack.imgur.com/2tEDE.png
FYI - someone in Google Groups pointed out that I needed 2 load balancers. 1 to terminate the HTTPS traffic and the second to redirect the HTTP traffic. Works like a charm.

Make 'http' request from Github-pages 'https' hosted site

I've hosted my webapp to Github pages, thus website is on 'https'. But now, I want it to make a 'Http' request to some external site.(I don't have a custom domain to change hosted site to http.)
I'm getting the 'Mixed-content' error -
Mixed Content: The page at 'https://username.github.io/MyHostedSite/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://someHttpApi'. This request has been blocked; the content must be served over HTTPS.
Is there a way to proxy this so I can do a 'http' request over 'https' ?
Get a custom domain, and do DNS with Cloudflare (free)
… you can turn https on at Cloudflare (in page rules) — then you don't have to worry about github's http/https settings and mixed content errors.
There are good instructions for setting up a custom domain with github pages, you can see it here: Custom domain for GitHub project pages
You just have to decide if you want to serve your site at the apex domain, or with the www subdomain:
http://example.com
vs
http://www.example.com
page rules at Cloudflare look like this:

AWS API Gateway - Test works, deployed API errors. Why?

I'm trying to setup AWS Api Gateway as a reverse proxy for my actual deployed API.
My understanding is that I do this by creating a "Proxy" Resource and then specifying my http endpoint URL - as described here
Create and Test an API with HTTP Proxy Integration through a Proxy Resource
This works fine when I try to use the API through the "Test" function within the Resource Editor. I can make calls to any exposed resources using GET methods and see the successful responses.
However, when I deploy the API Gateway API I can no longer access anything using the "Invoke URL" it gives me - I simply get:
{
"Message": "No HTTP resource was found that matches the request URI 'http://<myuniqueid>.execute-api.eu-west-1.amazonaws.com/api/Sector/100'.",
"MessageDetail": "No type was found that matches the controller named 'Sector'."
}
If I remove the "Use HTTP Proxy integration" checkbox from the "Integration Request" I can get it working, but why doesn't it work as a proxy?
I suspect that this is caused by a known issue with the HTTP proxy integration. When you use an HTTP proxy integration, API Gateway passes all headers through to the integration endpoint, including the HOST header. Many existing http endpoint require the use of a HOST header which matches their DNS name and in such cases, passing through the HOST header of the API Gateway can confuse the endpoint.
UPDATE: We identified a work-around for this issue.
In your integration request, explicitly add a header named "Host" and give it the value of the integration endpoint DNS name. This will replace the Host header forwarded from the incoming client request with the Host header you specify. This should allow your backend endpoint to function correctly.