mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-17 04:12:17 +03:00
ba274b616a
#13828. `zylo-api` is registered as OpenAI-compatible, so the generic probe validated a key with `GET /v1/models` and returned on the first 2xx. Zylo serves that route WITHOUT authentication — it answers 200 with no Authorization header at all, and 200 for a bogus key — so the account-setup dialog greened any string. The first request Zylo actually authenticates is the user's own model test, which comes back `401 {"error":"Key not found: zk-…"}`. Running the production validator against a fake key returned `{valid:true}` before this change. Two corrections to the report: nothing passes a key value where a key name is expected — there is no such lookup — and that 401 text is Zylo's own, not OmniRoute's. The defect is a false-green validation, which is worse: an invalid key is stored as working and only fails later, at the model level. `POST /v1/chat/completions` is authenticated, so a single probe there is the correct auth check — the remedy already applied to dify (#11002) and bytez (#5422). Registered under both `zylo-api` and the `zylo` alias, matching the adobe-firefly/firefly pair, so a connection stored under the alias does not fall back to the open-catalog probe. Tests are red-first: a key the chat route rejects must not validate, the catalog route must not be consulted at all, a key it accepts still validates, and the alias takes the same path. The first and third failed before the fix. Not in scope, reported separately: Zylo's catalog is not OpenAI-shaped (`{text:[…],image:[…]}`), so model sync yields 0 models.