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

[ilyakrasnovsky]

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:

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

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)

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.

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!

[ilyakrasnovsky]

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

[ilyakrasnovsky]

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 :)

[guillep2k]

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.

[ilyakrasnovsky]

@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.

[stale]

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.

[bendem]

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.

[traverseda]

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.

[bendem]

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?

[traverseda]

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

[traverseda]

Can confirm that this works.

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

[daniil-pankratov]

Hi.

Are there any news about this bug? @lunny

[lunny]

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),
 	})
 }

[daniil-pankratov]

Could IsSyncEnabled parameter lead to this bug?

[lunny]

I don't think so.

[bendem]

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),   }) } —