v7.8.2

Route-relative path resolution under root_path and mounts, Starlette and FastAPI floors (v7.8.2)

• Fixed - StarletteGuardRequest.url_path and the WebSocket adapter's _WebSocketGuardRequest.url_path returned request.url.path / websocket.url.path, which under an ASGI root_path (uvicorn --root-path, or a mounted sub-app) includes the mount prefix. guard-core matches that value against SecurityConfig.exclude_paths and endpoint_rate_limits (an exact dict-key match) and passes it to custom_request_check hooks, so a key such as /api/vault/login never matched a request actually served at /mounted/api/vault/login and every path-keyed control silently stopped applying under a mount. Both adapters now return Starlette's own get_route_path(scope), the same route-relative path Starlette's router already matches routes against.
• Compatibility - If exclude_paths or endpoint_rate_limits keys currently include your root_path mount prefix (a workaround for the bug above), remove the prefix after upgrading: those keys now match the route-relative path and a prefixed key silently stops matching. The same applies to custom_request_check hooks that branch on url_path.
• Compatibility - starlette>=0.35.0 and fastapi>=0.109.0 are now declared floors (no ceilings). Route-relative path resolution uses starlette.routing.get_route_path, which Starlette added in 0.35.0; 0.109.0 is the first FastAPI release that requires that Starlette. Older pairs fail at import guard with an ImportError.
• Changed - Detection input and the reason text of the Suspicious activity detected log line now use the route-relative path, while the GET <url> part of the same line still shows the full URL including the mount prefix (url_full is unchanged), so the two differ under a mount by design.

---

What's Changed

• release(v7.8.2): route-relative path resolution and dependency floors by @rennf93 in #123

Full Changelog: 7.8.1...7.8.2