Skip to content

fix(middleware): accept the full engine config and route exclusions through the engine - #17

Merged
rennf93 merged 1 commit into
masterfrom
parity/adapter-parity
Oct 15, 2026
Merged

rennf93 merged 1 commit into
masterfrom
parity/adapter-parity

Conversation

@rennf93

@rennf93 rennf93 commented Oct 15, 2026 •

Copy link
Copy Markdown
Member

Closes #16

The plugin now accepts the full engine config. PREST_GUARD_ENGINE_CONFIG (inline JSON) or PREST_GUARD_ENGINE_CONFIG_FILE decode a strict JSON object of guardcore.SecurityConfig field names over the existing env subset (unknown keys, bad JSON, func fields and values the engine rejects fail closed with the generic 500), and GuardConfig.Configure gives a fork the built config last for the func and interface fields JSON cannot carry. The env variables keep working, and PREST_GUARD_TRUSTED_PROXY_DEPTH is new. The README documents the surface.

Exclusions and client identity now run inside the engine like the other adapters. I deleted proxy.go and the path short-circuit in the handler; the pre-engine matcher stays only for the 503 window before an engine exists, and it now cleans the path so /_health/../articles cannot ride an excluded prefix. Behavior change to review: excluded paths still skip detection but, as in the reference, ip_security and rate_limit stay enforced on them, so a probe source that shares an identity with a rate limit should go in PREST_GUARD_EXEMPT_IPS. Client resolution now follows the engine's trusted_proxy_depth (default 1) instead of the old rightmost-untrusted walk.

I also fixed the stale comment about the chain walk, refreshed the README text and benchmark table against the current engine (large-value truncation exists now, 8 KiB prose ~28 ms, 256 KiB ~1.2 s), and bumped nethttp-guard to v1.4.0. I left the EnableRateLimitAutoBan note: I re-checked it and the knob is still inert through the middleware path.

CustomResponseModifier can be set through Configure, but it only takes effect once a nethttp-guard release carries the modifier wiring (Guard-Core/nethttp-guard#40); I did not pin a pseudo-version. Tests fail on master for the JSON surface, the excluded-path routing, the traversal and the depth variable, and the gate is green: gofmt, vet, go test -race ./..., the plugin build and staticcheck.

…hrough the engine

PREST_GUARD_ENGINE_CONFIG and PREST_GUARD_ENGINE_CONFIG_FILE decode a strict JSON object over the env subset, and GuardConfig.Configure gives a fork the built SecurityConfig last. PREST_GUARD_TRUSTED_PROXY_DEPTH reaches the engine's trusted_proxy_depth.

Excluded paths and client identity resolution now run inside the engine like the other adapters, so excluded responses carry the security headers and metrics and ip_security and rate_limit stay enforced on them as in the reference. The README and benchmark table are refreshed against the current engine and nethttp-guard moves to v1.4.0. Closes #16
@github-actions github-actions Bot added documentation Docs, README, governance files area: middleware Touches the plugin middleware core config PREST_GUARD_* configuration surface tests Test suite changes build Makefile / module files / plugin packaging dependencies go.mod or go.sum changes labels Oct 15, 2026
@rennf93
rennf93 merged commit 808c83f into master Oct 15, 2026
10 checks passed
@rennf93
rennf93 deleted the parity/adapter-parity branch October 15, 2026 11:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: middleware Touches the plugin middleware core build Makefile / module files / plugin packaging config PREST_GUARD_* configuration surface dependencies go.mod or go.sum changes documentation Docs, README, governance files tests Test suite changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix: accept the full engine config, route exclusions and client resolution through the engine

1 participant