This leverages our existing Discord OAuth implementation. Any users with a linked Discord account will be able to log in immediately. When logging in, we request the `email` scope in addition to `identity`, so existing users will be prompted one time to accept the new permissions. On subsequent logins, Discord will skip the prompt.
When linking your Discord account to an existing HMN account, we continue to only request the `identity` scope, so we do not receive the user's Discord email.
Both login and linking go through the same Discord OAuth callback. All flows through the callback try to achieve the same end goal: a logged-in HMN user with a linked Discord account.
Linking works the same as it ever has. Login, however, is different because we do not have a session ID to use as the OAuth state. To account for this, I have added a `pending_login` table that stores a secure unique ID and the eventual destination URL. These pending logins expire after 10 minutes. When we receive the OAuth callback, we look up the pending login by the OAuth `state` and immediately delete it. The destination URL will be used to redirect the user to the right place.
If we have a `discord_user` entry for the OAuth'd Discord user, we immediately log the user into the associated HMN account. This is the typical login case. If we do not have a `discord_user`, but there is exactly one HMN user with the same email address as the Discord user, we will link the two accounts and log into the HMN account.
(It is possible for multiple HMN accounts to have the same email, because we don't have a uniqueness constraint there. We fail the login in this case rather than link to the wrong account.)
Finally, if no associated HMN user exists, a new one will be created. It will use the Discord user's username, email, and avatar. This user will have no password, but they can set or reset a password through the usual flows.
Co-authored-by: Ben Visness <bvisness@gmail.com>
Reviewed-on: #106
It didn't work when creating a new project or editing personal projects,
due to routing issues. I also took this opportunity to make the script
support multiple form submit buttons, since in some cases we will have a
submit button on each tab, and I figured they all should respect the
fact that you have an upload in progress.
This takes advantage of generics, and generally clears up a lot of
inconsistencies and quality-of-life issues.
Start of db rework: clean up, start generics, improve tests
Write some nice aspirational package docs
Rework and document the db API
Tests still pass, at least...now for everything else
Update all callsites of db functions
Finish converting all callsites
Not too bad actually! Centralizing access into the helpers makes a big
difference.
wtf it works
This includes the ability to "shadowban" new users who have not yet been
approved. We do not have UI for approving these users.
Migrate deserving users to new Approved status
Add post fetching helpers as well
The logic in the thread/post stuff is definitely getting redundant, but
I'm not sure I'm yet ready to try to abstract any of it away.
The next thing to do is probably to update blogs and other places that
fetch threads/posts, and delete the old helpers.
Move forums and blogs fully to new helpers
Use the helpers on the landing page too
that was easy!
Fix up some spots I missed
Check user status and use helpers on the profile page
We don't need to do this any more, since our database backups now
include the migration table. The seedfile command also no longer
requires the user to type a password.
This also prevents the Discord history bot from running when it has no
credentials.
Asaf Gartner
bvisness
Ben Visness