refactor(validators): centralize endpoint URL policy and allow HTTP in development#11
Merged
Merged
Conversation
…n development
The four endpoint validators (CreateEndpointRequestValidator, UpdateEndpointRequestValidator, and the dashboard equivalents) each carried their own copy of a private static BeValidHttpsUrl helper. Extracted the rule into a single EndpointUrlPolicy service injected via the DI container; AddValidatorsFromAssemblyContaining<Program>() resolves it for every endpoint validator without further wiring.
Production behavior is unchanged: HTTPS remains the only accepted scheme. In Development environments (IHostEnvironment.IsDevelopment() == true), HTTP is also accepted so local end-to-end testing — Docker compose with a host receiver, sample receivers, ngrok-free flows — works without TLS plumbing. The relaxation is gated on the host environment rather than a feature flag, so production deployments cannot accidentally opt in. The validation message adapts ("HTTPS or HTTP" vs "HTTPS") so callers see the rule that applies in their environment.
All 142 existing tests still pass — they run under the default Testing environment with no Development override and continue to expect HTTPS.
CI runners hit the 100ms production default on JmesPath.Net's first JIT-warmed evaluation, intermittently flipping the size and reshape tests into the timeout fail-open path. Test fixtures now use a 5000ms ceiling by default; the production default in TransformationOptions stays at 100ms. Tests that specifically exercise the timeout still pass an explicit short value.
3 tasks
voyvodka
added a commit
that referenced
this pull request
May 11, 2026
…le mock-fetch (#100) CodeQL alert #11 (HIGH severity, js/incomplete-url-substring-sanitization) on samples/portal-host/src/mock-fetch.ts:117. The previous shape was: if (!url.startsWith(BASE)) return originalFetch(input, init); with BASE = 'https://hooks.example.com'. The startsWith check correctly catches paths like https://hooks.example.com/api/v1/portal/endpoints, but it ALSO matches https://hooks.example.com.attacker.com/api/v1/portal/endpoints — the BASE prefix can be followed by an arbitrary host suffix. This is fine for the sample's mock semantics in isolation (the worst case is the mock answers a request that should have gone to the real network), but the kind of pattern that absolutely should not get copy-pasted into production code. Fixed by parsing the URL and comparing protocol + host explicitly via WHATWG URL. Same intent, no substring trap. Also flipped path = url.slice(BASE.length).split('?')[0] to path = parsed.pathname which is the same value via a safer route. The route handlers downstream are unchanged. Closes the CodeQL alert. No test changes required — the mock continues to serve the same routes for the same inputs the sample emits.
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
1 participant
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.
Why
Local end-to-end testing of the JMESPath transformation pipeline (and the upcoming sample receivers / Docker compose flows) needs to point endpoints at a host receiver on `http://host.docker.internal:9999\` or similar. The existing validator hard-codes HTTPS-only, which is correct for production but blocks local verification without TLS plumbing.
What changed
Test plan