Originally created by @JoeLudwig on GitHub (Apr 25, 2025).
Check Existing Issues
I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
0.6.5
Ollama Version (if applicable)
No response
Operating System
Debian 12
Browser (if applicable)
No response
Confirmation
I have read and followed all instructions in README.md.
I am using 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 listed steps to reproduce the bug in detail.
Expected Behavior
Oauth SSO completes in a timely manner. It pulls profile images from the Oauth provider, using the proxy server specified in the environment.
Actual Behavior
Open WebUI attempts to connect directly to the profile picture provider, and that connection times out after a while. This causes unfortunate behavior in the UI that makes it look like the sign in failed, even though it kind of succeeded. Do this enough times, and eventually you will be signed in.
Steps to Reproduce
There are two calls to aiohttp.ClientSession() inside oauth.py what do not pass trust_env=True into the constructor. That causes the session to not respect the proxy settings in the environment, so if your server happens to be in an environment that requires a proxy to talk to the internet, the requests for profile pictures will time out. There are other constructor calls to for that class which also don't pass trust_env-True. I did not audit all of them to determine if those other calls also represent bugs.
We happen to use Microsoft SSO, but the bug doesn't appear to be Microsoft-specific and will likely occur any time you run behind a proxy server and use SSO.
Originally created by @JoeLudwig on GitHub (Apr 25, 2025).
### Check Existing Issues
- [x] I have searched the existing issues and discussions.
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
0.6.5
### Ollama Version (if applicable)
_No response_
### Operating System
Debian 12
### Browser (if applicable)
_No response_
### Confirmation
- [x] I have read and followed all instructions in `README.md`.
- [x] I am using the latest version of **both** Open WebUI and Ollama.
- [x] I have included the browser console logs.
- [x] I have included the Docker container logs.
- [x] I have listed steps to reproduce the bug in detail.
### Expected Behavior
Oauth SSO completes in a timely manner. It pulls profile images from the Oauth provider, using the proxy server specified in the environment.
### Actual Behavior
Open WebUI attempts to connect directly to the profile picture provider, and that connection times out after a while. This causes unfortunate behavior in the UI that makes it look like the sign in failed, even though it kind of succeeded. Do this enough times, and eventually you will be signed in.
### Steps to Reproduce
There are two calls to `aiohttp.ClientSession()` inside oauth.py what do not pass `trust_env=True` into the constructor. That causes the session to not respect the proxy settings in the environment, so if your server happens to be in an environment that requires a proxy to talk to the internet, the requests for profile pictures will time out. There are other constructor calls to for that class which also don't pass `trust_env-True`. I did not audit all of them to determine if those other calls also represent bugs.
We happen to use Microsoft SSO, but the bug doesn't appear to be Microsoft-specific and will likely occur any time you run behind a proxy server and use SSO.
### Logs & Screenshots
2025-04-25 20:35:12.806 | ERROR | open_webui.utils.oauth:handle_callback:361 - Error downloading profile image 'https://graph.microsoft.com/v1.0/me/photo/$value': Connection timeout to host https://graph.microsoft.com/v1.0/me/photo/$value - {}
### Additional Information
_No response_
GiteaMirror
added the bug label 2025-11-11 16:08:14 -06:00
Should be addressed with 7d0a78a43a based on your issue description, if not resolved PR welcome.
@tjbck commented on GitHub (Apr 28, 2025):
Should be addressed with 7d0a78a43a664dfc16a039424ce4a05960ec4655 based on your issue description, if not resolved PR welcome.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @JoeLudwig on GitHub (Apr 25, 2025).
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.6.5
Ollama Version (if applicable)
No response
Operating System
Debian 12
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
Oauth SSO completes in a timely manner. It pulls profile images from the Oauth provider, using the proxy server specified in the environment.
Actual Behavior
Open WebUI attempts to connect directly to the profile picture provider, and that connection times out after a while. This causes unfortunate behavior in the UI that makes it look like the sign in failed, even though it kind of succeeded. Do this enough times, and eventually you will be signed in.
Steps to Reproduce
There are two calls to
aiohttp.ClientSession()inside oauth.py what do not passtrust_env=Trueinto the constructor. That causes the session to not respect the proxy settings in the environment, so if your server happens to be in an environment that requires a proxy to talk to the internet, the requests for profile pictures will time out. There are other constructor calls to for that class which also don't passtrust_env-True. I did not audit all of them to determine if those other calls also represent bugs.We happen to use Microsoft SSO, but the bug doesn't appear to be Microsoft-specific and will likely occur any time you run behind a proxy server and use SSO.
Logs & Screenshots
2025-04-25 20:35:12.806 | ERROR | open_webui.utils.oauth:handle_callback:361 - Error downloading profile image 'https://graph.microsoft.com/v1.0/me/photo/$value': Connection timeout to host https://graph.microsoft.com/v1.0/me/photo/$value - {}
Additional Information
No response
@tjbck commented on GitHub (Apr 28, 2025):
Should be addressed with
7d0a78a43abased on your issue description, if not resolved PR welcome.@JoeLudwig commented on GitHub (Apr 29, 2025):
Looks great to me. Thanks!