gitea should fail gracefully when OIDC IDP has problems #4289

New Issue

GiteaMirror · 2025-11-02T05:44:56-06:00

GiteaMirror commented

2025-11-02 05:44:56 -06:00

Originally created by @cruwe on GitHub (Nov 12, 2019).

First, thank you very much for developing gitea!

Gitea version (or commit ref): db0d4ffdc7
Git version: v1.10.0-RC1, (I am sorry, I "destroyed" the test-case when fixing the issue, so I cannot test against more recent)
Operating system: Ubuntu 18.04.3 LTS, 4.15.0-66-generic #75-Ubuntu SMP, upstream Dockerfile
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

2019/11/12 07:36:17 ...uth/oauth2/oauth2.go:173:createProvider() [W] Failed to create OpenID Connect Provider with name '<...>' with url 'https://keycloak-management-infra.router.default.svc.cluster.local/auth/realms/<...>/.well-known/openid-configuration': Get https://keycloak-management-infra.router.default.svc.cluster.local/auth/realms/<...>/.well-known/openid-configuration: x509: certificate signed by unknown authority
2019/11/12 07:36:17 routers/init.go:92:GlobalInit() [F] Failed to initialize OAuth2 support: Get https://keycloak-management-infra.router.default.svc.cluster.local/auth/realms/<...>/.well-known/openid-configuration: x509: certificate signed by unknown authority

Description

When gitea has been configured against an OIDC IDP and when between restarts the IDP's endpoint stops being served with "proper/correct" certificates, gitea fails to start, running in a restart loop with a container built from the upstream Dockerfile.

Instead, I would like gitea to fail gracefully, disabling the IDP in question and allowing to login with other authentication sources (local admin comes to mind) to fix the problem "in app". I stumbled upon the issue when trying to "migrate" an instance over differently built experimental OpenShift clusters via the persistent volume. I "solved" the issue by deleting the corresponding row in "login_source" on the database.

The issue is minor, stems from operator weirdness in my case and is fixable. Abstracting from my specifics, however, I can imagine cases where a certificates' best-before-date may have been reached. I agree for various reasons that one should not trust such a certificate any more, especially for an IDP.
However, it would be nice to be able to fix such issues without reverting to fiddling with the database.

Thank you very much for your consideration! Cheers!

Screenshots

Originally created by @cruwe on GitHub (Nov 12, 2019).  First, thank you very much for developing gitea! - Gitea version (or commit ref): db0d4ffdc7d0800b7785beddee4a715b1f7589bd - Git version: v1.10.0-RC1, (I am sorry, I "destroyed" the test-case when fixing the issue, so I cannot test against more recent) - Operating system: Ubuntu 18.04.3 LTS, 4.15.0-66-generic #75-Ubuntu SMP, upstream Dockerfile - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: 2019/11/12 07:36:17 ...uth/oauth2/oauth2.go:173:createProvider() [W] Failed to create OpenID Connect Provider with name '<...>' with url 'https://keycloak-management-infra.router.default.svc.cluster.local/auth/realms/<...>/.well-known/openid-configuration': Get https://keycloak-management-infra.router.default.svc.cluster.local/auth/realms/<...>/.well-known/openid-configuration: x509: certificate signed by unknown authority 2019/11/12 07:36:17 routers/init.go:92:GlobalInit() [F] Failed to initialize OAuth2 support: Get https://keycloak-management-infra.router.default.svc.cluster.local/auth/realms/<...>/.well-known/openid-configuration: x509: certificate signed by unknown authority ## Description When gitea has been configured against an OIDC IDP and when between restarts the IDP's endpoint stops being served with "proper/correct" certificates, gitea fails to start, running in a restart loop with a container built from the upstream Dockerfile. Instead, I would like gitea to fail gracefully, disabling the IDP in question and allowing to login with other authentication sources (local admin comes to mind) to fix the problem "in app". I stumbled upon the issue when trying to "migrate" an instance over differently built experimental OpenShift clusters via the persistent volume. I "solved" the issue by deleting the corresponding row in "login_source" on the database. The issue is minor, stems from operator weirdness in my case and is fixable. Abstracting from my specifics, however, I can imagine cases where a certificates' best-before-date may have been reached. I agree for various reasons that one should not trust such a certificate any more, especially for an IDP. However, it would be nice to be able to fix such issues without reverting to fiddling with the database. Thank you very much for your consideration! Cheers! ## Screenshots

GiteaMirror added the type/proposal label 2025-11-02 05:44:56 -06:00

GiteaMirror closed this issue

2025-11-02 05:44:56 -06:00

GiteaMirror commented

2025-11-02 05:44:57 -06:00

@lunny commented on GitHub (Nov 12, 2019):

