Open MikeTheCanuck opened 6 years ago
If we believe the reddit thread that AWS has patently refused to implement the most common layer-7 redirect behaviour, that everyone in the world needs, in their layer-4 load balancer, then we're left to find the lightest-weight, lowest overhead web server configuration to manage this.
Here's one option which is attractive because it handles multiple domains and routes with a single web server. This would demand that we:
While I'm sure there's a way to walk that intricate tightrope, boy howdy does that sound painfully brittle.
Good news: ELB now supports redirects in ALB
Bad news: this is supported through direct manipulation, but CloudFormation hasn't implemented support for this new functionality.
So let's wait a couple of months before we can turn off the HTTP listeners.
Any chance the "swagger" api pages (like this one) could be changed to use https
for the underlying AJAX call?
Update: as of today AWS appears to provide the missing support in CloudFormation: https://forums.aws.amazon.com/thread.jspa?threadID=286855&tstart=0&messageID=878304#878304
And apparently this is a working example (haven’t read it, just filing away for later):
Quick question about this. I notice that we have http and https versions of the site, but the https isn't the default. Is that in any way related to this issue and it's still blocked, or should I open a new issue to get https as default?
Thanks
Thanks for resurrecting this redirect idea @fstorr! I recall a recent problem folks were having with one but not the other of HTTP and HTTPS versions of the APIs: https://civicsoftware.slack.com/archives/CFTR2UVAP/p1567404250022600
Which leads to a couple of issues we have with our APIs: https://github.com/hackoregon/civic-devops/issues/210 - which hasn't been closed yet
https://github.com/hackoregon/2019-transportation-systems-backend/issues/63 - which apparently was implemented in the 2019 Transportation API but doesn't appear to have been resolved in the 2018/19 Disaster API yet (might just need a rebuild with the latest 2019-backend-docker build).
Goals
Need for redirect
There are many industry-wide efforts to drive as much of the world's traffic to HTTPS (TLS-encrypted) channels and minimize the amount of traffic over HTTP (non-encrypted). Google will be marking all HTTP pages "insecure" as of this year.
It would be preferable (especially as it's free, in an AWS world) to leverage HTTPS listeners - no questions there.
Given that all of Hack Oregon's infrastructure to date has been built on HTTP listeners (front end and APIs), there is a lot of legacy code that is hard-coded to send requests over HTTP.
So we will need to allow for incoming HTTP requests and redirect those requests to our HTTPS listeners.
Preserve routes and params
Further, I have noticed in many implementations of redirects that routes and query parameters can get dropped in the redirect, breaking the underlying application behaviour:
Minimize extra infrastructure
Ideally it would be less overhead, and fewer points of failure, if the redirects were performed at the ALB layer (or some other "hands-free" AWS piece). However, most documents and articles I'm finding in my research focus on implementing the redirecting listener as a web server module that you own yourself. Having to account for, configure, manage and support another dozen web servers just for the purpose of sending traffic from HTTP to HTTPS seems like an awful burden, and given how common this need is, I can't accept that Amazon hasn't found a way to relieve this burden themselves.