[mforce]

What

Gives the login rate-limit counter a bucket the probe can measure without the suite's own traffic in it. Follow-up to #866, which proved the collision but did not remove it from the way.

IsolatedLoginBucket makes loopback a trusted proxy for one test host, so ForwardedHeadersMiddleware honours X-Forwarded-For and the limiter keys on an address the test names instead of on the socket peer.

Two findings from building it

A first cut minted buckets as 198.51.100.<a>.<b>. Five octets is not a valid IPv4 literal. ForwardedHeadersMiddleware rejects it and falls back to the socket peer, so every "independent" bucket silently collapsed onto loopback — where the test's own exhaustion turned the next client's first request into a 429. It looked like isolation not working, not like a malformed address. Buckets are TEST-NET-3 /32s now, and the helper says why that matters.

The probe's own fixture spends against the probe's own bucket. The burst moved the counter by 18 on 14 requests, in a Redis container private to that class — nothing external could have written it. CluckworkWebApplicationFactory builds its host in the constructor, before any test body runs, and the suite logs in constantly from loopback. So #840's collision reproduces one level down, inside a single class. That is why the assertion is >= and not ==: an exact assertion here would have made the file red on a working mechanism.

Why configuration and not PostConfigure<ForwardedHeadersOptions>

Program.cs:63 reads RateLimiting:TrustedProxies eagerly into a registration record and hands that snapshot to AddCluckworkEdgeSecurity, which clears KnownIPNetworks and rebuilds them from it. A PostConfigure runs afterwards and is silently overwritten — a helper written that way looks correct and does nothing at runtime.

Guard

A host that already sets RateLimiting:TrustedProxies:0 is refused, not merged. Such a host is exercising #143's anti-spoof boundary; overwriting its proxy list would delete the thing under test while leaving the test green.

Verification

Executed, 32/32 across every class that touches the login limiter or the forwarded-header trust decision:

• RateLimitingTests, AuthRateLimitLoggingTests, DistributedRateLimiterWiringTests, MultiInstanceRateLimitTests, LoginCounterKeyProbeTests, SchemaDocsTests — 20
• ForwardedHeaderTrustKestrelTests, SecurityHeadersTests, KestrelRequestBodyLimitTests — 12

The second group matters most: those are the anti-spoof tests, and they still pass because they configure their own proxies and therefore never enter this helper.

Not in this PR

The collision is still there for the ~102 classes that log in through the shared factory. This isolates the probe. Extending it to the suite is the next step and should be its own PR, because it means every factory opting in and each one is a place to get the trust decision wrong.

Does not close #840. No flake has been shown to stop flaking yet — that needs repetition, not reasoning.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: f9effc10-6988-4b7d-8dbc-2a389f4fdb2f

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}