Maybe an option on Auth Source.

@lunny commented on GitHub (Nov 12, 2019): Maybe an option on Auth Source.

GiteaMirror commented

2025-11-02 05:44:57 -06:00

@xeals commented on GitHub (May 30, 2020):

This is an ongoing issue and surfaces in more than just certificate issues.

I have a self-hosted instance of an OIDC provider (Keycloak) that occasionally fails for completely random reasons. Since it's behind a proxy, when it fails the proxy will return a plaintext "502 Bad Gateway" response, which Gitea happily tries to parse and brings itself down when it doesn't work.

2020/05/30 18:57:23 ...uth/oauth2/oauth2.go:174:createProvider() [W] Failed to create OpenID Connect Provider with name 'keycloak' with url 'https://keycloak.example.com/auth/realms/universe/.well-known/openid-configuration': invalid character 'B' after top-level value
2020/05/30 18:57:23 routers/init.go:142:GlobalInit() [F] Failed to initialize OAuth2 support: invalid character 'B' after top-level value
Received signal 15; terminating.

@xeals commented on GitHub (May 30, 2020): This is an ongoing issue and surfaces in more than just certificate issues. I have a self-hosted instance of an OIDC provider (Keycloak) that occasionally fails for completely random reasons. Since it's behind a proxy, when it fails the proxy will return a plaintext "502 Bad Gateway" response, which Gitea happily tries to parse and brings itself down when it doesn't work. ``` 2020/05/30 18:57:23 ...uth/oauth2/oauth2.go:174:createProvider() [W] Failed to create OpenID Connect Provider with name 'keycloak' with url 'https://keycloak.example.com/auth/realms/universe/.well-known/openid-configuration': invalid character 'B' after top-level value 2020/05/30 18:57:23 routers/init.go:142:GlobalInit() [F] Failed to initialize OAuth2 support: invalid character 'B' after top-level value Received signal 15; terminating. ```

GiteaMirror commented

2025-11-02 05:44:57 -06:00

@kowalski7cc commented on GitHub (Feb 24, 2021):

Yep, my personal keycloak failed and I have no time to fix it. So now I'm unable to use my gitea...

@kowalski7cc commented on GitHub (Feb 24, 2021): Yep, my personal keycloak failed and I have no time to fix it. So now I'm unable to use my gitea...

GiteaMirror commented

2025-11-02 05:44:57 -06:00

@kowalski7cc commented on GitHub (Feb 24, 2021):

I worked it around by creating a new instance of keycloak on the same URL and deleting it from the settings page.

@kowalski7cc commented on GitHub (Feb 24, 2021): I worked it around by creating a new instance of keycloak on the same URL and deleting it from the settings page.

GiteaMirror commented

2025-11-02 05:44:58 -06:00

@netcicd commented on GitHub (Mar 23, 2021):

I understand that this is a solution for some, but I can no longer re-enable keycloak. So in my case the cure is worse than the problem. Rebooting gitea in order to see if the connection does not help.

@netcicd commented on GitHub (Mar 23, 2021): I understand that this is a solution for some, but I can no longer re-enable keycloak. So in my case the cure is worse than the problem. Rebooting gitea in order to see if the connection does not help.

GiteaMirror commented

2025-11-02 05:44:58 -06:00

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

@netcicd I don't understand. Why can't you re-enable keycloak?

@zeripath commented on GitHub (Mar 23, 2021): @netcicd I don't understand. Why can't you re-enable keycloak?

GiteaMirror commented

2025-11-02 05:44:58 -06:00

@netcicd commented on GitHub (Mar 24, 2021):

@zeripath thx for your rapid response. My monitor made the check-box invisible :) Can re-enable indeed this way (but this is hardly usable)
This implies that a user needs to log in as admin to get it working again. I use Keycloak and Gitea in Docker. Gitea boots faster than Keycloak and some form of retry /graceful recovery should be possible. I can imagine that you can configure a timeout as a solution: e.g. if Keycloak does not come back within say 5 min, only then disable. Or make it configurable.

@netcicd commented on GitHub (Mar 24, 2021): @zeripath thx for your rapid response. My monitor made the check-box invisible :) Can re-enable indeed this way (but this is hardly usable) This implies that a user needs to log in as admin to get it working again. I use Keycloak and Gitea in Docker. Gitea boots faster than Keycloak and some form of retry /graceful recovery should be possible. I can imagine that you can configure a timeout as a solution: e.g. if Keycloak does not come back within say 5 min, only then disable. Or make it configurable.

GiteaMirror referenced this issue

2025-11-02 12:32:29 -06:00

[PR #4289] [MERGED] Fix webhook type conflation. (#4285) #17319

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