[GH-ISSUE #8100] After upgrading from 0.4.8 to 0.5.1 api key authentication is not working #53664

New Issue

GiteaMirror · 2026-05-05T15:06:33-05:00

GiteaMirror commented

2026-05-05 15:06:33 -05:00

Originally created by @df-cgdm on GitHub (Dec 26, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/8100

Bug Report

Installation Method

Docker

Environment

Open WebUI 0.5.1

Confirmation:

I have read and followed all the instructions provided in the README.md.
I am on the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

Expected Behavior:

When I'm calling the API (ollama or openai endpoints) with the API key it should accept it

Actual Behavior:

I get a 403 with the following detail

{
  "detail": "Use of API key is not enabled in the environment."
}

Description

Bug Summary:
Even if ENABLE_API_KEY is True the api_key is not accepted any more.

Reproduction Details

Steps to Reproduce:
1/ Install the version 0.4.8 enable the API Key Auth.
2/ Any call to the api using the API key is working
3/ Upgrade to version 0.5.1
4/ Verify in the Admin UI that Enable API Key Auth is still enabled
5/ Any call to the api using the API key is receiving a 403 "Use of API key is not enabled in the environment."

Logs and Screenshots

Docker Container Logs:
NFO: 10.62.42.19:0 - "GET /openai/models HTTP/1.1" 403 Forbidden

Screenshots/Screen Recordings (if applicable):

Additional Information

For what I've seen this is related to this commit
a2366a20ba

Originally created by @df-cgdm on GitHub (Dec 26, 2024). Original GitHub issue: https://github.com/open-webui/open-webui/issues/8100 # Bug Report ## Installation Method Docker ## Environment - Open WebUI 0.5.1 **Confirmation:** - [X] I have read and followed all the instructions provided in the README.md. - [X] I am on the latest version of both Open WebUI and Ollama. - [ ] I have included the browser console logs. - [X] I have included the Docker container logs. - [X] I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below. ## Expected Behavior: When I'm calling the API (ollama or openai endpoints) with the API key it should accept it ## Actual Behavior: I get a 403 with the following detail ``` { "detail": "Use of API key is not enabled in the environment." } ``` ## Description **Bug Summary:** Even if ENABLE_API_KEY is True the api_key is not accepted any more. ## Reproduction Details **Steps to Reproduce:** 1/ Install the version 0.4.8 enable the API Key Auth. 2/ Any call to the api using the API key is working 3/ Upgrade to version 0.5.1 4/ Verify in the Admin UI that Enable API Key Auth is still enabled 5/ Any call to the api using the API key is receiving a 403 "Use of API key is not enabled in the environment." ## Logs and Screenshots **Docker Container Logs:** NFO: 10.62.42.19:0 - "GET /openai/models HTTP/1.1" 403 Forbidden **Screenshots/Screen Recordings (if applicable):** ![API call ScreenShot](https://github.com/user-attachments/assets/21e75dea-04e2-4d62-8447-4ab8ab83b6a9) ## Additional Information For what I've seen this is related to this commit https://github.com/open-webui/open-webui/commit/a2366a20ba9e2fa0ec525b7ff586a4f7d9450833

GiteaMirror closed this issue

2026-05-05 15:06:34 -05:00

GiteaMirror commented

2026-05-05 15:06:37 -05:00

@rchaklashiya commented on GitHub (Dec 26, 2024):

I'm having a similar issue. In the updated 5.1 version I cannot upload pdf's by API via python (I am getting a 405 Error, {"detail":"Method Not Allowed"}). Meanwhile doing queries via API via python still works for me. So it seems like it's related to the commit you mentioned, as the pdf upload is govered by ''/api/v1/files' which does not appear to be in the allowed list for 5.1, meanwhile queries are under '/v1/chat/completions' which is allowed in 5.1.
I still need to try an older version of Open Web UI to doublecheck (not that experienced with downgrading so am struggling a bit on that end)

@rchaklashiya commented on GitHub (Dec 26, 2024): I'm having a similar issue. In the updated 5.1 version I cannot upload pdf's by API via python (I am getting a 405 Error, {"detail":"Method Not Allowed"}). Meanwhile doing queries via API via python still works for me. So it seems like it's related to the commit you mentioned, as the pdf upload is govered by ''/api/v1/files' which does not appear to be in the allowed list for 5.1, meanwhile queries are under '/v1/chat/completions' which is allowed in 5.1. I still need to try an older version of Open Web UI to doublecheck (not that experienced with downgrading so am struggling a bit on that end)

GiteaMirror commented

2026-05-05 15:06:38 -05:00

@ghmer commented on GitHub (Dec 26, 2024):

Me too. Cannot access the ollama backend via open-webui at all. Please fix!

@ghmer commented on GitHub (Dec 26, 2024): Me too. Cannot access the ollama backend via open-webui at all. Please fix!

GiteaMirror commented

2026-05-05 15:06:39 -05:00

@yanismiraoui commented on GitHub (Dec 26, 2024):

Me too, having a lot issues since update.

@yanismiraoui commented on GitHub (Dec 26, 2024): Me too, having a lot issues since update.

GiteaMirror commented

2026-05-05 15:06:40 -05:00

@rchaklashiya commented on GitHub (Dec 26, 2024):

I'm having a similar issue. In the updated 5.1 version I cannot upload pdf's by API via python (I am getting a 405 Error, {"detail":"Method Not Allowed"}). Meanwhile doing queries via API via python still works for me. So it seems like it's related to the commit you mentioned, as the pdf upload is govered by ''/api/v1/files' which does not appear to be in the allowed list for 5.1, meanwhile queries are under '/v1/chat/completions' which is allowed in 5.1. I still need to try an older version of Open Web UI to doublecheck (not that experienced with downgrading so am struggling a bit on that end)

Update on this: I downgraded to 0.4.8 to doublecheck what was going on, and there the issue is different (a 422 error, {"detail":[{"type":"missing","loc":["body","file"],"msg":"Field required","input":null}]},

However, I checked my code and noticed the mistake, I was using 'Content-Type' in my headers dictionary instead of 'Accept'.

Once I fixed that, the pdf uploaded properly (albeit it did so while giving a "'NoneType' object is not iterable" error, so there is still something wrong, which I am in the process of trying to figure out now).

I'm not sure if I want to try this on 0.5.1 just yet, as the error is very different there, and based on the commit given by OP I think the issue is probably more fundamental in that version at the present moment.

@rchaklashiya commented on GitHub (Dec 26, 2024): > I'm having a similar issue. In the updated 5.1 version I cannot upload pdf's by API via python (I am getting a 405 Error, {"detail":"Method Not Allowed"}). Meanwhile doing queries via API via python still works for me. So it seems like it's related to the commit you mentioned, as the pdf upload is govered by ''/api/v1/files' which does not appear to be in the allowed list for 5.1, meanwhile queries are under '/v1/chat/completions' which is allowed in 5.1. I still need to try an older version of Open Web UI to doublecheck (not that experienced with downgrading so am struggling a bit on that end) Update on this: I downgraded to 0.4.8 to doublecheck what was going on, and there the issue is different (a 422 error, {"detail":[{"type":"missing","loc":["body","file"],"msg":"Field required","input":null}]}, However, I checked my code and noticed the mistake, I was using 'Content-Type' in my headers dictionary instead of 'Accept'. Once I fixed that, the pdf uploaded properly (albeit it did so while giving a "'NoneType' object is not iterable" error, so there is still something wrong, which I am in the process of trying to figure out now). I'm not sure if I want to try this on 0.5.1 just yet, as the error is very different there, and based on the commit given by OP I think the issue is probably more fundamental in that version at the present moment.

GiteaMirror commented

2026-05-05 15:06:41 -05:00

@AzizDXT commented on GitHub (Dec 26, 2024):

I am unable to upload a file, unfortunately, nor access knowledge at all!

@AzizDXT commented on GitHub (Dec 26, 2024): I am unable to upload a file, unfortunately, nor access knowledge at all!

GiteaMirror commented

2026-05-05 15:06:45 -05:00

@rchaklashiya commented on GitHub (Dec 26, 2024):

I'm having a similar issue. In the updated 5.1 version I cannot upload pdf's by API via python (I am getting a 405 Error, {"detail":"Method Not Allowed"}). Meanwhile doing queries via API via python still works for me. So it seems like it's related to the commit you mentioned, as the pdf upload is govered by ''/api/v1/files' which does not appear to be in the allowed list for 5.1, meanwhile queries are under '/v1/chat/completions' which is allowed in 5.1. I still need to try an older version of Open Web UI to doublecheck (not that experienced with downgrading so am struggling a bit on that end)

Update on this: I downgraded to 0.4.8 to doublecheck what was going on, and there the issue is different (a 422 error, {"detail":[{"type":"missing","loc":["body","file"],"msg":"Field required","input":null}]},

However, I checked my code and noticed the mistake, I was using 'Content-Type' in my headers dictionary instead of 'Accept'.

Once I fixed that, the pdf uploaded properly (albeit it did so while giving a "'NoneType' object is not iterable" error, so there is still something wrong, which I am in the process of trying to figure out now).

I'm not sure if I want to try this on 0.5.1 just yet, as the error is very different there, and based on the commit given by OP I think the issue is probably more fundamental in that version at the present moment.

Just now I'm realizing that downgrading also purged my models...and also made me unable to upload any more models :/
I'm going to upgrade to 0.5.1 again and see if that fixes that.

@rchaklashiya commented on GitHub (Dec 26, 2024): > > I'm having a similar issue. In the updated 5.1 version I cannot upload pdf's by API via python (I am getting a 405 Error, {"detail":"Method Not Allowed"}). Meanwhile doing queries via API via python still works for me. So it seems like it's related to the commit you mentioned, as the pdf upload is govered by ''/api/v1/files' which does not appear to be in the allowed list for 5.1, meanwhile queries are under '/v1/chat/completions' which is allowed in 5.1. I still need to try an older version of Open Web UI to doublecheck (not that experienced with downgrading so am struggling a bit on that end) > > Update on this: I downgraded to 0.4.8 to doublecheck what was going on, and there the issue is different (a 422 error, {"detail":[{"type":"missing","loc":["body","file"],"msg":"Field required","input":null}]}, > > However, I checked my code and noticed the mistake, I was using 'Content-Type' in my headers dictionary instead of 'Accept'. > > Once I fixed that, the pdf uploaded properly (albeit it did so while giving a "'NoneType' object is not iterable" error, so there is still something wrong, which I am in the process of trying to figure out now). > > I'm not sure if I want to try this on 0.5.1 just yet, as the error is very different there, and based on the commit given by OP I think the issue is probably more fundamental in that version at the present moment. Just now I'm realizing that downgrading also purged my models...and also made me unable to upload any more models :/ I'm going to upgrade to 0.5.1 again and see if that fixes that.

GiteaMirror commented

2026-05-05 15:06:47 -05:00

@rchaklashiya commented on GitHub (Dec 26, 2024):

I'm having a similar issue. In the updated 5.1 version I cannot upload pdf's by API via python (I am getting a 405 Error, {"detail":"Method Not Allowed"}). Meanwhile doing queries via API via python still works for me. So it seems like it's related to the commit you mentioned, as the pdf upload is govered by ''/api/v1/files' which does not appear to be in the allowed list for 5.1, meanwhile queries are under '/v1/chat/completions' which is allowed in 5.1. I still need to try an older version of Open Web UI to doublecheck (not that experienced with downgrading so am struggling a bit on that end)

Update on this: I downgraded to 0.4.8 to doublecheck what was going on, and there the issue is different (a 422 error, {"detail":[{"type":"missing","loc":["body","file"],"msg":"Field required","input":null}]},
However, I checked my code and noticed the mistake, I was using 'Content-Type' in my headers dictionary instead of 'Accept'.
Once I fixed that, the pdf uploaded properly (albeit it did so while giving a "'NoneType' object is not iterable" error, so there is still something wrong, which I am in the process of trying to figure out now).
I'm not sure if I want to try this on 0.5.1 just yet, as the error is very different there, and based on the commit given by OP I think the issue is probably more fundamental in that version at the present moment.

Just now I'm realizing that downgrading also purged my models...and also made me unable to upload any more models :/ I'm going to upgrade to 0.5.1 again and see if that fixes that.

I upgraded to 0.5.1 and that gave me back my models.

I tested out uploading a PDF via API in python with my fix that worked in 0.4.8 and I'm still getting a Error: 405, {"detail":"Method Not Allowed"}, which I think means that the commit issue is the culprit here.

**Update: Actually, reading through the commit, I realized that it doesn't involve a 405 error nor does it involve the error message I encountered--which leads me to think there is another issue somewhere else in Open Web UI's code (wherever a 405 error is mentioned). I'm looking for it now.

@rchaklashiya commented on GitHub (Dec 26, 2024): > > > I'm having a similar issue. In the updated 5.1 version I cannot upload pdf's by API via python (I am getting a 405 Error, {"detail":"Method Not Allowed"}). Meanwhile doing queries via API via python still works for me. So it seems like it's related to the commit you mentioned, as the pdf upload is govered by ''/api/v1/files' which does not appear to be in the allowed list for 5.1, meanwhile queries are under '/v1/chat/completions' which is allowed in 5.1. I still need to try an older version of Open Web UI to doublecheck (not that experienced with downgrading so am struggling a bit on that end) > > > > > > Update on this: I downgraded to 0.4.8 to doublecheck what was going on, and there the issue is different (a 422 error, {"detail":[{"type":"missing","loc":["body","file"],"msg":"Field required","input":null}]}, > > However, I checked my code and noticed the mistake, I was using 'Content-Type' in my headers dictionary instead of 'Accept'. > > Once I fixed that, the pdf uploaded properly (albeit it did so while giving a "'NoneType' object is not iterable" error, so there is still something wrong, which I am in the process of trying to figure out now). > > I'm not sure if I want to try this on 0.5.1 just yet, as the error is very different there, and based on the commit given by OP I think the issue is probably more fundamental in that version at the present moment. > > Just now I'm realizing that downgrading also purged my models...and also made me unable to upload any more models :/ I'm going to upgrade to 0.5.1 again and see if that fixes that. I upgraded to 0.5.1 and that gave me back my models. I tested out uploading a PDF via API in python with my fix that worked in 0.4.8 and I'm still getting a Error: 405, {"detail":"Method Not Allowed"}, which I think means that the commit issue is the culprit here. **Update: Actually, reading through the commit, I realized that it doesn't involve a 405 error nor does it involve the error message I encountered--which leads me to think there is another issue somewhere else in Open Web UI's code (wherever a 405 error is mentioned). I'm looking for it now.

GiteaMirror commented

2026-05-05 15:06:50 -05:00

@tjbck commented on GitHub (Dec 26, 2024):

Please read the changelogs before updating. JWT should be used in this case instead of API keys.

@tjbck commented on GitHub (Dec 26, 2024): Please read the changelogs before updating. JWT should be used in this case instead of API keys.

GiteaMirror commented

2026-05-05 15:06:51 -05:00

@ProjectMoon commented on GitHub (Dec 26, 2024):

There isn't anything about JWT in the change log. Was it a missed patch note?

@ProjectMoon commented on GitHub (Dec 26, 2024): There isn't anything about JWT in the change log. Was it a missed patch note?

GiteaMirror commented

2026-05-05 15:06:53 -05:00

@tjbck commented on GitHub (Dec 26, 2024):

Related: https://github.com/open-webui/open-webui/pull/7322
cc @DmitriyAlergant-T1A

@tjbck commented on GitHub (Dec 26, 2024): ![image](https://github.com/user-attachments/assets/a67a8423-f4b3-4384-8819-55fc4a0461c1) Related: https://github.com/open-webui/open-webui/pull/7322 cc @DmitriyAlergant-T1A

GiteaMirror commented

2026-05-05 15:06:54 -05:00

@ProjectMoon commented on GitHub (Dec 26, 2024):

I mean, I saw that note, yes. But it doesn't explain that JWTs are now in use or how to get them. I'll look at the PR though.

@ProjectMoon commented on GitHub (Dec 26, 2024): I mean, I saw that note, yes. But it doesn't explain that JWTs are now in use or how to get them. I'll look at the PR though.

GiteaMirror commented

2026-05-05 15:06:56 -05:00

@tjbck commented on GitHub (Dec 26, 2024):

@ProjectMoon JWT should work as a drop in replacement!

@tjbck commented on GitHub (Dec 26, 2024): @ProjectMoon JWT should work as a drop in replacement! ![image](https://github.com/user-attachments/assets/b08197f5-64ac-4c78-b046-d3e21dc97251)

GiteaMirror commented

2026-05-05 15:06:57 -05:00

@ProjectMoon commented on GitHub (Dec 26, 2024):

I mean, I saw that note, yes. But it doesn't explain that JWTs are now in use or how to get them. I'll look at the PR though.

@ProjectMoon JWT should work as a drop in replacement!

That works perfectly, thanks!

@ProjectMoon commented on GitHub (Dec 26, 2024): I mean, I saw that note, yes. But it doesn't explain that JWTs are now in use or how to get them. I'll look at the PR though. > @ProjectMoon JWT should work as a drop in replacement! > > ![image](https://private-user-images.githubusercontent.com/25473318/398801750-b08197f5-64ac-4c78-b046-d3e21dc97251.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzUyNDcxNDYsIm5iZiI6MTczNTI0Njg0NiwicGF0aCI6Ii8yNTQ3MzMxOC8zOTg4MDE3NTAtYjA4MTk3ZjUtNjRhYy00Yzc4LWIwNDYtZDNlMjFkYzk3MjUxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDEyMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQxMjI2VDIxMDA0NlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTY5M2RjZjI3Yzc3NGIxNmM0MTFlZWQ1YTA4OWUzMGM3YjU2MTA0MzU5ODdhZGU1ODdlYTYwZWQ2ZTBjN2UzY2ImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.0NZSnlvqhpJ0ZGHJ2K7VjKt-M_PA-jAQoEBBFQYjfhs) That works perfectly, thanks!

GiteaMirror commented

2026-05-05 15:06:58 -05:00

@DmitriyAlergant commented on GitHub (Dec 26, 2024):

Keep in mind that JWTs reset on any app restart. Also they may have limited expiration date (if enabled in admin general settings).

Ideally you are supposed to get fresh JWTs ad-hoc via a /signin call.

@DmitriyAlergant commented on GitHub (Dec 26, 2024): Keep in mind that JWTs reset on any app restart. Also they may have limited expiration date (if enabled in admin general settings). Ideally you are supposed to get fresh JWTs ad-hoc via a /signin call.

GiteaMirror commented

2026-05-05 15:06:58 -05:00

@ProjectMoon commented on GitHub (Dec 26, 2024):

Hmmm. Part of the problem, I think, is that the changes have locked down the entirety of the proxied ollama API. Wouldn't it make sense to allow API key access to similar completion/model list endpoints on the proxied APIs?

@ProjectMoon commented on GitHub (Dec 26, 2024): Hmmm. Part of the problem, I think, is that the changes have locked down the entirety of the proxied ollama API. Wouldn't it make sense to allow API key access to similar completion/model list endpoints on the proxied APIs?

GiteaMirror commented

2026-05-05 15:06:59 -05:00

@DmitriyAlergant commented on GitHub (Dec 26, 2024):

I think so... the spirit of the original PR was to limit API access to chat completion endpoints, to minimize security exposure for prone-to-leakage and non-expiring API keys.

if Ollama completion endpoints are different they should be included as well...

@DmitriyAlergant commented on GitHub (Dec 26, 2024): I think so... the spirit of the original PR was to limit API access to chat completion endpoints, to minimize security exposure for prone-to-leakage and non-expiring API keys. if Ollama completion endpoints are different they should be included as well...

GiteaMirror commented

2026-05-05 15:07:00 -05:00

@ProjectMoon commented on GitHub (Dec 26, 2024):

They are indeed different. It's a whole separate router within the application.

@ProjectMoon commented on GitHub (Dec 26, 2024): They are indeed different. It's a whole separate router within the application.

GiteaMirror commented

2026-05-05 15:07:02 -05:00

@ghmer commented on GitHub (Dec 26, 2024):

Keep in mind that JWTs reset on any app restart. Also they may have limited expiration date (if enabled in admin general settings).

Ideally you are supposed to get fresh JWTs ad-hoc via a /signin call.

Well, imho the purpose of an API key is to get rid of interactive logins. I mean, if the /signin was issuing a JWT when supplying a valid API key, this was probably a valid scenario, but right now, afaik this is not the case. Also, the exposed endpoints available with API keys do not offer the same features as, for example, the Ollama endpoint does (adding images, anyone?).

I don't get the idea behind this at all - with other tools, I can have many API keys, and I can limit what those API keys can do. These are independent from my login, and if I want to revoke one, I can just do so without an impact on my other keys.

The current approach

only have one API key
limit this API key to endpoints that don't provide much functionality besides just the chat completion AND
use a JWT that changes at least on every server restart

renders open-webui as the API middleware pretty unattractive. Please revert (or better, extend!)

@ghmer commented on GitHub (Dec 26, 2024): > Keep in mind that JWTs reset on any app restart. Also they may have limited expiration date (if enabled in admin general settings). > > Ideally you are supposed to get fresh JWTs ad-hoc via a /signin call. Well, imho the purpose of an API key is to get rid of interactive logins. I mean, if the /signin was issuing a JWT when supplying a valid API key, this was probably a valid scenario, but right now, afaik this is not the case. Also, the exposed endpoints available with API keys do not offer the same features as, for example, the Ollama endpoint does (adding images, anyone?). I don't get the idea behind this at all - with other tools, I can have many API keys, and I can limit what those API keys can do. These are independent from my login, and if I want to revoke one, I can just do so without an impact on my other keys. The current approach - only have one API key - limit this API key to endpoints that don't provide much functionality besides just the chat completion AND - use a JWT that changes at least on every server restart renders open-webui as the API middleware pretty unattractive. Please revert (or better, extend!)

GiteaMirror commented

2026-05-05 15:07:03 -05:00

@tjbck commented on GitHub (Dec 26, 2024):

@ghmer Agreed, let's make this an opt-in option from the admin settings. 0.5.2 with changes will be pushed shortly!

@tjbck commented on GitHub (Dec 26, 2024): @ghmer Agreed, let's make this an opt-in option from the admin settings. 0.5.2 with changes will be pushed shortly!

GiteaMirror commented

2026-05-05 15:07:05 -05:00

@DmitriyAlergant commented on GitHub (Dec 26, 2024):

@tjbck there are still two separate things here:

overall opt-in status for API Key restrictions (new behavior vs legacy behavior)
the list of allowed endpoints in the new "restricted" behavior should be bigger then those 2 originally suggested, and should include OLLama completion endpoints.

@DmitriyAlergant commented on GitHub (Dec 26, 2024): @tjbck there are still two separate things here: - overall opt-in status for API Key restrictions (new behavior vs legacy behavior) - the list of allowed endpoints in the new "restricted" behavior should be bigger then those 2 originally suggested, and should include OLLama completion endpoints.

GiteaMirror commented

2026-05-05 15:07:06 -05:00

@ghmer commented on GitHub (Dec 26, 2024):

@tjbck there are still two separate things here:

* overall opt-in status for API Key restrictions (new behavior vs legacy behavior)

* the list of allowed endpoints in the new "restricted" behavior should be bigger then those 2 originally suggested, and should include OLLama completion endpoints.

@DmitriyAlergant-T1A @tjbck

I mean, if you are reworking 2nd one, why not make the endpoints configurable, too? In a first step, enabling API keys and then having a list of endpoints to grant access to that you can check or uncheck seems straight forward. This could later then be extended in a "config per api key", so one API key could indeed be used to do admin tasks, while another one could give access to the complete ollama backend, while a third one only allows access to open-webui's chat/completions endpoint.

@ghmer commented on GitHub (Dec 26, 2024): > @tjbck there are still two separate things here: > > * overall opt-in status for API Key restrictions (new behavior vs legacy behavior) > > * the list of allowed endpoints in the new "restricted" behavior should be bigger then those 2 originally suggested, and should include OLLama completion endpoints. @DmitriyAlergant-T1A @tjbck I mean, _if_ you are reworking 2nd one, why not make the endpoints configurable, too? In a first step, enabling API keys and then having a list of endpoints to grant access to that you can check or uncheck seems straight forward. This could later then be extended in a "config per api key", so one API key could indeed be used to do admin tasks, while another one could give access to the complete ollama backend, while a third one only allows access to open-webui's chat/completions endpoint.

GiteaMirror commented

2026-05-05 15:07:08 -05:00

@tjbck commented on GitHub (Dec 27, 2024):

Added to dev!

@tjbck commented on GitHub (Dec 27, 2024): Added to dev! ![image](https://github.com/user-attachments/assets/ad6f1e9e-89e5-44f8-8281-ac348ce93cf1)

GiteaMirror commented

2026-05-05 15:07:12 -05:00

@DmitriyAlergant commented on GitHub (Dec 27, 2024):

@tjbck Thanks for going above and beyond, even with the configuration change.

Just one last ask... Can you put in there some sensible defaults, that we can recommend security-conscious users to restrict endpoints? Like as per the original implementation: /api/v1/models, /api/v1/chat/completions + similar Ollama endpoints that I was not fully aware of.

There is only one shot to add defaults, before the users complete the upgrade...

Thanks!

@DmitriyAlergant commented on GitHub (Dec 27, 2024): @tjbck Thanks for going above and beyond, even with the configuration change. Just one last ask... Can you put in there some sensible defaults, that we can recommend security-conscious users to restrict endpoints? Like as per the original implementation: /api/v1/models, /api/v1/chat/completions + similar Ollama endpoints that I was not fully aware of. There is only one shot to add defaults, before the users complete the upgrade... Thanks!

GiteaMirror commented

2026-05-05 15:07:14 -05:00

@ProjectMoon commented on GitHub (Dec 27, 2024):

Getting this on 0.5.2, even after toggling and saving the admin settings a few times.

AttributeError: 'State' object has no attribute 'ENABLE_API_KEY_ENDPOINT_RESTRICTIONS'

@ProjectMoon commented on GitHub (Dec 27, 2024): Getting this on 0.5.2, even after toggling and saving the admin settings a few times. ``` AttributeError: 'State' object has no attribute 'ENABLE_API_KEY_ENDPOINT_RESTRICTIONS' ```

GiteaMirror commented

2026-05-05 15:07:17 -05:00

@tjbck commented on GitHub (Dec 27, 2024):

Fixed with https://github.com/open-webui/open-webui/pull/8131

@tjbck commented on GitHub (Dec 27, 2024): Fixed with https://github.com/open-webui/open-webui/pull/8131

GiteaMirror commented

2026-05-05 15:07:19 -05:00

@deepsidhu1313 commented on GitHub (Dec 27, 2025):

recently upgraded image ghcr.io/open-webui/open-webui:ollama to latest and api calls have stopped working.

For non admin user API option doen't appear in settings, there is no way to retrieve api key.
Copy button is broken
Using api key from admin account, received {"detail":"Use of API key is not enabled in the environment."}, then followed steps from above, enable api key usage and added allowed urls /api/v1/models, /api/v1/chat/completions, /ollama/api/generate, /ollama/api/tags, /ollama/api/embed, /api/v1/files/, /api/v1/knowledge/{id}/file/add, but still receiving API key not allowed to access this endpoint.

curl -X POST http://localhost:3000/api/chat/completions \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
      "model": "llama3.1",
      "messages": [
        {
          "role": "user",
          "content": "Why is the sky blue?"
        }
      ]
    }'

any ideas ?

@deepsidhu1313 commented on GitHub (Dec 27, 2025): recently upgraded image `ghcr.io/open-webui/open-webui:ollama` to latest and api calls have stopped working. 1. For non admin user API option doen't appear in settings, there is no way to retrieve api key. 2. Copy button is broken 3. Using api key from admin account, received `{"detail":"Use of API key is not enabled in the environment."}`, then followed steps from above, enable api key usage and added allowed urls `/api/v1/models, /api/v1/chat/completions, /ollama/api/generate, /ollama/api/tags, /ollama/api/embed, /api/v1/files/, /api/v1/knowledge/{id}/file/add`, but still receiving `API key not allowed to access this endpoint.` ``` curl -X POST http://localhost:3000/api/chat/completions \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "llama3.1", "messages": [ { "role": "user", "content": "Why is the sky blue?" } ] }' ``` any ideas ?

GiteaMirror commented

2026-05-05 15:07:20 -05:00

@ThomasFeustel commented on GitHub (Dec 29, 2025):

Sorry for german screenshot. Did you tried to enable API in Settings? I assume, the old environment-parameter was moved ...
(Administration => Settings => General => Enable API)

@ThomasFeustel commented on GitHub (Dec 29, 2025): Sorry for german screenshot. Did you tried to enable API in Settings? I assume, the old environment-parameter was moved ... (Administration => Settings => General => Enable API) <img width="1209" height="543" alt="Image" src="https://github.com/user-attachments/assets/5e907a7e-446d-4c74-a1c4-ec5d83a8bba7" />

GiteaMirror commented

2026-05-05 15:07:21 -05:00

@deepsidhu1313 commented on GitHub (Dec 30, 2025):

No worries, i think i got it working by turning off allowed urls setting. But still not sure how to make enable api setting and API key appear for non admin account.

@deepsidhu1313 commented on GitHub (Dec 30, 2025): No worries, i think i got it working by turning off allowed urls setting. But still not sure how to make enable api setting and API key appear for non admin account.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#53664