-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Always put OAuth user info in the ExternalLoginUser table #1143
Conversation
It's really to need a proposal document to describe all the login. |
If a document is needed, it should be produced *before* introducing
the OAuth2 support, rather than let it add confusion to the code base
(and changes to production databases)
|
Note that doing this after 1.1.0 is out will require a new migration to convert existing records with OAuth2 in User.LoginSource |
@strk but even if it is done before, what happens to the installs from master builds (such as my own)? |
@geek1011 good question, I guess those would be just left with inconsistent database values. You might end up having users with OAuth2 LoginSource and no way to login with those OAuth2. |
u := &models.User{ | ||
Name: form.UserName, | ||
Email: form.Email, | ||
Passwd: form.Password, | ||
IsActive: !setting.Service.RegisterEmailConfirm, | ||
LoginType: models.LoginOAuth2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LoginType should be plain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default is LoginNone, which is threated by code the same as LoginPlain.
But yes, I guess it could be LoginPlain as long as we guarantee the actual login is not of the LDAP or SMTP or PAM type...
@@ -648,6 +625,13 @@ func LinkAccountPostRegister(ctx *context.Context, cpt *captcha.Captcha, form au | |||
} | |||
log.Trace("Account created: %s", u.Name) | |||
|
|||
// Link the oAuth account to the user | |||
err := models.LinkAccountToUser(u, gothUser.(goth.User)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How to migrate the old user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that 1.1.0 is out yes, this is a problem. Too bad you didn't want to merge this before (we saw people had problems with early upgrades anyway, so this would have not been different)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just like @geek1011 said, there many people use master, a migration needed.
I like this idea. There are two kinds of external Login Source. One is provide password authentication, another is for link. |
I raised this issue in the OAuth2 PR before, but my concern was not
considered. Now I don't know if I have time to fix this myself.
I think it should be done by the author of the OAuth2 code.
It's great to be more "open" in development, but we all need to pay
more attention to contributions and give proper importance to
responsibility. Whoever introduces a feature should be available to
maintain it.
|
@strk, when you review a PR, if you think your opinion should not be ignored, you could use github's request changes, then the merger should ask your confirmation before merge it. Our rules only consider two reviewers, lost this rule. |
I will try to add migration for this PR when I have time. |
e882bf5
to
01d0770
Compare
@lunny Did you have time to work on this? Otherwise I suggest we close this as "out of date" |
@bkcsoft I'm afraid I have no time to work on this. I still have serval PRs in v1.3 and v1.4 need work. |
a7d5065
to
b82fd19
Compare
This pull request 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 months. Thank you for your contributions. |
Still relevant, not sure why Travis is sad |
As per integration tests there is error in template:
|
7e16c04
to
dc03425
Compare
Never set OAuth in User.LoginSource, which keeps referring to the username/password interpretation. Fixes go-gitea#1124
dc03425
to
924f5ab
Compare
Refactors moved |
Yes, the motivation remains valid. Unfortunately the high version of Go required to build Gitea made me in a position to have more problems contributing (can't build w/out installing a foreign package in my otherwise all-distro-based system, and I'm short on disk space). For this reason I can't test my change much. Will gladly accept a PR to my branch if you want to work on the refactoring porting. |
It's stale for petty long time. What's the root problem behind the issue/PR? Is there any valuable information in this context? |
It was mostly a design concern, a way to separate "external" authentication sources from "internal" ones. One problem being resolved would be described in #1124 (comment) but that issue was closed by stale bot too |
Could some maintainers help to re-open that issue? @techknowlogick @lunny |
I think this PR/issue could be kept open, until there is a clear conclusion |
#1124 was opened so I think we could close this one because it's outdated. |
I also think we can close this and keep the issue open for further discussion |
Never set OAuth in User.LoginSource, which keeps referring to
the username/password interpretation. Fixes #1124
\cc @willemvd, @morrildl, @lunny, @bkcsoft
I think this should be done before 1.1.0