NOTE: This issue serves as an overview of the new user-verification flow and to keep track of the various issues related to it. Broad discussions about the overall method goes here, specific discussions about implementation detail goes into the respective issues.
Description
Our current method for handling user verification is flawed as it requires the server to know the user's token and to verify directly. While this prevents request forgery, it requires us to save more data on the users than we should. Instead, we should verify through Kitsu that the user in question has access to the account.
We might want to tie the verification to an account on our side so we don't need to store their token and so we don't need to go through that process again each time the user gets a new token.
NOTE: This issue serves as an overview of the new user-verification flow and to keep track of the various issues related to it. Broad discussions about the overall method goes here, specific discussions about implementation detail goes into the respective issues.
Description
Our current method for handling user verification is flawed as it requires the server to know the user's token and to verify directly. While this prevents request forgery, it requires us to save more data on the users than we should. Instead, we should verify through Kitsu that the user in question has access to the account.
Implementation
We might want to tie the verification to an account on our side so we don't need to store their token and so we don't need to go through that process again each time the user gets a new token.