Harden Astro.clientAddress when using from Node adapter

[matthewp]

Changes

• X-Forwarded-For is now gated by security.allowedDomains, consistent with how X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Port are already handled.

Testing

Added and updated unit tests in packages/astro/test/units/app/node.test.js

Docs

N/A, bug fix

[changeset-bot]

🦋 Changeset detected

Latest commit: 8e01ece

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

Merging this PR will not alter performance

✅ 18 untouched benchmarks

---

_{Comparing node-ip-addr (8e01ece) with main (918d394)¹}

Footnotes

1. No successful run was found on main (20b05c0) during the generation of this report, so 918d394 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[ematipico]

There are some tests that need updating.

Also a bit concerned... isn't this, technically, a breaking change? But I don't have strong feelings. However, maybe we should update the docs https://docs.astro.build/en/reference/adapter-reference/#clientaddress

We should mention that clientAddress values must match values inside allowedDomains

[matthewp]

@ematipico Yes breaking, but in line with the other enforcements over X-Forwarded- headers, this was just one that was missing. This is enforced for X-Forwarded-Host and X-Forwarded-Port. If you have X-Forwarded-For then you have those headers too (behind a proxy) and are already using allowedDomain otherwise your Astro.url is missing the domain, so I don't think this realistically breaks for many people. And it's in a major anyways.