github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-06 16:11:34 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #3571] Let ollama's locally started api server support cross-domain!! #27963

New Issue
Closed
opened 2026-04-22 05:37:54 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-22 05:37:54 -05:00
Owner
Copy Link

Originally created by @kirakiray on GitHub (Apr 10, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/3571

What are you trying to do?

I am a front-end development programmer. I found that if the api service started by ollama allows cross-domain requests, then the online web application can also directly request the localhost api, which will greatly reduce the usage threshold of ollama-related applications.

How should we solve this?

You need to add headers to the returned headers, similar to the following code
response.Header.Set("Access-Control-Allow-Origin", "*")

If you are worried about the abuse of this cross-domain interface, you can add similar instructions to enable the cross-domain function on a specific port, similar to the following operations:
ollama serve --port:5551 --cross-domain

What is the impact of not solving this?

The current ollama-related web applications must be started locally on the computer before they can be used, which is very unfriendly to users.
There are also some applications that need to expose (or proxy) the local ollama port to the public network in order to be used by these applications, which will cause greater security issues.

If this cross-domain requirement is completed, online web applications will easily use the local ollama API interface. This is a very convenient operation because users do not need to consider how to download or install the application itself.

Anything else?

I now use nodejs to expose the local ollama port (11434) to 11001, and then deceive the server's request source to achieve the desired effect I want. This allows my web application to be online and use the native ollama api. (chrome and firefox work fine)

The script address is: https://github.com/kirakiray/test-website/blob/main/scripts/proxy-server.js

Originally created by @kirakiray on GitHub (Apr 10, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/3571 ### What are you trying to do? I am a front-end development programmer. I found that if the api service started by ollama allows cross-domain requests, then the online web application can also directly request the localhost api, which will greatly reduce the usage threshold of ollama-related applications. ### How should we solve this? You need to add headers to the returned headers, similar to the following code `response.Header.Set("Access-Control-Allow-Origin", "*")` If you are worried about the abuse of this cross-domain interface, you can add similar instructions to enable the cross-domain function on a specific port, similar to the following operations: `ollama serve --port:5551 --cross-domain` ### What is the impact of not solving this? The current ollama-related web applications must be started locally on the computer before they can be used, which is very unfriendly to users. There are also some applications that need to expose (or proxy) the local ollama port to the public network in order to be used by these applications, which will cause greater security issues. If this cross-domain requirement is completed, online web applications will easily use the local ollama API interface. This is a very convenient operation because users do not need to consider how to download or install the application itself. ### Anything else? I now use nodejs to expose the local ollama port (11434) to 11001, and then deceive the server's request source to achieve the desired effect I want. This allows my web application to be online and use the native ollama api. (chrome and firefox work fine) The script address is: https://github.com/kirakiray/test-website/blob/main/scripts/proxy-server.js
GiteaMirror commented 2026-04-22 05:37:55 -05:00
Author
Owner
Copy Link

@erhhung commented on GitHub (Apr 12, 2024):

So that CORS support isn't always open to all domains, I'd suggest supporting an arg like --cors [domain] (or --cors[=domain]) where the optional domain value is "*" if not given, or an URI like "http://example.com".

And if CORS is enabled via --cors, the server should also send, in addition to the "Access-Control-Allow-Origin" response header, the header "Access-Control-Allow-Methods: OPTIONS, GET, HEAD, POST, DELETE" (based on currently supported APIs), and actually handle preflight OPTIONS requests.

<!-- gh-comment-id:2052178368 --> @erhhung commented on GitHub (Apr 12, 2024): So that CORS support isn't always open to all domains, I'd suggest supporting an arg like `--cors [domain]` (or `--cors[=domain]`) where the optional `domain` value is "`*`" if not given, or an URI like "`http://example.com`". And if CORS is enabled via `--cors`, the server should also send, in addition to the "`Access-Control-Allow-Origin`" response header, the header "`Access-Control-Allow-Methods: OPTIONS, GET, HEAD, POST, DELETE`" _(based on currently supported APIs)_, and actually handle preflight `OPTIONS` requests.
GiteaMirror commented 2026-04-22 05:37:56 -05:00
Author
Owner
Copy Link

@BruceMacD commented on GitHub (May 14, 2024):

Thanks to you both for the feedback on the CORS configuration. We unfortunately can't set CORS to allow all origins by default for security reasons, but I have added allow-methods in a recent release.

It is actually possible to set CORS configuration by using the OLLAMA_ORIGINS environment variable:
https://github.com/ollama/ollama/blob/main/docs/faq.md#how-can-i-allow-additional-web-origins-to-access-ollama

I'm going to resolve this one for now, with the plan to improve the OLLAMA_ORIGINS interface continuing in #2335.

<!-- gh-comment-id:2110944181 --> @BruceMacD commented on GitHub (May 14, 2024): Thanks to you both for the feedback on the CORS configuration. We unfortunately can't set CORS to allow all origins by default for security reasons, but I have added allow-methods in a recent release. It is actually possible to set CORS configuration by using the `OLLAMA_ORIGINS` environment variable: https://github.com/ollama/ollama/blob/main/docs/faq.md#how-can-i-allow-additional-web-origins-to-access-ollama I'm going to resolve this one for now, with the plan to improve the OLLAMA_ORIGINS interface continuing in #2335.
GiteaMirror commented 2026-04-22 05:37:57 -05:00
Author
Owner
Copy Link

@matthiasgeihs commented on GitHub (Oct 25, 2024):

Thanks to you both for the feedback on the CORS configuration. We unfortunately can't set CORS to allow all origins by default for security reasons, but I have added allow-methods in a recent release.

@BruceMacD Can you elaborate on the security reasons?

<!-- gh-comment-id:2438904029 --> @matthiasgeihs commented on GitHub (Oct 25, 2024): > Thanks to you both for the feedback on the CORS configuration. We unfortunately can't set CORS to allow all origins by default for security reasons, but I have added allow-methods in a recent release. @BruceMacD Can you elaborate on the security reasons?
GiteaMirror commented 2026-04-22 05:37:57 -05:00
Author
Owner
Copy Link

@erhhung commented on GitHub (Oct 26, 2024):

@BruceMacD Can you elaborate on the security reasons?

@matthiasgeihs You surely wouldn't want just ANY website on the Internet to be able to make calls to http://localhost:11434, would you, especially since that port is becoming a well-known port number?

If the ollama server always included the response header "Access-Control-Allow-Origin: *", then ANY web app or malicious iframe can try to connect to http://localhost:11434 and query for possibly your RAG'ed private information without your consent.

Public API servers do generally allow all CORS requests, but they will also require client authentication before authorizing an API call. Since ollama provides no out-of-box API client authentication facility, it needs to play safe by default.

Here's an article I found describing ollama & auth: https://www.arsturn.com/blog/understanding-authentication-in-ollama

<!-- gh-comment-id:2439287659 --> @erhhung commented on GitHub (Oct 26, 2024): > @BruceMacD Can you elaborate on the security reasons? @matthiasgeihs You surely wouldn't want just **ANY** website on the Internet to be able to make calls to `http://localhost:11434`, would you, especially since that port is becoming a well-known port number? If the ollama server always included the response header "`Access-Control-Allow-Origin: *`", then ANY web app or malicious iframe can try to connect to `http://localhost:11434` and query for possibly your RAG'ed private information without your consent. Public API servers do generally allow all CORS requests, but they will also require client authentication before authorizing an API call. Since ollama provides no out-of-box API client authentication facility, it needs to play safe by default. Here's an article I found describing ollama & auth: https://www.arsturn.com/blog/understanding-authentication-in-ollama
GiteaMirror commented 2026-04-22 05:37:58 -05:00
Author
Owner
Copy Link

@matthiasgeihs commented on GitHub (Oct 27, 2024):

@erhhung Absolutely! Thanks for the pointer to the article. The reason why I was asking: I'm experimenting with a Chrome extension that uses Ollama. Currently, to make this work, a user has to manually set the OLLAMA_ORIGINS flag. This is way too much to ask from a regular user. (I would argue even an Ollama regular user.) So while I agree that opening up Ollama to any web page is not what we want, I'm wondering if there is a secure and easy way to make access from a Chrome extension work. I'm thinking in the direction of integrating API_KEY functionality with the Ollama REST interface. Alternatively, there could be a popup if an unknown origin queries Ollama. Then, the user could accept or deny the request. What do you think? Are there already any efforts in either of these directions?

<!-- gh-comment-id:2440171900 --> @matthiasgeihs commented on GitHub (Oct 27, 2024): @erhhung Absolutely! Thanks for the pointer to the article. The reason why I was asking: I'm experimenting with a Chrome extension that uses Ollama. Currently, to make this work, a user has to manually set the `OLLAMA_ORIGINS` flag. This is way too much to ask from a regular user. (I would argue even an Ollama regular user.) So while I agree that opening up Ollama to any web page is not what we want, I'm wondering if there is a secure and easy way to make access from a Chrome extension work. I'm thinking in the direction of integrating API_KEY functionality with the Ollama REST interface. Alternatively, there could be a popup if an unknown origin queries Ollama. Then, the user could accept or deny the request. What do you think? Are there already any efforts in either of these directions?
GiteaMirror commented 2026-04-22 05:37:59 -05:00
Author
Owner
Copy Link

@erhhung commented on GitHub (Oct 27, 2024):

@matthiasgeihs Ollama being, at this point, NOT yet a turnkey desktop app but a CLI app, IMO having to provide some instructions to users to set the OLLAMA_ORIGINS environment variable before launch should they want to use your Chrome extension with their locally hosted Ollama endpoint isn't too much to ask, like:

OLLAMA_ORIGINS="chrome-extension://abcdefghijklmnopqrstuvwxy" ollama serve

That said, having to set that variable each time to an unmemorable chrome-extension URL is certainly not ideal. I would push the community here to get the sought-after "config file" feature (see #7089 for example) implemented that includes setting defaults for all supported environment variables (ollama serve --help) while values actually defined in the environment should override those in the config file.

Then a one-time addition of your chrome-extension URL into the config file would be less painful.

As for implementing "proper" authentication directly into Ollama core, I doubt that would get much traction as there are so many ways to implement authn & authz that I would think wrapper applications to proxy Ollama REST API calls, or sidecars (as in service mesh), or an Ollama-supported plugin framework would be the best ways to support it.

Anyway, given that this issue is closed, I'd create a new discussion or push for existing requests.

<!-- gh-comment-id:2440219886 --> @erhhung commented on GitHub (Oct 27, 2024): @matthiasgeihs Ollama being, at this point, NOT yet a turnkey desktop app but a CLI app, IMO having to provide some instructions to users to set the `OLLAMA_ORIGINS` environment variable before launch should they want to use your Chrome extension with their locally hosted Ollama endpoint isn't too much to ask, like: ```bash OLLAMA_ORIGINS="chrome-extension://abcdefghijklmnopqrstuvwxy" ollama serve ``` That said, having to set that variable each time to an unmemorable `chrome-extension` URL is certainly not ideal. I would push the community here to get the sought-after "config file" feature (see #7089 for example) implemented that includes setting **defaults** for all supported environment variables (`ollama serve --help`) while values actually defined in the environment should override those in the config file. Then a one-time addition of your `chrome-extension` URL into the config file would be less painful. As for implementing "proper" authentication directly into Ollama core, I doubt that would get much traction as there are so many ways to implement authn & authz that I would think wrapper applications to **proxy** Ollama REST API calls, or sidecars (as in service mesh), or an Ollama-supported **plugin** framework would be the best ways to support it. Anyway, given that this issue is closed, I'd create a new discussion or push for existing requests.
GiteaMirror commented 2026-04-22 05:37:59 -05:00
Author
Owner
Copy Link

@matthiasgeihs commented on GitHub (Oct 28, 2024):

@erhhung thanks for discussing this with me. i think i got a bunch of insights from your explanations. agreed that the config file option might be a good middle ground. (even for me as a developer, it's currently a bit annoying to have to manually start the ollama with the right flags every time i want to work on the project.) and yeah, opening a new discussion around that would eventually be the right thing to do. for now, i'm satisfied with the outcome. thank you.

<!-- gh-comment-id:2441000725 --> @matthiasgeihs commented on GitHub (Oct 28, 2024): @erhhung thanks for discussing this with me. i think i got a bunch of insights from your explanations. agreed that the config file option might be a good middle ground. (even for me as a developer, it's currently a bit annoying to have to manually start the ollama with the right flags every time i want to work on the project.) and yeah, opening a new discussion around that would eventually be the right thing to do. for now, i'm satisfied with the outcome. thank you.
GiteaMirror commented 2026-04-22 05:38:00 -05:00
Author
Owner
Copy Link

@clearsitedesigns commented on GitHub (Jul 13, 2025):

Why cant there be an option to just turn this on since I start the app on my mac - just let me flip a switch

<!-- gh-comment-id:3066330853 --> @clearsitedesigns commented on GitHub (Jul 13, 2025): Why cant there be an option to just turn this on since I start the app on my mac - just let me flip a switch
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
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#27963
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?