CDCgov
Broken links in the tos.md page (static site)
Description
There are two broken links on the static site that have been identified by our link checker here.
Expected behavior
The two links in question are currently returning 403s, when we expect 200s.
The links both seem to work in a browser, I'm curious why we're getting permissions issues https://www.hhs.gov/foia/privacy/index.html https://www.hhs.gov/vulnerability-disclosure-policy/index.html
In addition to direct browsing to the links, I'm able to click the links on the static site itself. It appears to just be an issue from the github actions.
Followed up with Rin on this:
Both of these sites go to HHS, not CDC. The DNS entry for this points to an ec2 instance floating around somewhere in AWS, with a default Apache page. I have heard of instances where GitHub Actions runners are blocked, since they can be used to launch attacks. I want to say we have run into something like this previously with SimpleReport's WAF. Ultimately, everything is configured correctly on our end. This would be outside the CDC's hands. The only two workarounds that I can think of are:
- Use a self-hosted runner for this. CDC provides a few in their CDCEnt organization, but they haven't made them accessible in CDCGov. Unfortunately, unless we want to pay a few hundred per month in hosting costs, this will be a no-go for us.
- Use a lycheeignore file, or pass in domains to ignore using the --exclude switch from within the action's args: input. We can exclude the problematic HHS domains here, but we will have no way to know if they end up broken. Ultimately, though, that's beyond our control.
- Bonus option: expect a 403 code. Concern with this approach is if the code we're getting is at the gateway level vs the page level. Link could go back and everything would still be green.
There were 4 total failing links. Two of these links come from HHS and were simply added to the lycheeignore file since they work in a browser. A third link has a new embedded YouTube URL that @emyl3 provided which passes the linkChecker and successfully appears on both the demo site and production. A fourth link was on the "staying-connected" page, which turned out to be a page we could remove altogether along with the failing link within it. The staying-connected page has been removed from the codebase but still exists as a file that we've uploaded as part of our deploy process that hasn't been deleted. Full removal of the "staying-connected" page will be addressed in a new story and/or possibly be done manually by someone who has access to do so.
Marking this story as completed.
