Repository navigation
Conversation
trusted_proxy previously accepted exactly one address, which does not work when the proxy's address is not constant (e.g. traefik pods in Kubernetes). The adjustment now normalizes to a list of entries (single string, whitespace/comma separated string, or iterable), and the proxy-header middleware trusts a peer when any entry is "*", matches the peer exactly, or is an IP network (CIDR range or single IP) containing the peer's address. Single-address configurations behave as before.
Author
|
Hi @kgaughan, could you take a look at this when you have a chance? Happy to make changes if anything needs work. Thanks! |
Author
|
closing this one, no traction. thanks anyway |
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
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 #478
Problem
trusted_proxyaccepts exactly one address. When waitress runs behind a proxy whose address is not constant — the reporter runs traefik in K3s, where pod IPs change — a single trusted address is not enough, so proxy headers from legitimate proxies get cleared/ignored.Change
adjustments.pyas_trusted_proxiescaster normalizes thetrusted_proxyadjustment to a list of entries. Accepted inputs: a single string ("192.168.1.1","10.0.0.0/8","*"), a string with multiple entries separated by whitespace and/or commas (the form usable from the CLI / config files), or an iterable of strings. Empty input still meansNone(no trusted proxy), and the existingtrusted_proxy_count/trusted_proxy_headersvalidation is unchanged.Adjustments.trusted_proxyis now a list of entries (orNone) instead of a string; the one test asserting the attribute's value was updated accordingly.waitress.serve(..., trusted_proxy="192.168.1.1")and--trusted-proxy=192.168.1.1behave exactly as before.proxy_headers.py_is_trusted_proxy()matcher used byproxy_headers_middleware. A peer is trusted when any entry:"*"(existing behaviour, now also usable as one entry among several),ipaddress.ip_network(..., strict=False)— covering both CIDR ranges (10.0.0.0/8,2001:db8::/32) and single IPs — and contains the peer's IP address.proxy_headers_middlewareitself accepts a string or an iterable fortrusted_proxy, so standalone users of the middleware get the same behaviour.Tests
tests/test_proxy_headers.py: list matching (hit and miss), IPv4 CIDR in/out of range, IPv6 CIDR, mixed CIDR + exact entries,"*"inside a list, invalid entries ignored.tests/test_adjustments.py: normalization of single string, space-separated, comma-separated, list input,"*", and empty input.Disclosure: this change was prepared with AI assistance and verified by running the project's test suite locally.