Originally created by @ghost on GitHub (Apr 11, 2024).
Is your feature request related to a problem? Please describe.
The current in-app update check polls the generic GitHub API which can be problematic to approve (and permit firewall network access to) in restrictive enterprise environments. From a security perspective, this can be undesirable since threat actors are known to abuse GitHub for malicious purpose.
Describe the solution you'd like
I'd like to see a dedicated GitHub domain and associated project-controlled host-name, perhaps: update.openwebui.com, deployed to replace api.github.com for the in-app update check. One possible solution could be to use a GitHub Action with a process like push-directory-to-another-repository to generate JSON output and push it to an "update" project. The application client code could then point to https://update.openwebui.com/release.json (or something) to pull the JSON containing the relevant release version metadata.
Originally created by @ghost on GitHub (Apr 11, 2024).
**Is your feature request related to a problem? Please describe.**
The current in-app update check polls the generic GitHub API which can be problematic to approve (and permit firewall network access to) in restrictive enterprise environments. From a security perspective, this can be undesirable since threat actors are known to abuse GitHub for malicious purpose.
**Describe the solution you'd like**
I'd like to see a dedicated GitHub domain and associated project-controlled host-name, perhaps: `update.openwebui.com`, deployed to replace `api.github.com` for the in-app update check. One possible solution could be to use a [GitHub Action](https://docs.github.com/en/actions) with a process like [push-directory-to-another-repository](https://github.com/marketplace/actions/push-directory-to-another-repository) to generate JSON output and push it to an "update" project. The application client code could then point to `https://update.openwebui.com/release.json` (or something) to pull the JSON containing the relevant release version metadata.
Maintainers are open to PRs. It looks like you have a good idea of what to do with this issue, maybe you could open a PR?
Thanks for the feature suggestion
@Lanhild commented on GitHub (Apr 15, 2024):
Maintainers are open to PRs. It looks like you have a good idea of what to do with this issue, maybe you could open a PR?
Thanks for the feature suggestion
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 @ghost on GitHub (Apr 11, 2024).
Is your feature request related to a problem? Please describe.
The current in-app update check polls the generic GitHub API which can be problematic to approve (and permit firewall network access to) in restrictive enterprise environments. From a security perspective, this can be undesirable since threat actors are known to abuse GitHub for malicious purpose.
Describe the solution you'd like
I'd like to see a dedicated GitHub domain and associated project-controlled host-name, perhaps:
update.openwebui.com, deployed to replaceapi.github.comfor the in-app update check. One possible solution could be to use a GitHub Action with a process like push-directory-to-another-repository to generate JSON output and push it to an "update" project. The application client code could then point tohttps://update.openwebui.com/release.json(or something) to pull the JSON containing the relevant release version metadata.@Lanhild commented on GitHub (Apr 15, 2024):
Maintainers are open to PRs. It looks like you have a good idea of what to do with this issue, maybe you could open a PR?
Thanks for the feature suggestion
@ghost commented on GitHub (Apr 16, 2024):
In hindsight, this probably isn't worth the effort.