feat: Add LM Studio provider with dynamic model discovery

[athul0rameshan9]

Summary

Add LM Studio as a built-in provider and implement a 'Fetch Models' button that auto-discovers available models from any OpenAI-compatible local server, eliminating the need to manually specify models in the env file.

Related Issues

Fixes #730

Changes

• Register lmstudio as a built-in provider (localhost:1234/v1, no API key required)
• Add /api/list-models endpoint to fetch models from OpenAI-compatible /v1/models APIs
• Add 'Fetch Models' button to provider settings panel for all OpenAI-type providers
• Add LMSTUDIO_BASE_URL / LMSTUDIO_MODELS env var support in server provider config
• Add i18n translations (en-US, zh-CN)

Type of Change

• New feature (non-breaking change that adds functionality)

Verification

• My changes do not introduce new warnings
• TypeScript compiles without errors (tsc --noEmit)

[wyuc]

Thanks for this, and welcome — a clean, well-structured first contribution (nice that you covered every locale). A few things to address before merge; two are security-related.

🔴 Server API key can leak to a client-supplied host — app/api/list-models/route.ts
For a server-managed provider configured with only an API key (e.g. OPENAI_API_KEY set, no OPENAI_BASE_URL), resolveBaseUrl() returns undefined, so resolveBaseUrl(...) || clientBaseUrl falls back to the client-supplied baseUrl while resolveApiKey() still returns the server secret. The request then sends Authorization: Bearer <server key> to an arbitrary client-controlled host. For managed providers, please ignore clientBaseUrl entirely and use only the server/default URL when a server key is attached.

🔴 Missing SSRF guard — app/api/list-models/route.ts
The other routes that fetch a client-supplied URL (app/api/generate/voice, azure-voices, generate/video, proxy-media, parse-pdf) all call validateUrlForSSRF() from @/lib/server/ssrf-guard before fetching. This new route fetches after only new URL() parsing, so a crafted baseUrl can make the server probe internal addresses, and the upstream error body is returned to the caller. Please run the same validateUrlForSSRF() before building/fetching modelsUrl. This matters most for hosted / multi-tenant deployments.

🟡 Success-response shape mismatch breaks the feature — components/settings/provider-config-panel.tsx
apiSuccess({ models }) serializes as { success: true, models: [...] } (the helper spreads, it does not nest under data). The client reads data.data?.models, which is always undefined, so even a successful fetch shows the failure message. Read data.models instead.

Once the two security items are addressed the rest looks good. Thanks again for the contribution!

[athul0rameshan9]

Thanks for the review! All three items have been addressed:

• 🔴 API key leak: Managed providers now ignore all client-supplied credentials (isServerConfiguredProvider check, matching the pattern in tts/voice/video routes)
• 🔴 SSRF guard: Added validateUrlForSSRF() on client-supplied base URLs before fetching
• 🟡 Response shape: Client now reads data.models instead of data.data?.models

Also rebased onto latest main. Ready for re-review!

[wyuc]

Review: /api/list-models + LM Studio provider

Thanks for the PR — the model auto-discovery is a nice addition, and the SSRF guard + managed-provider key/baseUrl isolation are good to see. One blocking issue and a couple of follow-ups before merge.

🔴 P1 (blocking) — Redirect-based SSRF bypass · app/api/list-models/route.ts

The outbound fetch(modelsUrl, …) uses the default redirect: 'follow', but validateUrlForSSRF() only validates the initial user-supplied baseUrl. An attacker can supply a public baseUrl that returns a 3xx redirect to an internal target (e.g. cloud metadata http://169.254.169.254/…, localhost, or an internal service); fetch transparently follows it and the redirect target is never re-validated — so the SSRF guard is bypassed and the upstream body is returned to the caller.

This is reachable unauthenticated on deployments where ACCESS_CODE is unset (the default for the public demo and typical self-host).

The repo already has the right pattern for this — please mirror it:

• app/api/proxy-media/route.ts uses redirect: 'manual' and re-validates every Location hop with validateUrlForSSRF (see [RFC] SSRF hardening: redirect re-validation, second-hop protection, IP pinning #398).
• app/api/azure-voices/route.ts and app/api/verify-pdf-provider/route.ts use redirect: 'manual' and reject 3xx.
• The REDIRECT_NOT_ALLOWED / TOO_MANY_REDIRECTS error codes already exist in lib/server/api-response.ts.

/api/list-models is currently the only user-URL-fetching route missing this protection.

🟡 P2 — defaultBaseUrl fallback · app/api/list-models/route.ts + components/settings/index.tsx

Two issues on the same fallback path:

• Security: only safeClientBaseUrl goes through validateUrlForSSRF. The || provider?.defaultBaseUrl branch is fetched without any SSRF check. It's a hardcoded constant today (so low risk), but the guard should run against the resolved baseUrl, not just the raw client input. (The middle || safeClientBaseUrl term is also dead code — resolveBaseUrl already returns it for unmanaged providers.)
• Correctness: for a fresh LM Studio setup with the Base URL field left blank, the fetch succeeds via defaultBaseUrl but only the models are persisted, not the base URL. Since keyless providers are considered configured only when baseUrl is set, the provider still won't appear in the active model list until the user manually types the URL. Either persist the effective default base URL, or require it before fetching.

🟡 P2 — Upstream error body echoed verbatim · app/api/list-models/route.ts

On a non-OK upstream response the route returns Provider returned ${status}: ${errorText} (the full raw upstream body) to the client. Combined with the P1 this is the exfiltration channel, but it's also an independent info leak. Other routes (verify-model, verify-image-provider) return sanitized/generic messages and log the detail server-side — please do the same here.

🔵 P3 (nit) — SSRF gating divergence

This route validates unconditionally, whereas most sibling routes gate the check on NODE_ENV === 'production'. Unconditional is the more secure choice (and there's the ALLOW_LOCAL_NETWORKS=true escape hatch), but note it means a local LM Studio at localhost:1234 is blocked unless that env var is set — which slightly undercuts the feature's main use case. A short code comment explaining the trade-off would help.

---

Verified OK

Managed-provider key isolation (client key/baseUrl suppressed for admin-owned providers) ✅ · AbortController 10s timeout with clearTimeout on all paths ✅ · localeCompare guarded by if (model.id) ✅.

The P1 is the only hard blocker. Happy to re-review once the redirect handling is in.