github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 18:48:08 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Adding OAuth2 Authentication Sources through the CLI Requires Manual Intervention through UI in order to work #4048

New Issue
Closed
opened 2025-11-02 05:35:34 -06:00 by GiteaMirror · 15 comments
GiteaMirror commented 2025-11-02 05:35:34 -06:00
Owner
Copy Link

Originally created by @ilyakrasnovsky on GitHub (Oct 2, 2019).

First off, thanks for a great product so far!

  • Gitea version (or commit ref): 1.9.3
  • Git version: 1.8.3.1
  • Operating system: CentOS 7 (really a Docker container running in OpenShift)
  • 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: mentioned in description below

Description

The most straightforward way to reproduce this IMO is:

  1. Deploy Gitea 1.9.3 however you like
  2. Use the CLI reference to create an OAuth2 authentication source
  • For example gitea admin auth add-oauth --name keycloakoidc --provider openidConnect --key gitea --secret <MY-GITEA-CLIENT-SECRET> --auto-discover-url http://<MY-KEYCLOAK-DOMAIN>/auth/realms/<MY-KEYCLOAK-REALM>/.well-known/openid-configuration --config=/home/gitea/conf/app.ini
  • Also reproducible with other providers, like gitlab, ex.
    /home/gitea/gitea admin auth add-oauth --name gitlab --provider gitlab --key gitea --secret <MY-GITEA-CLIENT-SECRET> --custom-auth-url https://gitlab.com/oauth/authorize --custom-token-url https://gitlab.com/oauth/token --custom-profile-url https://gitlab.com/api/v3/user --config=/home/gitea/conf/app.ini

These commands both succeed and you get the appropriate Sign in with buttons appearing on the sign in page, as shown below:

image

However, clicking on this link immediately gives a 500 error (screenshot below):

image

The server logs don't produce much more there, just
[Macaron] 2019-10-02 17:02:02: Completed GET /user/oauth2/gitlab 500 Internal Server Error in 7.243256ms.

However : if you had DISABLE_REGISTRATION = false in your app.ini, and at this point you register as a local (non-external) user with admin privileges through the UI, and then go to Site Administration->Authentication Sources, click to edit the authentication source that you just created through the CLI, and just click update (no changes whatsoever, see below)

image

Then you will notice that if you sign out and go back to the sign in page, then clicking the Sign in with Gitlab button works, it takes you out to Gitlab.com instead of returning a 500.

image

In summary, as the title of this issue suggests, creating OAuth2 authentication sources through the CLI requires a manual, one-time intervention through the UI to make them work. In most cases this isn't a big deal, but it's a showstopper if you're trying to automate the deployment of Gitea. Thanks!

Originally created by @ilyakrasnovsky on GitHub (Oct 2, 2019). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> First off, thanks for a great product so far! - Gitea version (or commit ref): 1.9.3 - Git version: 1.8.3.1 - Operating system: CentOS 7 (really a Docker container running in OpenShift) - 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: mentioned in description below ## Description The most straightforward way to reproduce this IMO is: 1. Deploy Gitea 1.9.3 however you like 2. Use the [CLI reference](https://docs.gitea.io/en-us/command-line/) to create an OAuth2 authentication source * For example `gitea admin auth add-oauth --name keycloakoidc --provider openidConnect --key gitea --secret <MY-GITEA-CLIENT-SECRET> --auto-discover-url http://<MY-KEYCLOAK-DOMAIN>/auth/realms/<MY-KEYCLOAK-REALM>/.well-known/openid-configuration --config=/home/gitea/conf/app.ini` * Also reproducible with other providers, like gitlab, ex. `/home/gitea/gitea admin auth add-oauth --name gitlab --provider gitlab --key gitea --secret <MY-GITEA-CLIENT-SECRET> --custom-auth-url https://gitlab.com/oauth/authorize --custom-token-url https://gitlab.com/oauth/token --custom-profile-url https://gitlab.com/api/v3/user --config=/home/gitea/conf/app.ini` These commands both succeed and you get the appropriate `Sign in with` buttons appearing on the sign in page, as shown below: ![image](https://user-images.githubusercontent.com/15662092/66065366-35ba8180-e515-11e9-8a86-b7f6f87df356.png) However, clicking on this link immediately gives a 500 error (screenshot below): ![image](https://user-images.githubusercontent.com/15662092/66065417-571b6d80-e515-11e9-8540-e0967246c618.png) The server logs don't produce much more there, just `[Macaron] 2019-10-02 17:02:02: Completed GET /user/oauth2/gitlab 500 Internal Server Error in 7.243256ms`. **However** : if you had `DISABLE_REGISTRATION = false` in your `app.ini`, and at this point you register as a local (non-external) user with admin privileges through the UI, and then go to `Site Administration->Authentication Sources`, click to edit the authentication source that you just created through the CLI, **and just click update** (no changes whatsoever, see below) ![image](https://user-images.githubusercontent.com/15662092/66066153-fc831100-e516-11e9-932b-17c4457e4ff7.png) Then you will notice that if you sign out and go back to the sign in page, then clicking the `Sign in with` Gitlab button works, it takes you out to Gitlab.com instead of returning a 500. ![image](https://user-images.githubusercontent.com/15662092/66066240-2b00ec00-e517-11e9-85c8-24431938f3a1.png) In summary, as the title of this issue suggests, creating OAuth2 authentication sources through the CLI requires a manual, one-time intervention through the UI to make them work. In most cases this isn't a big deal, but it's a showstopper if you're trying to automate the deployment of Gitea. Thanks!
GiteaMirror added the issue/confirmedtype/bug labels 2025-11-02 05:35:34 -06:00
GiteaMirror commented 2025-11-02 05:35:35 -06:00
Author
Owner
Copy Link

