Repository navigation
fix(middleware): accept the full engine config and route exclusions through the engine - #17
Merged
Merged
Conversation
…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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #16
The plugin now accepts the full engine config.
PREST_GUARD_ENGINE_CONFIG(inline JSON) orPREST_GUARD_ENGINE_CONFIG_FILEdecode a strict JSON object ofguardcore.SecurityConfigfield names over the existing env subset (unknown keys, bad JSON, func fields and values the engine rejects fail closed with the generic 500), andGuardConfig.Configuregives a fork the built config last for the func and interface fields JSON cannot carry. The env variables keep working, andPREST_GUARD_TRUSTED_PROXY_DEPTHis new. The README documents the surface.Exclusions and client identity now run inside the engine like the other adapters. I deleted
proxy.goand 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/../articlescannot ride an excluded prefix. Behavior change to review: excluded paths still skip detection but, as in the reference,ip_securityandrate_limitstay enforced on them, so a probe source that shares an identity with a rate limit should go inPREST_GUARD_EXEMPT_IPS. Client resolution now follows the engine'strusted_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-guardto v1.4.0. I left theEnableRateLimitAutoBannote: I re-checked it and the knob is still inert through the middleware path.CustomResponseModifiercan be set throughConfigure, but it only takes effect once anethttp-guardrelease 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.