Skip to content

v.7.5.0

Choose a tag to compare

@rennf93 rennf93 released this 09 Aug 14:35
· 2 commits to master since this release
e206ac6

Pipeline composition support and quality-gate repairs (v7.5.0)

  • Added - Route configuration is visible when the pipeline is built. guard-core 3.10.0 derives the security pipeline from the effective configuration, skipping checks that configuration can never trigger. Six of those checks are driven purely by per-route decorators, and guard-core can only skip them when it can enumerate the registered route configuration. SecurityMiddleware now adopts app.state.guard_decorator before initialize() builds the pipeline, so an application that registers its decorator handler that way gets the smaller pipeline instead of the conservative full one. Applications that call set_decorator_handler were already covered. When no decorator handler can be found the route configuration is treated as unknown and every route-driven check is kept, so this path can only lose the optimization, never the protection. The pipeline log line now reports how many checks were skipped alongside the ones that ran.
  • Fixed - Requests carrying a non-mapping ASGI scope no longer corrupt pipeline construction. The decorator adoption guards every attribute access and verifies the scope is a mapping, so a request-like object without a real scope leaves the decorator handler unset rather than propagating a bogus value into pipeline construction.
  • Internal - The dead-code gate was doing nothing. Both vulture invocations in the vulture Makefile target were commented out, so make quality reported success without scanning anything. The target now runs, and the one real finding it surfaced is fixed.
  • Internal - A warning filter was masking 30 live deprecation warnings. pyproject.toml carried a filterwarnings entry suppressing guard-core's ipinfo_token is deprecated warning, which 24 call sites in the middleware tests were triggering. The entry is removed and the call sites no longer pass the deprecated field. The suite runs warning-free with no filters configured at all.
  • Internal - Test suite warning cleanup. Fixtures that wired a geo_ip_handler without any country rule tripped guard-core's validator warning on every use; the dead wiring is removed. The example application's seven Pydantic models migrated from class-based Config to model_config = ConfigDict(...). httpx2 is added to the dev dependencies, which is what starlette's test client now expects.
  • Internal - test_rate_limiting_with_redis was failing about half the time. Each request stalled roughly 3.3 seconds on a live geo-IP lookup that could not initialize, and three such requests took about as long as the test's own 10 second rate-limit window, so whether the third request still fell inside the window was decided by network latency. The test no longer exercises the geo path it never asserted on, and now runs in well under a second.
  • Internal - guard/middleware.py maintainability. The decorator adoption lives in guard/_decorator_adoption.py so the middleware module stays at rank A against the declared mi_min = "A".
  • Compatibility (shared-state registry key) - guard._middleware_state.get_state and register_state gained a decorator parameter, and the registry key changed from id(config) to (id(config), id(guard_decorator)). The module is underscore-private, so this is not public API, but anything reaching into it directly still breaks. The key changed because two SecurityMiddleware instances can share one SecurityConfig while decorating different routes now that the pipeline is derived from route configuration; keying on id(config) alone would let the second app adopt the first app's already-eliminated pipeline by reference and silently skip checks its own routes need.
  • Compatibility (guard-core dependency) - guard-core stays an unconstrained dependency in pyproject.toml per this project's policy. Installed against guard-core 3.9.0, this release's adapter code only calls build_default_pipeline() and reads the guard_decorator attribute, both of which already existed there, so it degrades to the previous conservative full-pipeline behavior rather than crashing. The test suite does require guard-core 3.10.0, since tests/test_middleware/test_pipeline_composition.py asserts the smaller, decorator-driven pipeline by check name, so guard-core 3.10.0 must be published before this suite runs in CI; this is a CI ordering constraint, not a runtime crash risk for installed applications.
  • Compatibility (dev dependencies) - httpx2 is added to [project.optional-dependencies].dev, which is what starlette's TestClient now expects.

What's Changed

  • Adapter support for guard-core 3.10.0's config-derived pipeline, and a shared-state pipeline-sharing fix by @rennf93 in #114

Full Changelog: 7.4.1...7.5.0