Open stadust opened 2 months ago
Oh, and there's also some code scattered around the repository about "email verification". That was an old attempt to instead associated email addresses to pointercrate accounts for password reset reasons. It failed because I couldn't be bothered to set up an email server. So that code should probably just be deleted as part of this.
In the beginning, the interesting code for this project lives almost completely in the pointercrate-user
packages.
pointercrate-user
, specifically https://github.com/stadust/pointercrate/blob/master/pointercrate-user/src/auth/mod.rsFor the last phase, some work with the demonlist packages will be needed, but we can get to that later
Add the ability to sign in with Google. The end goal is that the current registration and username/password system will be completely replaced (with the option to use the current username/password login only for accounts created before the new system was put in place).
[ ] Phase 1: Add ability to link google accounts to current pointercrate accounts. If I understand the high level overview that google gives on https://developers.google.com/identity/gsi/web/guides/integrate, it actually sounds quite simple
google_account_id
column to themembers
tableMost of the complicated oauth stuff is handled by google. We can use the HTML API. The flow here is
POST
to a new pointercrate API (say/api/v1/auth/google/link
) containing the GJWT and authorizing with the PJWT.members
table by setting thegoogle_account_id
to thesub
field of the GJWT.[ ] Phase 2: Add ability to actually log in with google
/api/v1/auth/google/login
) handling log-ins with Google will query the members table for the account that has the received Google JWT's sub field (after validating, ofc!), and return a PJWT for that account on success (still, a lot of code can probably be shared with step 1. - let's cross that bridge when we get to it though)[ ] Phase 3: Add ability to create new accounts through Google Sign Up - This one might actually be the trickiest one, funnily enough
/api/v1/auth/register
). I think it's fine to just have it start returning some error unconditionally.When creating a new account through google sign-in, we'll need to deal with two problems (after doing the same OAuth dance as above):
The latter is a problem because the JWT pointercrate creates are signed using a combination of the server's secret and the random salt used when hashing the account's password (which, yeah, no idea what 16 y/o me was thinking here). So that'll have to get fixed up. I guess just depending on the server's secret will be enough, but we need to make sure that we only change this for accounts that were created through the google sign-up option, old accounts should continue doing whatever we are doing right now.
The former, we can fix by simply dropping the entire username concept. Accounts created through Google Sign-Up with have the username field set to
null
, and theirdisplay_name
field set to the name of the google account (we get this information from the GJWT). Reason for this being that this is easier than providing some bizarre "username initially set to name of google account, but you can change it once in case you don't want to have the google name public" functionality. Currently pointercrate only uses the username for "legacy" login (which wont be possible for these accounts anyway), and when rendering the account as part of the claim verification system, and when you're a List Mod. For the latter reasons, we should make display name mandatory for these accounts (they can stay optional for legacy accounts).PATCH /api/v1/auth/me
)We won't support changing the google account associated with a pointercrate account (at least for now, although I guess a lot of the code from Phase 1 could be reused to implement this should it ever be needed).