mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 06:16:20 -06:00
4b13dadb4d
getClientIp() decides the value every per-IP control keys on — the auth/pairing rate limiters, lib/pair-lockout, and activity_log.ip_address — so a caller must never be able to choose it. It believed CF-Connecting-IP whenever the immediate peer was in the `trust proxy` list, which includes loopback/linklocal/uniquelocal. Those entries are correct for X-Forwarded-For: a proxy APPENDS to that header and Express walks the chain right-to-left, so a client-supplied value cannot become the resolved address. CF-Connecting-IP has no chain — a local reverse proxy passes through whatever single value the client sent — so treating a loopback peer as evidence the request came through Cloudflare means trusting the client. Gate it on the published Cloudflare ranges alone. This is also the portable behaviour: most self-hosted installs are not behind Cloudflare, and for them the header is now simply ignored, with attribution falling back to req.ip under whatever `trust proxy` the operator configured. Installs that do front with Cloudflare are unaffected — their peer really is a CF edge. Documented the distinction at config/cloudflareIps.js so the two lists are not conflated again. No response shape or DB change; no client impact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| activationNudge.js | ||
| activity.js | ||
| agency-digest.js | ||
| alerts.js | ||
| content-expiry.js | ||
| email.js | ||
| heartbeat.js | ||
| loop-lag.js | ||
| scheduler.js | ||
| signupEmails.js | ||