Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create external user for new OAuth2 user #21276

Closed
wants to merge 4 commits into from
Closed

Create external user for new OAuth2 user #21276

wants to merge 4 commits into from

Conversation

wolfogre
Copy link
Member

Fix #21202.

After creating a new OAuth2 user, should insert an external user if it doesn't exist.

@6543 6543 modified the milestones: 1.17.3, 1.18.0 Sep 27, 2022
@@ -1041,7 +1041,7 @@ func handleOAuth2SignIn(ctx *context.Context, source *auth.Source, u *user_model
}

// update external user information
if err := externalaccount.UpdateExternalUser(u, gothUser); err != nil {
if err := externalaccount.UpdateExternalUser(u, gothUser, false); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why upsert=false?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unlike handleUserCreated, in handleOAuth2SignIn, the external user is expected to exist.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I tried to read the code, but the flow is quite complex.

I am not sure that handleOAuth2SignIn is guaranteed to be called after external user is prepared correctly.

Since the code was that before, I think there shouldn't be more problem. So LGTM.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I'm not even sure the stored external user data is being used. The code couldn't store any data before, but it worked fine, just caused user concern because of error logs.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Oct 10, 2022
@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Oct 11, 2022
Copy link
Contributor

@zeripath zeripath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... My usual comment about transactions applies here. We would actually need this to be an upsert and certainly not do a select then insert outside of a transaction.

Now, regarding this, the external user stuff seems to have gotten broken along the way here and I'm not certain whether it's being used at all or if it's helpful, or what it was intended to do.

We could merge this and then attempt to rationalize this code but I think we might want to take a closer look. Adding a little flag on to the function to say 'upsert' or not feels kinda wrong to me.

@wolfogre
Copy link
Member Author

wolfogre commented Oct 11, 2022

Hmm... My usual comment about transactions applies here. We would actually need this to be an upsert and certainly not do a select then insert outside of a transaction.

Now, regarding this, the external user stuff seems to have gotten broken along the way here and I'm not certain whether it's being used at all or if it's helpful, or what it was intended to do.

We could merge this and then attempt to rationalize this code but I think we might want to take a closer look. Adding a little flag on to the function to say 'upsert' or not feels kinda wrong to me.

You are right. Actually, I tried to find an elegant way to fix it, but the flow is so complex. The upsert is the simplest way I can think of to solve the error logs safely, a temporary patch to give us time to figure out the root cause.

@KN4CK3R
Copy link
Member

KN4CK3R commented Oct 18, 2022

That may not be correct. If I understand the existing code an ExternalLoginUser

makes the connecting between some existing user and additional external login sources

From the code this type is only inserted if an external login is used for an existing user but not if the user is created with/by that source. In this case User.LoginType has a specific value and no ExternalLoginUser is needed. (?)

to figure out the root cause.

And that may be root cause: an existing ExternalLoginUser may not be mandatory.

@KN4CK3R
Copy link
Member

KN4CK3R commented Oct 18, 2022

Alternative fix if my assumption is correct: #21504

zeripath pushed a commit that referenced this pull request Oct 19, 2022
Fixes #21202
Closes #21276

An `ExternalLoginUser` is not mandatory if the current user account was
created with/by the external login source.
KN4CK3R added a commit to KN4CK3R/gitea that referenced this pull request Oct 24, 2022
Fixes go-gitea#21202
Closes go-gitea#21276

An `ExternalLoginUser` is not mandatory if the current user account was
created with/by the external login source.
@lunny lunny removed this from the 1.18.0 milestone Dec 20, 2022
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/need 1 This PR needs approval from one additional maintainer to be merged. type/bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

UpdateExternalUser failed: external login user link does not exists
7 participants