-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use module to handle redirects for 18F Jobs #410
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like an easier solution to our current redirects workflow ... if this works ... we should follow up with a removal of the jobs/join.18f.gov redirects in pages-redirects
@afeld I know very little about Terraform, and am not a DNS expert, so bear with me if these thoughts are naive. It looks like this approach replaces using CNAMEs and explicit references to Cloudfront distributions with 301 redirects placed in S3 buckets. While I like not having to explicitly reference the distributions, it is clear exactly where things are pointing.
|
I disagree: There is no way to know from this repository where that CloudFront distribution lives. Is the record pointing to pages-redirect, or something else? They are disconnected. Here, at least, CloudFront references the S3 bucket in the same account, which is easier to retrieve.
I don't think so. The bucket names are all prefixed with Admittedly, it is moving the cruft from one AWS account (cloud.gov, via the service instances) to another, but at least it's easier to manage this way.
I don't think it makes it worse, and is better for SEO.
Given folks might be linking to the latter, we would have to do that anyway.
🤷♂Terraform is a third-party library. We can pin the module version if it would make us feel more comfortable. |
For a little more context: the need to set up redirects is going to come up more and more, especially with the Digital Council looking to shut down sites that aren't maintained.
Yeah, if we want to go all the way with this, we can remove a lot from pages-redirects, and possibly deprecate the whole thing. |
Thanks @afeld , sounds fine to me, especially as we'd probably prefer Tech Portfolio taking ownership of this anyways. Regarding the 3rd party library thing, i should have emphasized the word this. Terraform is a thing managed by a pretty well-known company with a ton of history. I can't speak for other folks, but I've never heard of mediapop so I'd be more cautious since this interacts with our infra. Since I'm not all that familiar with Terraform, I have no idea what a malicious user could do if configuration of their choosing is injected into our Terraform config, but at a minimum, they could redirect traffic :) Locking the version seems like the minimum here. We could even go old school and copy/paste the code into our repo. This amount of caution may seem strange from a Javascript dev (mostly these days), but the worst case scenario here seems bad. |
@afeld this seems OK to merge, yes? |
@afeld nudge |
That's fair. Not sure of the best way to do it. Asked the Terraform community. |
Locked the version until we figure out a better way. |
I've been thinking a bit about how to make setting up a redirect for a TTS site easier, and was wondering if there's an all-AWS way to do it. I found an example of the basics, and then found a module that takes care of everything, including multiple source domains and managing certificates.
Besides creating a CloudFront distribution being slow (not the module's fault), I tried it out from my machine, and it Just Works 🚀
Doing redirects in this way rather than using pages-redirects means that we don't:
I only converted the one to give a proof of concept, but it wouldn't be hard to do the rest. Let me know what you think!