-
-
Notifications
You must be signed in to change notification settings - Fork 351
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
[feature] overhaul the oidc system #961
Conversation
cb7f9bd
to
9f3be8b
Compare
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.
This is looking pretty tasty IMO. Got a few comments about clarification and stuff. Overall, this looks like it's going in a great direction. I'm glad you bit the bullet and just jumped into it, it's always a nice surprise to get a really good PR like this :)
} | ||
|
||
func init() { | ||
gob.Register(&Claims{}) |
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.
Could you explain this? I'm not sure what it does :P
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.
Sure: the way I implemented the finalization page, the claim temporarily gets stored in the session. Since the session package uses gob to serialize the struct, we need to register it as serializable. I'm open to cleaner approaches - am not too happy with this as well
internal/cache/user.go
Outdated
@@ -87,6 +87,11 @@ func (c *UserCache) GetByEmail(email string) (*gtsmodel.User, bool) { | |||
return c.cache.GetBy("email", email) | |||
} | |||
|
|||
// GetByExternalID attempts to fetch a user from the cache by its external id, you will receive a copy for thread-safety | |||
func (c *UserCache) GetByExternalID(id string) (*gtsmodel.User, bool) { | |||
return c.cache.GetBy("external_id", id) |
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.
Does this need to be registered with the cache as a lookup @NyaaaWhatsUpDoc ?
I had an idea for a graceful migration path:
What do you think about this? |
9f3be8b
to
f06bed0
Compare
I've now implemented this (without the step of asking for a new username for now). With this, we have a migration path for servers already using OIDC |
98c72e5
to
bc87fe7
Compare
Heya, apologies for being slow to respond to this, it's been rather a hectic week :') This looks good to me so far! At least, I don't see any glaring issues, but will have to try it out on gts.superseriousbusiness.org (which uses oidc) to see how it works :) One thing you missed is adding the new config flag to Once those things are done, I think you can mark this as ready for review and we can have a proper look through it. Thank you, this is great work! |
No problem, I'm just happy to hack on something not work-related 😁 I've added the docs and example config. I always seem to forget at least one place when adding new config options :D Also marked this PR as ready 🤞 |
This looks good to me :) @NyaaaWhatsUpDoc do you also wanna review or nah? |
hey @theSuess , can you merge main into this or rebase to resolve the merge conflicts? then i'll look at it afresh |
69681f8
to
b382797
Compare
Rebased and tested |
b382797
to
0593356
Compare
0593356
to
dfe79ea
Compare
I'll take a look at this today too :) sorry I managed to miss your notifications on this @tsmethurst |
No worries pal :) |
I have started to review this, but I have ran out of spoons for the evening, and it is late. I shall get back to it tomorrow evening most likely :) |
dfe79ea
to
13f63f3
Compare
i suggest we merge this once 0.6.0 is out, so we have time to mess about with it :) [edit] Also sorry for the constant need for rebases dominik 😬 |
this allows for more flexible username handling and prevents account takeover using old email addresses
13f63f3
to
0c4caab
Compare
func (m *Module) FinalizePOSTHandler(c *gin.Context) { | ||
s := sessions.Default(c) | ||
|
||
form := &extraInfo{} |
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.
Could we get some code comments in here? It's quite a heavy unseparated function block
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.
I've sprinkled in some comments - let me know if something is still unclear
if errWithCode != nil { | ||
m.clearSession(s) | ||
api.ErrorHandler(c, errWithCode, m.processor.InstanceGet) | ||
return | ||
} | ||
|
||
if user == nil { |
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.
Again this is quite a heavy unseparated function block. I know this is quite nitpicky I'm just a bit of a stickler for readability!
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.
Also added some comments here. We could also split this up into its own function, but not sure if that would increase readability by much
Since I'm very interested in this topic, I've built a draft to implement my feedback on #763, #917 and #309
This is by no means final, and very much intended as a base for further discussions on these issues.
It works by intercepting the first OIDC callback of a user and returns a small page for customizing the username if no matching user is found. The text field is prefilled with the
preferred_username
claim.It also performs validation and checks the DB for colliding usernames
The biggest open topic IMHO is finding a way to migrate existing OIDC setups to the new
ExternalID
field. I honestly have no idea what would be the best approach here