New Registration Flow#91
Merged
Merged
Conversation
A better approach to handling registration (that importantly does not involve storing plain text passwords in a database ever) will involve storing a null password hash for an unregistered user. The binary blob is updated to reflect the new schema. A check is added to the check_credentials function to handle a null password hash and prevent the user from logging in even though currently hyperspace will never create such accounts.
Now that password hash can be null, we don't need to require a password when creating a user. The user can be created and then their password can be set later using `hyperspace --mutate-password`.
if a user has a null password hash they will not be able to log in so this can be used to lock the account. It can be unlocked again by setting a password with `hyperspace --mutate-password`.
This function makes it easier to add more ways to retrieve credentials because it can use positive logic and early return if it is successful and leave the negative logic early return for the main function.
They will receive a new randomly generated password and the hash will be updated in the database.
We can stop providing a password when creating the user so that a random one will be generated when they register using the new system. We then capture the password from the registration page to use it when logging in instead of a hard-coded password.
Now that passwords can be generated for students with a null password hash, we can remove the old way of dealing with pending account data. We can remove the code that looks for entries in it during registration, and remove the code that adds credentials to it during account creation. Those are the only references to the table, so we can remove the class for it from the db file, and update the binary blob for the empty db to reflect the new schema.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
To avoid needing to store the credentials for students while we are waiting for them to register, we can switch from pre-generating the credentials when making the accounts to generating them on the fly when the student registers.
In order to represent the state of an account for a student that hasn't registered yet, we need to introduce the possibility of an account having a null password hash. Logic is added to the credential checking function to block access to such accounts until a password hash has been set.
The existing support for creating accounts with passwords is not affected, though the old registration table is removed, so it is no longer possible to create an account with specific credentials that can be retrieved using the registration page. Only a new randomly generated password for an account with no password hash and a given student ID can be obtained.