Updating OAuth2 Auth Sources in CLI requires manual intervention in WebUI or restart #11142

New Issue

GiteaMirror · 2025-11-02T09:28:51-06:00

GiteaMirror commented

2025-11-02 09:28:51 -06:00

Originally created by @golyalpha on GitHub (Jul 1, 2023).

Description

This might be an issue similar to one described in #8356, it seems that changes made via the CLI don't actually get applied until intervention via the WebUI (or a restart of the Gitea server).

I have been reconfiguring an OIDC-based auth source with additional scopes via Gitea cli (got a shell in container via docker compose exec), because my Gitea account lost admin permissions (the groups claim required an extra scope which Gitea wasn't requesting at the time). A while later, I found out that even though I tried changing the requested scopes a bunch of times, during login or linking Gitea would only request the openid and profile scopes.

When I managed to get admin back on my Gitea account, I checked the site administration, and the form had the updated scopes, and after updating the configuration from the form (without actually changing anything) gitea started requesting all the scopes that were configured for the auth source.

Gitea Version

1.19.3 (Docker)

Can you reproduce the bug on the Gitea demo site?

No (bug requires CLI access)

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Linux, Ubuntu Focal (aarch64)

How are you running Gitea?

It's running in Docker with a Postgres DB an the Actions Runner inside Docker Compose, behind Nginx Proxy Manager.

Database

PostgreSQL

Originally created by @golyalpha on GitHub (Jul 1, 2023). ### Description This might be an issue similar to one described in #8356, it seems that changes made via the CLI don't actually get applied until intervention via the WebUI (or a restart of the Gitea server). I have been reconfiguring an OIDC-based auth source with additional scopes via Gitea cli (got a shell in container via docker compose exec), because my Gitea account lost admin permissions (the groups claim required an extra scope which Gitea wasn't requesting at the time). A while later, I found out that even though I tried changing the requested scopes a bunch of times, during login or linking Gitea would only request the `openid` and `profile` scopes. When I managed to get admin back on my Gitea account, I checked the site administration, and the form had the updated scopes, and after updating the configuration from the form (without actually changing anything) gitea started requesting all the scopes that were configured for the auth source. ### Gitea Version 1.19.3 (Docker) ### Can you reproduce the bug on the Gitea demo site? No (bug requires CLI access) ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Linux, Ubuntu Focal (aarch64) ### How are you running Gitea? It's running in Docker with a Postgres DB an the Actions Runner inside Docker Compose, behind Nginx Proxy Manager. ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 09:28:51 -06:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11142