github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-16 13:19:40 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #15680] Add trusted browser extension onboarding with extension-ID allowlist (CORS-safe local integrations) #56516

New Issue
Open
opened 2026-04-29 10:57:08 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-29 10:57:08 -05:00
Owner
Copy Link

Originally created by @joelnishanth on GitHub (Apr 18, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/15680

Summary

Ollama currently supports custom origins via OLLAMA_ORIGINS, including browser extension origins like chrome-extension://*. However, this approach is too coarse and lacks a first-class onboarding flow for browser extensions.

This makes it difficult to build secure, local-first integrations (e.g., Chrome extensions) without relying on fragile workarounds. I am currently building a browser extension which uses Ollama for filling out Forms online. i.e job applications . This is disrupting the onboarding experience as they have to run a command in the terminal to allow chrome explicitly which is a pain for non technical users and its turning them away.

https://apply.offlyn.ai

Problem

Browser extensions cannot reliably POST to Ollama due to strict Origin validation:

Origin: chrome-extension://

Unless users manually configure OLLAMA_ORIGINS, requests are rejected.

Current limitations

  • No first-class support for browser extensions
  • Coarse control (e.g., chrome-extension://* allows all extensions)
  • No user-facing approval/onboarding flow
  • No way to list/revoke allowed extensions
  • Forces workaround patterns (hidden tabs, injected scripts)

Real-world impact

To make extensions work today, developers must:

This workaround:

  • Adds complexity
  • Breaks streaming (must use stream: false)
  • Introduces lifecycle/race issues
  • Feels like a hack rather than a supported path

Proposal

Introduce a first-class trusted browser extension model with explicit onboarding and per-extension allowlisting.

1) Extension ID–based allowlist

Allow explicit configuration of trusted extensions:

OLLAMA_ORIGINS=chrome-extension://abc123...

Encourage specific extension IDs instead of wildcards like chrome-extension://*.

2) Interactive onboarding (recommended)

When an unknown extension attempts access, prompt the user:

A browser extension is requesting access to Ollama:

Origin: chrome-extension://abc123...
Requested endpoints: /api/generate, /api/embeddings

Allow?
[ ] Allow once
[ ] Always allow
[ ] Deny

Benefits:

  • Explicit user consent
  • Visibility into who is accessing Ollama
  • Aligns with browser/OS permission models

3) Persistent trusted extension registry

Store approved extensions locally (file or config):

{
"trusted_extensions": [
{
"origin": "chrome-extension://abc123...",
"permissions": ["generate", "embeddings"],
"added_at": "2026-04-18T00:00:00Z"
}
]
}

4) Management commands

Examples:

ollama extensions list
ollama extensions allow chrome-extension://abc123...
ollama extensions revoke chrome-extension://abc123...

Optional: lightweight local UI

5) (Optional) Permission scoping

Per-extension scopes:

  • generate (chat/completions)
  • embeddings
  • pull (model downloads)
  • list (model listing)

Why this matters

  • Enables local-first browser extension ecosystem
  • Safer than allowing all extensions
  • Eliminates hidden-tab/injection workarounds
  • Restores full API functionality (including streaming)
  • Improves developer experience

Backward compatibility

  • Existing OLLAMA_ORIGINS behavior remains unchanged
  • New functionality is additive and opt-in

Alternative considered

Hidden tab + injected script proxy:

  • Works today but is complex, fragile, and breaks streaming
  • Not suitable as a long-term solution

Ask

Would you be open to supporting a first-class trusted extension flow (ID-based allowlist + optional onboarding prompt)?

Happy to contribute implementation if aligned.

Originally created by @joelnishanth on GitHub (Apr 18, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/15680 # Summary Ollama currently supports custom origins via `OLLAMA_ORIGINS`, including browser extension origins like `chrome-extension://*`. However, this approach is too coarse and lacks a first-class onboarding flow for browser extensions. This makes it difficult to build secure, local-first integrations (e.g., Chrome extensions) without relying on fragile workarounds. I am currently building a browser extension which uses Ollama for filling out Forms online. i.e job applications . This is disrupting the onboarding experience as they have to run a command in the terminal to allow chrome explicitly which is a pain for non technical users and its turning them away. https://apply.offlyn.ai ## Problem Browser extensions cannot reliably POST to Ollama due to strict Origin validation: Origin: chrome-extension://<extension-id> Unless users manually configure `OLLAMA_ORIGINS`, requests are rejected. ### Current limitations - No first-class support for browser extensions - Coarse control (e.g., `chrome-extension://*` allows all extensions) - No user-facing approval/onboarding flow - No way to list/revoke allowed extensions - Forces workaround patterns (hidden tabs, injected scripts) ## Real-world impact To make extensions work today, developers must: - Create a hidden tab at http://localhost:11434 - Inject a script and call fetch() from that page context This workaround: - Adds complexity - Breaks streaming (must use `stream: false`) - Introduces lifecycle/race issues - Feels like a hack rather than a supported path ## Proposal Introduce a first-class trusted browser extension model with explicit onboarding and per-extension allowlisting. ### 1) Extension ID–based allowlist Allow explicit configuration of trusted extensions: OLLAMA_ORIGINS=chrome-extension://abc123... Encourage specific extension IDs instead of wildcards like `chrome-extension://*`. ### 2) Interactive onboarding (recommended) When an unknown extension attempts access, prompt the user: A browser extension is requesting access to Ollama: Origin: chrome-extension://abc123... Requested endpoints: /api/generate, /api/embeddings Allow? [ ] Allow once [ ] Always allow [ ] Deny Benefits: - Explicit user consent - Visibility into who is accessing Ollama - Aligns with browser/OS permission models ### 3) Persistent trusted extension registry Store approved extensions locally (file or config): { "trusted_extensions": [ { "origin": "chrome-extension://abc123...", "permissions": ["generate", "embeddings"], "added_at": "2026-04-18T00:00:00Z" } ] } ### 4) Management commands Examples: ollama extensions list ollama extensions allow chrome-extension://abc123... ollama extensions revoke chrome-extension://abc123... Optional: lightweight local UI ### 5) (Optional) Permission scoping Per-extension scopes: - generate (chat/completions) - embeddings - pull (model downloads) - list (model listing) ## Why this matters - Enables local-first browser extension ecosystem - Safer than allowing all extensions - Eliminates hidden-tab/injection workarounds - Restores full API functionality (including streaming) - Improves developer experience ## Backward compatibility - Existing `OLLAMA_ORIGINS` behavior remains unchanged - New functionality is additive and opt-in ## Alternative considered Hidden tab + injected script proxy: - Works today but is complex, fragile, and breaks streaming - Not suitable as a long-term solution ## Ask Would you be open to supporting a first-class trusted extension flow (ID-based allowlist + optional onboarding prompt)? Happy to contribute implementation if aligned.
GiteaMirror added the feature request label 2026-04-29 10:57:08 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#56516
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?