-
Notifications
You must be signed in to change notification settings - Fork 578
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
Clean up other email tokens #1572
Conversation
// for lookups where we don't know the did | ||
await db.schema.createIndex('email_token_token_idx').on('token').execute() |
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 may need to be unique when paired with purpose
to ensure two dids don't end-up with the same token. I believe the passwordResetToken
column dropped below did have this uniqueness constraint on it for that purpose.
(Relatedly, I forget if that index/unique-constraint automatically gets dropped when the column is dropped. If so, I wonder if the DROP INDEX
is not done CONCURRENTLY
and can cause table locking.)
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.
took care of this in a previous PR with a unique index on (purpose, token)
👍
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.
Worth taking a peek at that one comment re: indexing by token
, but by and large this looks great and feels real nice to have cleaned-up.
* lexicons * codegen * email templates * request routes * impl * migration * tidy * tests * tidy & bugfixes * format * fix api test * fix auth test * impl * update constraint name * temporarily disable unconfirmed updates * tidy * fix some tests * validate email syntax
Optional addition on top of #1568
Move account delete & password reset tokens to the new
email_token
table & logic.This cleans up the routes substantially, removes password reset state from the
user_account
table and gets some of this sensitive logic all co-located.The migration is a little bit tricky here because we'll end up breaking some folks' deletes/password resets. But it will just be for a short time and it might be worth it. We can do it in off-peak hours to mitigate the impact