Disabling openid provider on startup is confusing when provider is still working #7017

New Issue

GiteaMirror · 2025-11-02T07:13:36-06:00

GiteaMirror commented

2025-11-02 07:13:36 -06:00

Originally created by @decentral1se on GitHub (Mar 18, 2021).

Gitea version (or commit ref): 1.13.4
Git version: 2.20.1
Operating system: GNU/Linux Debian buster
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
Log gist: N/A

Description

While upgrading to 1.13.4, my keycloak openid provider was temporarily down. I had this openid provider enabled and working before the upgrade. After upgrading, the openid login button was gone. Looking back at the changelog, it seems in 1.13.3, a change was implemented to disable openid providers that were not reachable and avoid failing startup. That is a good change imho but disabling them leads to the case where your openid login is gone away but it should not be. Is it possible to not fail and not disable them? A retry window in place before disabling? I am not sure what is best but having the provider disabled is not ideal.

Refs: https://github.com/go-gitea/gitea/pull/14802

Originally created by @decentral1se on GitHub (Mar 18, 2021).   - Gitea version (or commit ref): 1.13.4 - Git version: 2.20.1 - Operating system: GNU/Linux Debian buster    - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - Log gist: N/A    ## Description  While upgrading to 1.13.4, my keycloak openid provider was temporarily down. I had this openid provider enabled and working before the upgrade. After upgrading, the openid login button was gone. Looking back at the changelog, it seems in 1.13.3, a change was implemented to disable openid providers that were not reachable and avoid failing startup. That is a good change imho but disabling them leads to the case where your openid login is gone away but it should not be. Is it possible to not fail and not disable them? A retry window in place before disabling? I am not sure what is best but having the provider disabled is not ideal. Refs: https://github.com/go-gitea/gitea/pull/14802

GiteaMirror added the type/proposal topic/authentication labels 2025-11-02 07:13:36 -06:00

GiteaMirror commented

2025-11-02 07:13:37 -06:00

@ghmer commented on GitHub (Mar 25, 2021):

Supporting that, at least make it configurable whether it should automatically be disabled. Or, even better: Retry, until the authentication source is up again. Right now, it is just confusing users.

@ghmer commented on GitHub (Mar 25, 2021): Supporting that, at least make it configurable whether it should automatically be disabled. Or, even better: Retry, until the authentication source is up again. Right now, it is just confusing users.

GiteaMirror commented

2025-11-02 07:13:37 -06:00

@zeripath commented on GitHub (Mar 25, 2021):

If we don't disable it the system fatals.

What you're basically asking for is a temporarily disabled status?

@zeripath commented on GitHub (Mar 25, 2021): If we don't disable it the system fatals. What you're basically asking for is a temporarily disabled status?

GiteaMirror commented

2025-11-02 07:13:37 -06:00

@zeripath commented on GitHub (Mar 25, 2021):

I mean you can always go into system admin and reenable it.

@zeripath commented on GitHub (Mar 25, 2021): I mean you can always go into system admin and reenable it.

GiteaMirror commented

2025-11-02 07:13:37 -06:00

@ghmer commented on GitHub (Mar 25, 2021):

This is not a binary issue, there are ways between "I must disable the authentication source" and "I must use log.Fatal". In example, why not put the authentication source in a retry list and have a thread periodically check whether it is available again?
Sure I can always admin into the system, but I'd rather see one user having a login issue but the system will "heal itself" (because I know the authentication source will be up in probably another minute) than getting several tickets overnight until I wake up the next morning and enable that thing again.

@ghmer commented on GitHub (Mar 25, 2021): This is not a binary issue, there are ways between "I must disable the authentication source" and "I must use log.Fatal". In example, why not put the authentication source in a retry list and have a thread periodically check whether it is available again? Sure I can always admin into the system, but I'd rather see one user having a login issue but the system will "heal itself" (because I know the authentication source will be up in probably another minute) than getting several tickets overnight until I wake up the next morning and enable that thing again.

GiteaMirror commented

2025-11-02 07:13:38 -06:00

@ctII commented on GitHub (Mar 30, 2021):

Self-healing providers could have a blip in their uptime at the same time as Gitea starts due to timing differences in startup, especially when deployed on the same Kubernetes cluster, but that shouldn't prevent providers from being used later if they are available

Could a new task in modules/cron that attempts to initialize disabled providers in models/oauth2 from the database on a periodic basis solve this?

@ctII commented on GitHub (Mar 30, 2021): Self-healing providers could have a blip in their uptime at the same time as Gitea starts due to timing differences in startup, especially when deployed on the same Kubernetes cluster, but that shouldn't prevent providers from being used later if they are available Could a new task in ```modules/cron``` that attempts to initialize disabled providers in ```models/oauth2``` from the database on a periodic basis solve this?

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#7017