Repository navigation
Use the visitor's address behind a trusted reverse proxy - #63
Merged
Merged
Conversation
Behind a reverse proxy or tunnel every request reached ConnectHub from the proxy's address, so all visitors shared one login rate limit (anyone's ten wrong passwords locked everyone out) and logs showed the proxy. With the proxy listed in the new TRUSTED_PROXIES setting, client_ip() takes the nearest X-Forwarded-For entry that isn't a trusted proxy. The forward-auth check keeps using the connecting peer. Fixes #55 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #55
What changed
TRUSTED_PROXIESsetting (IPs/CIDRs, empty by default = unchanged behaviour).client_ip(): when the peer nginx saw (X-Real-IP) is a trusted proxy, the visitor is the nearestX-Forwarded-Forentry, read from the right, that isn't a trusted proxy. A visitor's forged entries sit to the left of what the proxy appends, so they're ignored. Used by the login/sign-up/password rate limiter and log messages.peer_ip()(the old behaviour) is what the forward-auth check uses, soTRUSTED_PROXIEScan never let a forwarded address pass as the forward-auth proxy.docker-compose.ymldocument the setting.Testing
pytest: 255 passed, 8 skipped. New tests: no trusted proxy → peer; behind a trusted tunnel → visitor, both with nginx's appended entry and asauth_requestpasses the header unchanged; a forged left-hand entry is ignored; a direct visitor can't claim another address; a chain of trusted proxies is skipped; a trusted proxy that forwards nothing → the proxy; forward auth rejects a request whose forwarded address, but not peer, is the forward-auth proxy.172.21.0.4, and cloudflared'sX-Forwarded-Forcarries the visitor (uvicorn's own access log shows it for/auth/verify).🤖 Generated with Claude Code