Replies: 2 comments
-
While my initial reaction would be to opt for the more extensible At any rate, I feel like I've blocked this issue long enough by not giving a proper answer. Write it whichever way you feel would be best. At this point I'm ok with code that isn't ideal but gets the job done. If it works it can be fixed "later" if needed. For the record, I have no issue with using different URL endpoints for each OAuth method that do the actual login (eg |
Beta Was this translation helpful? Give feedback.
-
For now i think i'll play around with the slice idea, but if it ends up to be too messy i'll just hardcode the structs as specific fields. Regarding the endpoints: since it is needed anyways, i already do it that way. |
Beta Was this translation helpful? Give feedback.
-
Issue #35 intends to implement an integration point for external OAuth providers.
In my current planning a
Authentication
struct is created to manage the different authentication methods (OAuth, Local Login) in one single (uniform) structure.The user struct would be modified accordingly with two possibilities that are tbd:
or
While the first option would enable future expansion without modifying the user struct it would require having a
type
field in theAuthentication
struct which would require some iteration when selecting the correct authentication method for the login.Any feedback would be appreciated.
Beta Was this translation helpful? Give feedback.
All reactions