mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-13 18:32:12 +03:00
7d57d9f4a1
Rebased onto the current release/v3.8.51 tip as part of a combined provider-retirement/provenance merge batch (Designer Web, Felo Web, Runtime, GPL-derived removal, Qwen Web already landed). Large conflict set (this is the biggest PR in the batch — the common ChatGPT Web provider touches chat, images, count-tokens, session leases, and combos). Conflicts resolved: - `open-sse/config/providers/registry/chatgpt-web/*`, `open-sse/executors/chatgpt-web*`, `open-sse/handlers/imageGeneration/providers/chatgptWeb.ts`, and their tests: kept deleted, matching the PR's stated scope. - `open-sse/config/providers/registry/minimax/web/index.ts`, `open-sse/handlers/imageGeneration/providers/geminiWeb.ts`, `open-sse/executors/gemini-web.ts`'s stale image-mode branch: base-drift collisions against already-merged sibling retirements (#11691, #11708) — kept deleted / dropped the dead code, since this PR's own branch forked before those merged. - `src/shared/constants/reservedProviderPrefixes.ts`, `open-sse/executors/index.ts`, `executorProxy.ts`, `virtualFactory.ts`, `autoStrategy.ts`, `src/lib/db/providers.ts`, `src/sse/handlers/chat.ts`: combined the Designer + Runtime (Felo/Qwen) + common-ChatGPT-Web retirement guard calls at each shared chokepoint — compute-once-then-OR pattern, consistent with prior combinations in this batch. - `src/sse/services/model.ts` / `src/sse/handlers/chatHelpers.ts`: adopted this PR's new `getModelInfoOrRetirementResponse()` central wrapper (a real improvement over ad-hoc try/catch), and extended it to also catch the Designer + Runtime retirement errors it didn't originally cover, so the consolidation doesn't regress the other two mechanisms. - `src/app/api/v1/images/edits/route.ts`: this PR moved the retirement check earlier (before `enforceApiKeyPolicy`) but left the old later call+catch block in place from base drift — removed the now-redundant duplicate `resolveImageRouteModel()` call and merged the Designer catch into the earlier one. - `open-sse/config/imageRegistry.ts`, `tests/snapshots/executors/executor-map.json` (`keyCount` recomputed to 133), `tests/snapshots/provider/translate-path.json`: same "both sides inserted a different retired provider at the same slot" pattern — resolved by dropping both. - `tests/unit/chatcore-executor-proxy.test.ts`, `provider-node-reserved-prefix.test.ts`, `combo-auto-candidate-expansion.test.ts`, `messages-count-tokens-route.test.ts`, `virtual-auto-combo.test.ts`: split into independent per-mechanism test blocks (established pattern); `virtual-auto-combo.test.ts`'s old "includes cookie web-session providers" positive-inclusion test (which used chatgpt-web as its example) was retired along with the provider and replaced by this PR's negative-exclusion test for the same slot. - `docs/architecture/ARCHITECTURE.md`, `CODEBASE_DOCUMENTATION.md` (+ 4 i18n mirrors), `README.md`, `FREE-TIERS-GUIDE.md`, `docs/diagrams/free-tier-budget.svg`, `docs/screenshots/free-tier-budget-card.svg`, `docs/reference/PROVIDER_REFERENCE.md`: recomputed every stale count from the real merged state — 104 executors (`countFiles` gate logic), 351 providers (regenerated via `gen:provider-reference`), 152/351 `hasFree` entries, 445/438/7 free-tier catalog rows, 13 ToS-avoid providers, budget-card regenerated via its real generator script. One doc conflict (`oauth/` module list) needed picking HEAD's side specifically — theirs still listed the already-removed `raycast` module instead of the real `openference`. - `config/quality/test-masking-allowlist.json`: additive merge of the PR's 17 `_deletedWithReplacement` entries alongside the batch's existing ones (one real duplicate-key mistake in my first pass, caught and fixed via a `object_pairs_hook` duplicate-key check before finalizing). Also fixed two real, unrelated-to-my-merge issues surfaced by the focused suite: - `tests/unit/resolve-web-provider-host.test.ts`: the PR's own test had a typo — it asserted `perplexity-web`'s resolved host as `"perplexity.ai"`, but the provider's registered `website` is `"https://www.perplexity.ai"` and the resolver returns the URL's `host` verbatim (no www-stripping), so the correct value is `"www.perplexity.ai"` (consistent with the same test's own `url` assertion). - `tests/unit/hard-session-lease-bypass-inventory.test.ts`: this golden call-site inventory was already stale on the pristine post-#11713 tip (confirmed via a throwaway probe worktree) — `src/lib/db/providers.ts`'s 3 connection-fallback sites and a third `src/app/api/providers/route.ts` site were never added to the golden list by the earlier-merged #11698/#11720 PRs. Updated it to the real current inventory (dated inline comments explain each delta and which PR introduced it), plus this PR's own legitimate deltas (image-edits duplicate-call removal, `ChatGptWebExecutor.execute()` site removed). Focused suite green (433/433 across executor-proxy, reserved-prefix, hard-session-lease-bypass-inventory, resolve-web-provider-host, retirement/runtime-block/source-retirement/management-retirement/image-handler-retirement, migration-168, combo-auto-candidate-expansion, virtual-auto-combo, executor-map-golden and siblings), plus `typecheck:core`, `check-file-size`, and `check-changelog-integrity` clean. Thanks for the thorough provenance-hold retirement work — appreciated.
193 lines
5.4 KiB
Markdown
193 lines
5.4 KiB
Markdown
---
|
|
title: "Getting Started — Web Cookie Providers"
|
|
version: 3.8.40
|
|
lastUpdated: 2026-07-20
|
|
---
|
|
|
|
# Web Cookie Providers
|
|
|
|
Web Cookie providers let OmniRoute use an AI service through your existing browser session instead of an API key. They are useful when you already have access to a service through its website and want OmniRoute to use the same authenticated session.
|
|
|
|
Unlike API-key providers, Web Cookie providers authenticate using the credentials that your browser sends to the website.
|
|
|
|
---
|
|
|
|
# Before You Begin
|
|
|
|
> **Important:** Always copy credentials from a **live network request**, **not** from your browser's cookie storage.
|
|
|
|
Many authentication issues are caused by copying cookies from the wrong place.
|
|
|
|
## Do NOT copy from Cookie Storage
|
|
|
|
Most browsers expose stored cookies through:
|
|
|
|
```
|
|
DevTools
|
|
→ Application (or Storage)
|
|
→ Cookies
|
|
```
|
|
|
|
Although these cookies look correct, they may be:
|
|
|
|
- stale
|
|
- incomplete
|
|
- missing cookies only sent on authenticated requests
|
|
|
|
Using these values may cause authentication failures even if they appear valid.
|
|
|
|
## Copy from a Live Request
|
|
|
|
Instead, use the cookies from a successful request:
|
|
|
|
```
|
|
DevTools
|
|
→ Network
|
|
→ Refresh the page
|
|
→ Open a chat or conversation request
|
|
→ Request Headers
|
|
→ Cookie
|
|
```
|
|
|
|
The `Cookie` request header contains the exact authentication information that your browser successfully used.
|
|
|
|
For most Web Cookie providers, this is the value that should be pasted into OmniRoute.
|
|
|
|
---
|
|
|
|
# General Setup
|
|
|
|
The setup process is the same for most Web Cookie providers.
|
|
|
|
1. Sign in to the provider's website.
|
|
2. Open the browser's Developer Tools.
|
|
3. Open the **Network** tab.
|
|
4. Refresh the page.
|
|
5. Open an authenticated chat or conversation request.
|
|
6. Copy the required authentication credentials.
|
|
7. Open OmniRoute.
|
|
8. Go to **Providers → Add Provider**.
|
|
9. Select your Web Cookie provider.
|
|
10. Paste the credentials.
|
|
11. Click **Test Connection**.
|
|
12. Save the provider.
|
|
|
|
The exact credentials required depend on the provider.
|
|
|
|
---
|
|
|
|
# Provider Credential Formats
|
|
|
|
Different websites store authentication differently. Some require only cookies, while others may require additional headers or tokens.
|
|
|
|
| Provider | Credential Format | Provider Guide |
|
|
| ------------------- | -------------------------- | ------------------------------- |
|
|
| Claude Web | Full Cookie request header | `docs/providers/CLAUDE_WEB.md` |
|
|
| ChatGPT Web (Codex) | Full Cookie header | `docs/providers/CHATGPT_WEB.md` |
|
|
| Gemini Web | _(verify)_ | |
|
|
| Copilot Web | _(verify)_ | |
|
|
| Grok Web | _(verify)_ | |
|
|
| ... | ... | ... |
|
|
|
|
> Update this table as new Web Cookie providers are added or existing providers change their authentication requirements.
|
|
|
|
---
|
|
|
|
# What Web Cookie Providers Can and Cannot Do
|
|
|
|
Web Cookie providers reuse a website's chat interface. They do **not** provide the same capabilities as official APIs.
|
|
|
|
## Supported
|
|
|
|
- Authenticate using your existing browser session
|
|
- Access models available through your account
|
|
- Stream chat responses
|
|
- No API key required
|
|
|
|
## Not Supported
|
|
|
|
- Function calling
|
|
- Tool calling
|
|
- Automatic file editing
|
|
- Agentic IDE workflows
|
|
- API-only features
|
|
|
|
This is expected behaviour and is **not** a bug.
|
|
|
|
If you need tool execution, automatic file editing, or other agent workflows, use an **API-key provider** instead of a Web Cookie provider.
|
|
|
|
---
|
|
|
|
# Validation Caveat
|
|
|
|
A successful **Test Connection** or cookie validation only verifies that the supplied credentials appear to be in the expected format.
|
|
|
|
Until Issue #7857 is resolved, a successful validation **does not guarantee** that the provider will authenticate successfully.
|
|
|
|
If authentication still fails, verify that you copied the credentials from a live network request rather than browser cookie storage.
|
|
|
|
---
|
|
|
|
# Troubleshooting
|
|
|
|
## Authentication Fails
|
|
|
|
Verify that the credentials were copied from:
|
|
|
|
```
|
|
Network
|
|
→ Request Headers
|
|
→ Cookie
|
|
```
|
|
|
|
and **not** from:
|
|
|
|
```
|
|
Application
|
|
→ Cookies
|
|
```
|
|
|
|
---
|
|
|
|
## Cookie Works in Browser but Not in OmniRoute
|
|
|
|
Some providers include cookies that are only sent during authenticated requests.
|
|
|
|
Recopy the credentials from a fresh network request after successfully opening a conversation.
|
|
|
|
---
|
|
|
|
## Session Expired
|
|
|
|
Web Cookie providers use your existing browser session.
|
|
|
|
If your browser session expires or you sign out, you must copy a new set of credentials.
|
|
|
|
---
|
|
|
|
## Test Connection Passes but Requests Fail
|
|
|
|
Until Issue #7857 is resolved, passing validation does not guarantee that the authentication request will succeed.
|
|
|
|
Recopy your credentials from a fresh authenticated request before troubleshooting further.
|
|
|
|
---
|
|
|
|
# Provider Example
|
|
|
|
For a complete provider-specific walkthrough, see:
|
|
|
|
- **Claude Web** — `docs/providers/CLAUDE_WEB.md`
|
|
|
|
The Claude Web guide demonstrates the complete setup process for a Web Cookie provider and serves as the reference implementation.
|
|
|
|
---
|
|
|
|
# Best Practices
|
|
|
|
- Copy credentials from a fresh authenticated request.
|
|
- Avoid reusing old cookies.
|
|
- Keep your browser session active while using Web Cookie providers.
|
|
- Treat copied cookies as sensitive credentials.
|
|
- Use API-key providers when you need function calling or agent workflows.
|