mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-19 05:12:16 +03:00
6aa1dad10e
Correcting my own over-tightening in this branch. The previous commit refused EVERY caller-supplied `provider_options.baseUrl`, which broke a documented, tested flow: `tests/unit/search-route.test.ts` covers "v1 search POST accepts authless SearXNG with provider_options baseUrl". SearXNG is self-hosted by definition and the caller naming their own instance is the supported way to use it — I read the field as purely hostile when part of its use is legitimate. This is the gate the reporter actually recommended and I went past: allow the caller override only for a provider that is BOTH keyless and explicitly opted in via the new `allowClientBaseUrlOverride` flag. Today that is `searxng-search` alone. Every `authType: "apikey"` provider still refuses, which is the half that matters — those are the ones whose builder attaches the operator's key to whatever host the base URL resolves to. The flag is checked alongside `authType === "apikey"` at the callsite AND pinned by a registry-wide invariant in the test: no provider may carry `allowClientBaseUrlOverride` while holding a key. Inferring the capability from which builder happens to call the resolver is what let this drift in the first place, so it is now declared, not inferred. The opted-in path keeps the block-metadata guard: loopback/LAN is the entire point of a self-hosted instance, IMDS is not. search-route 8/8, the 3f8g + j7j4 suites 33/33, sibling sweep 68/68, typecheck:core exit 0, check:api-typecheck OK (289, within baseline). Also registers error-sanitizer-sk-key-qv45 in stryker tap.testFiles — check:mutation-test-coverage flagged it once error.ts entered the mutated set.