@ilyakrasnovsky commented on GitHub (Oct 2, 2019):

#183 has a good discussion that's relevant to this

@ilyakrasnovsky commented on GitHub (Oct 2, 2019): #183 has a good discussion that's relevant to this
GiteaMirror commented 2025-11-02 05:35:35 -06:00
Author
Owner
Copy Link

@ilyakrasnovsky commented on GitHub (Oct 3, 2019):

I've been fooling around with this more after building Gitea from source. I've narrowed it down to a "no provider found" error in the SignInOAuth function in routers/user/auth.go (maybe similar to #5380, but I'm certain my auto-discovery URL is right because it works if I fill it in through the UI). I also noticed that simply restarting the Gitea application after invoking the gitea admin auth add-oauth commands described above, I no longer get the 500 on sign-in, without UI intervention. So that's an ugly but viable workaround. Basically, deploy Gitea, run the CLI command to add an auth source, then restart Gitea. This smells like a caching issue. I'm not too hot with Go or Macaron right now so perhaps I'll revisit when I'm better educated :)

@ilyakrasnovsky commented on GitHub (Oct 3, 2019): I've been fooling around with this more after building Gitea from source. I've narrowed it down to a "no provider found" error in the `SignInOAuth` function in `routers/user/auth.go` (maybe similar to #5380, but I'm certain my auto-discovery URL is right because it works if I fill it in through the UI). I also noticed that simply restarting the Gitea application after invoking the `gitea admin auth add-oauth` commands described above, I no longer get the 500 on sign-in, without UI intervention. So that's an ugly but viable workaround. Basically, deploy Gitea, run the CLI command to add an auth source, then restart Gitea. This smells like a caching issue. I'm not too hot with Go or Macaron right now so perhaps I'll revisit when I'm better educated :)
GiteaMirror commented 2025-11-02 05:35:35 -06:00
Author
Owner
Copy Link

@guillep2k commented on GitHub (Oct 3, 2019):

Sorry if the question is too dumb but, have you tried using quotes in your parameters when invoking from shell?

For instance, change:
--auto-discover-url http://<MY-KEYCLOAK-DOMAIN>
into
--auto-discover-url "http://<MY-KEYCLOAK-DOMAIN>"

A big gotcha with URLs is that they usually contain characters like ? and & that are special delimiters in most shells.

@guillep2k commented on GitHub (Oct 3, 2019): Sorry if the question is too dumb but, have you tried using quotes in your parameters when invoking from shell? For instance, change: `--auto-discover-url http://<MY-KEYCLOAK-DOMAIN>` into `--auto-discover-url "http://<MY-KEYCLOAK-DOMAIN>"` A big gotcha with URLs is that they usually contain characters like `?` and `&` that are special delimiters in most shells.
GiteaMirror commented 2025-11-02 05:35:35 -06:00
Author
Owner
Copy Link

@ilyakrasnovsky commented on GitHub (Oct 3, 2019):

@guillep2k I did try that, unfortunately I still got a 500. Inspecting it through the UI (after it's populated through the CLI) yields the exact URL I want. The actual request to user/oauth2/keycloakoidc (or whatever you named your authentication source) stills fails unless I click "update" through the UI, or restart the application.

@ilyakrasnovsky commented on GitHub (Oct 3, 2019): @guillep2k I did try that, unfortunately I still got a 500. Inspecting it through the UI (after it's populated through the CLI) yields the exact URL I want. The actual request to `user/oauth2/keycloakoidc` (or whatever you named your authentication source) stills fails unless I click "update" through the UI, or restart the application.
GiteaMirror commented 2025-11-02 05:35:35 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Dec 2, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Dec 2, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
GiteaMirror commented 2025-11-02 05:35:36 -06:00
Author
Owner
Copy Link

@bendem commented on GitHub (Jun 17, 2020):

Came here to say this, I've tried many things, checked the login_source table before and after updating manually from the UI, I'm not sure what's different.

@bendem commented on GitHub (Jun 17, 2020): Came here to say this, I've tried many things, checked the `login_source` table before and after updating manually from the UI, I'm not sure what's different.
GiteaMirror commented 2025-11-02 05:35:36 -06:00
Author
Owner
Copy Link

@traverseda commented on GitHub (Aug 14, 2020):

I've been fooling around with this more after building Gitea from source. I've narrowed it down to a "no provider found" error in the SignInOAuth function in routers/user/auth.go (maybe similar to #5380, but I'm certain my auto-discovery URL is right because it works if I fill it in through the UI). I also noticed that simply restarting the Gitea application after invoking the gitea admin auth add-oauth commands described above, I no longer get the 500 on sign-in, without UI intervention. So that's an ugly but viable workaround. Basically, deploy Gitea, run the CLI command to add an auth source, then restart Gitea. This smells like a caching issue. I'm not too hot with Go or Macaron right now so perhaps I'll revisit when I'm better educated :)

Unfortunately a simple restart doesn't seem to fix this. I think this means that this isn't going to be viable for my employer.

@traverseda commented on GitHub (Aug 14, 2020): > I've been fooling around with this more after building Gitea from source. I've narrowed it down to a "no provider found" error in the `SignInOAuth` function in `routers/user/auth.go` (maybe similar to #5380, but I'm certain my auto-discovery URL is right because it works if I fill it in through the UI). I also noticed that simply restarting the Gitea application after invoking the `gitea admin auth add-oauth` commands described above, I no longer get the 500 on sign-in, without UI intervention. So that's an ugly but viable workaround. Basically, deploy Gitea, run the CLI command to add an auth source, then restart Gitea. This smells like a caching issue. I'm not too hot with Go or Macaron right now so perhaps I'll revisit when I'm better educated :) Unfortunately a simple restart doesn't seem to fix this. I think this means that this isn't going to be viable for my employer.
GiteaMirror commented 2025-11-02 05:35:36 -06:00
Author
Owner
Copy Link

@bendem commented on GitHub (Aug 18, 2020):

Unfortunately a simple restart doesn't seem to fix this. I think this means that this isn't going to be viable for my employer.

I confirm a restart fixes the problem, if it doesn't for you, you probably have another problem. Does it work when you input the exact same config in the web UI?

@bendem commented on GitHub (Aug 18, 2020): > Unfortunately a simple restart doesn't seem to fix this. I think this means that this isn't going to be viable for my employer. I confirm a restart fixes the problem, if it doesn't for you, you probably have another problem. Does it work when you input the exact same config in the web UI?
GiteaMirror commented 2025-11-02 05:35:36 -06:00
Author
Owner
Copy Link

@traverseda commented on GitHub (Aug 18, 2020):

I'll investigate further. It's possible that that I've got something mistyped in the command line. Thanks for letting me know.

@traverseda commented on GitHub (Aug 18, 2020): I'll investigate further. It's possible that that I've got something mistyped in the command line. Thanks for letting me know.
GiteaMirror commented 2025-11-02 05:35:37 -06:00
Author
Owner
Copy Link

@traverseda commented on GitHub (Aug 18, 2020):

Can confirm that this works.

It appears that I misspelled --provider openidConnect, which was causing that to fail silently.

@traverseda commented on GitHub (Aug 18, 2020): Can confirm that this works. It appears that I misspelled `--provider openidConnect`, which was causing that to fail silently.
GiteaMirror commented 2025-11-02 05:35:37 -06:00
Author
Owner
Copy Link

@daniil-pankratov commented on GitHub (Dec 9, 2020):

Hi.

Are there any news about this bug? @lunny

@daniil-pankratov commented on GitHub (Dec 9, 2020): Hi. Are there any news about this bug? @lunny
GiteaMirror commented 2025-11-02 05:35:37 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 19, 2020):

It seems the command code is the same as creating OAuth2 login source via UI. The only different is

diff --git a/cmd/admin.go b/cmd/admin.go
index 25faaae18..b11719be3 100644
--- a/cmd/admin.go
+++ b/cmd/admin.go
@@ -615,10 +615,11 @@ func runAddOauth(c *cli.Context) error {
 	}
 
 	return models.CreateLoginSource(&models.LoginSource{
-		Type:      models.LoginOAuth2,
-		Name:      c.String("name"),
-		IsActived: true,
-		Cfg:       parseOAuth2Config(c),
+		Type:          models.LoginOAuth2,
+		Name:          c.String("name"),
+		IsActived:     true,
+		IsSyncEnabled: false,
+		Cfg:           parseOAuth2Config(c),
 	})
 }
@lunny commented on GitHub (Dec 19, 2020): It seems the command code is the same as creating OAuth2 login source via UI. The only different is ```diff diff --git a/cmd/admin.go b/cmd/admin.go index 25faaae18..b11719be3 100644 --- a/cmd/admin.go +++ b/cmd/admin.go @@ -615,10 +615,11 @@ func runAddOauth(c *cli.Context) error { } return models.CreateLoginSource(&models.LoginSource{ - Type: models.LoginOAuth2, - Name: c.String("name"), - IsActived: true, - Cfg: parseOAuth2Config(c), + Type: models.LoginOAuth2, + Name: c.String("name"), + IsActived: true, + IsSyncEnabled: false, + Cfg: parseOAuth2Config(c), }) } ```
GiteaMirror commented 2025-11-02 05:35:38 -06:00
Author
Owner
Copy Link

@daniil-pankratov commented on GitHub (Dec 19, 2020):

Could IsSyncEnabled parameter lead to this bug?

@daniil-pankratov commented on GitHub (Dec 19, 2020): Could `IsSyncEnabled` parameter lead to this bug?
GiteaMirror commented 2025-11-02 05:35:38 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 19, 2020):

I don't think so.

@lunny commented on GitHub (Dec 19, 2020): I don't think so.
GiteaMirror commented 2025-11-02 05:35:38 -06:00
Author
Owner
Copy Link

@bendem commented on GitHub (Dec 19, 2020):

You are showing the difference in database saving. My guess is: the data from that table is only loaded on application start. When adding from the UI it is added to the in-memory providers, when called from the cli, it is not. That's why a restart fixes the problem.

19 Dec 2020 09:42:57 Lunny Xiao notifications@github.com:

It seems the command code is the same as creating OAuth2 login source via UI. The only different isdiff --git a/cmd/admin.go b/cmd/admin.go
index 25faaae18..b11719be3 100644
--- a/cmd/admin.go
+++ b/cmd/admin.go
@@ -615,10 +615,11 @@ func runAddOauth(c *cli.Context) error {
  }

  return models.CreateLoginSource(&models.LoginSource{
-   Type:      models.LoginOAuth2,
-   Name:      c.String("name"),
-   IsActived: true,
-   Cfg:       parseOAuth2Config(c),
+   Type:          models.LoginOAuth2,
+   Name:          c.String("name"),
+   IsActived:     true,
+   IsSyncEnabled: false,
+   Cfg:           parseOAuth2Config(c),
  })
}
—

@bendem commented on GitHub (Dec 19, 2020): You are showing the difference in database saving. My guess is: the data from that table is only loaded on application start. When adding from the UI it is added to the in-memory providers, when called from the cli, it is not. That's why a restart fixes the problem. 19 Dec 2020 09:42:57 Lunny Xiao <notifications@github.com>: > It seems the command code is the same as creating OAuth2 login source via UI. The only different isdiff --git a/cmd/admin.go b/cmd/admin.go > index 25faaae18..b11719be3 100644 > --- a/cmd/admin.go > +++ b/cmd/admin.go > @@ -615,10 +615,11 @@ func runAddOauth(c *cli.Context) error { >   } > >   return models.CreateLoginSource(&models.LoginSource{ > -   Type:      models.LoginOAuth2, > -   Name:      c.String("name"), > -   IsActived: true, > -   Cfg:       parseOAuth2Config(c), > +   Type:          models.LoginOAuth2, > +   Name:          c.String("name"), > +   IsActived:     true, > +   IsSyncEnabled: false, > +   Cfg:           parseOAuth2Config(c), >   }) > } > —
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/confirmed type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#4048
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?