From e998d90eed92023a290f851aa6d00242aff321a2 Mon Sep 17 00:00:00 2001 From: Renn F Date: Thu, 15 Oct 2026 12:54:29 +0200 Subject: [PATCH 1/2] release(5.0.0): required GUARD_SECURITY_CONFIG, engine routing parity --- .mike.yml | 3 ++- CHANGELOG.md | 30 ++++++++++++++++++++++++++++++ docs/index.md | 2 +- docs/release-notes.md | 30 ++++++++++++++++++++++++++++++ docs/versions/versions.json | 3 ++- pyproject.toml | 2 +- 6 files changed, 66 insertions(+), 4 deletions(-) diff --git a/.mike.yml b/.mike.yml index 2b5aac9..a3e4f2f 100644 --- a/.mike.yml +++ b/.mike.yml @@ -2,6 +2,7 @@ version_selector: true title_switch: true versions_file: docs/versions/versions.json versions: + - 5.0.0 - 4.3.3 - 4.3.2 - 4.3.1 @@ -18,4 +19,4 @@ versions: - 1.0.0 - latest aliases: - latest: 4.3.3 + latest: 5.0.0 diff --git a/CHANGELOG.md b/CHANGELOG.md index 0dcc97b..07e46c3 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,6 +3,36 @@ Changelog ___ +v5.0.0 (2026-10-15) +------------------- + +Engine routing parity with fastapi-guard, required GUARD_SECURITY_CONFIG (v5.0.0) +--------------------------------------------------------------------------------- + +### Breaking changes + +- **A missing `settings.GUARD_SECURITY_CONFIG` now raises `ImproperlyConfigured`** (#39, closes #38). `DjangoAPIGuard` used to fall back silently to `SecurityConfig()` defaults when the setting was absent or `None`, which ran the guard with a configuration you never chose. It now fails at startup with a message naming the setting. +- **Upgrade action** - Define `GUARD_SECURITY_CONFIG = SecurityConfig(...)` in your Django settings before upgrading. If you relied on the defaults, set `GUARD_SECURITY_CONFIG = SecurityConfig()` explicitly. + +### Fixed + +- **Global behavioral return rules now run.** `global_behavior_rules` are passed to the engine response pass at both response-pass call sites, as fastapi-guard does. + +### Documentation and tests + +- The README examples now build a real `SecurityConfig` instead of relying on the fallback, and the advanced example uses the engine request and response protocols and the `status:404` return pattern syntax. +- `tests/test_engine_parity.py` drives the middleware over Django's real URL resolution and views with the real engine bypass handler and response factory. The test that asserted the fallback now asserts the error. + +### Compatibility + +- The `guard-core` floor stays at `>=4.1.0`. The detection and dynamic rule fixes in guard-core 4.4.0 reach this adapter by upgrading guard-core (for example `pip install -U guard-core`), with no change to this package. + +### Chore + +- The sponsor button points at the maintainer's Sponsors page, the mkdocs `site_url` drops `/latest/` so canonical URLs resolve, the README markdown lint errors that blocked the docs deploy are fixed and the README was brought to content parity, a CODEOWNERS file was added, the family Discord relay workflow was added, and the `upload-sarif` action was bumped (#29, #30, #31, #32, #34, #36, #37). + +___ + v4.3.3 (2026-10-08) ------------------- diff --git a/docs/index.md b/docs/index.md index f2005e0..00c53fd 100644 --- a/docs/index.md +++ b/docs/index.md @@ -109,7 +109,7 @@ You can also download the example app as a Docker container from [GitHub Contain docker pull ghcr.io/guard-core/djapi-guard-example:latest # Or pull a specific version (matches library releases) -docker pull ghcr.io/guard-core/djapi-guard-example:v4.3.3 +docker pull ghcr.io/guard-core/djapi-guard-example:v5.0.0 ``` ___ diff --git a/docs/release-notes.md b/docs/release-notes.md index b946f43..7d3d3bf 100644 --- a/docs/release-notes.md +++ b/docs/release-notes.md @@ -3,6 +3,36 @@ Release Notes ___ +v5.0.0 (2026-10-15) +------------------- + +Engine routing parity with fastapi-guard, required GUARD_SECURITY_CONFIG (v5.0.0) +--------------------------------------------------------------------------------- + +### Breaking changes + +- **A missing `settings.GUARD_SECURITY_CONFIG` now raises `ImproperlyConfigured`** (#39, closes #38). `DjangoAPIGuard` used to fall back silently to `SecurityConfig()` defaults when the setting was absent or `None`, which ran the guard with a configuration you never chose. It now fails at startup with a message naming the setting. +- **Upgrade action** - Define `GUARD_SECURITY_CONFIG = SecurityConfig(...)` in your Django settings before upgrading. If you relied on the defaults, set `GUARD_SECURITY_CONFIG = SecurityConfig()` explicitly. + +### Fixed + +- **Global behavioral return rules now run.** `global_behavior_rules` are passed to the engine response pass at both response-pass call sites, as fastapi-guard does. + +### Documentation and tests + +- The README examples now build a real `SecurityConfig` instead of relying on the fallback, and the advanced example uses the engine request and response protocols and the `status:404` return pattern syntax. +- `tests/test_engine_parity.py` drives the middleware over Django's real URL resolution and views with the real engine bypass handler and response factory. The test that asserted the fallback now asserts the error. + +### Compatibility + +- The `guard-core` floor stays at `>=4.1.0`. The detection and dynamic rule fixes in guard-core 4.4.0 reach this adapter by upgrading guard-core (for example `pip install -U guard-core`), with no change to this package. + +### Chore + +- The sponsor button points at the maintainer's Sponsors page, the mkdocs `site_url` drops `/latest/` so canonical URLs resolve, the README markdown lint errors that blocked the docs deploy are fixed and the README was brought to content parity, a CODEOWNERS file was added, the family Discord relay workflow was added, and the `upload-sarif` action was bumped (#29, #30, #31, #32, #34, #36, #37). + +___ + v4.3.3 (2026-10-08) ------------------- diff --git a/docs/versions/versions.json b/docs/versions/versions.json index c061ed3..33ba354 100644 --- a/docs/versions/versions.json +++ b/docs/versions/versions.json @@ -1,4 +1,5 @@ { + "5.0.0": "5.0.0", "4.3.3": "4.3.3", "4.3.2": "4.3.2", "4.3.1": "4.3.1", @@ -14,5 +15,5 @@ "2.0.0": "2.0.0", "1.0.1": "1.0.1", "1.0.0": "1.0.0", - "latest": "4.3.3" + "latest": "5.0.0" } diff --git a/pyproject.toml b/pyproject.toml index 66ad763..819ed87 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "djapi-guard" -version = "4.3.3" +version = "5.0.0" description = "A security library for Django to control IPs, log requests, and detect penetration attempts." authors = [ {name = "Renzo Franceschini", email = "rennf93@guard-core.com"} From f228aae102e92d10f3cc6329a24065bf24aa3ade Mon Sep 17 00:00:00 2001 From: Renn F Date: Thu, 15 Oct 2026 14:32:22 +0200 Subject: [PATCH 2/2] build(deps): require guard-core>=4.4.0 guard-core 4.4.0 is on PyPI, so the floor moves up and upgrading this adapter brings the engine fixes. The release notes say so instead of asking users to upgrade guard-core separately. --- CHANGELOG.md | 2 +- docs/release-notes.md | 2 +- pyproject.toml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 07e46c3..54c3e27 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -25,7 +25,7 @@ Engine routing parity with fastapi-guard, required GUARD_SECURITY_CONFIG (v5.0.0 ### Compatibility -- The `guard-core` floor stays at `>=4.1.0`. The detection and dynamic rule fixes in guard-core 4.4.0 reach this adapter by upgrading guard-core (for example `pip install -U guard-core`), with no change to this package. +- The `guard-core` floor rises from `>=4.1.0` to `>=4.4.0`, so upgrading djapi-guard also brings the guard-core 4.4.0 detection and dynamic rule fixes (Cookie header scanned per pair, the per-request scan budget, the semantic-only header opt-out and dynamic rule versions applied over the base config). ### Chore diff --git a/docs/release-notes.md b/docs/release-notes.md index 7d3d3bf..8996f88 100644 --- a/docs/release-notes.md +++ b/docs/release-notes.md @@ -25,7 +25,7 @@ Engine routing parity with fastapi-guard, required GUARD_SECURITY_CONFIG (v5.0.0 ### Compatibility -- The `guard-core` floor stays at `>=4.1.0`. The detection and dynamic rule fixes in guard-core 4.4.0 reach this adapter by upgrading guard-core (for example `pip install -U guard-core`), with no change to this package. +- The `guard-core` floor rises from `>=4.1.0` to `>=4.4.0`, so upgrading djapi-guard also brings the guard-core 4.4.0 detection and dynamic rule fixes (Cookie header scanned per pair, the per-request scan budget, the semantic-only header opt-out and dynamic rule versions applied over the base config). ### Chore diff --git a/pyproject.toml b/pyproject.toml index 819ed87..ca7e6cf 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -23,7 +23,7 @@ classifiers = [ ] dependencies = [ "django", - "guard-core>=4.1.0", + "guard-core>=4.4.0", ] [project.urls]