release(5.0.0): required GUARD_SECURITY_CONFIG, engine routing parity

.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

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 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
+
+- 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)
 -------------------
 

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
 ```
 
 ___

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 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
+
+- 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)
 -------------------
 

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"
 }

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"}
@@ -23,7 +23,7 @@ classifiers = [
 ]
 dependencies = [
     "django",
-    "guard-core>=4.1.0",
+    "guard-core>=4.4.0",
 ]
 
 [project.urls]