Repository navigation
feat: count shadow-mode denies as a synthetic "403*" status class - #3
Merged
Merged
Conversation
Shadow mode already exposes the scopes that *would* have been denied through the `X-Api-Would-Deny` header. This adds an opt-in counter so the statistics answer "who is already hitting the endpoints we are about to protect?". * `buffers.record_hit()` accepts an explicit `as_class`, so a synthetic status class can be recorded without faking an HTTP status code. * New `API_USAGE["TRACK_WOULD_DENY"]` setting (default `False`, opt-in). * `WOULD_DENY_STATUS_CLASS = "403*"`: the middleware writes one extra `EndpointStat` row per endpoint/day/client when a request carried pending would-deny scopes, which fits the existing `status_class` column and shows up in the admin and the reports without further changes. Tests cover both the default (nothing extra is counted) and the enabled path (the `403*` row is written next to the real `2xx` one).
Merged
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.
Why
Shadow mode already tells us which scopes a request would have been denied
(
X-Api-Would-Denyheader), but the statistics only counted the real response(
2xx). When we start protecting endpoints one by one we want to know who isalready hitting them before flipping enforcement on.
What
buffers.record_hit()accepts an explicitas_class, so a synthetic statusclass can be recorded without faking an HTTP status code.
API_USAGE["TRACK_WOULD_DENY"]setting (defaultFalse, opt-in).WOULD_DENY_STATUS_CLASS = "403*": when a request carries pending would-denyscopes, the middleware writes one extra
EndpointStatrow for the sameendpoint/day/client dimensions.
The synthetic class fits the existing
status_classcolumn (max_length=4), sothe admin, the filters and the reports show it without further changes:
Compatibility
Opt-in: with
TRACK_WOULD_DENYunset (the default) the recorded statistics arebyte-for-byte the same as before.
Tests
test_shadow_denies_are_not_counted_by_defaulttest_shadow_denies_are_counted_when_enabled(asserts the403*row and thatthe real
2xxrow is still written)pytest: 87 passed ·black --check✅ ·ruff check✅