Add /register route to auth service #2154
Merged
Conversation
This file contains 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
PedroFonsecaDEV
approved these changes
Apr 16, 2021
DukeManh
approved these changes
Apr 16, 2021
|
@humphd rebase and good to go ? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The work in #2148 revealed a few things about the signup flow that I wanted to fix. First, instead of having the front-end
POSTthe user's Telescope info to the Users service, I'm now proxying it through the Auth service via the/registerroute. I do this in part because I want to make it possible to upgrade the user's access token to include the new info that's being added for them.A user has to be authenticated as a Seneca user (i.e., have a token with the
'seneca'role) before they can register--this part is the same. However, after the user is done filling out the signup form, the front-end canPOST /registeron the auth service, sending the form data for the user. If all goes well, a new user will be created in the Users service, and the Telescope profile data will be used to generate an upgraded access token, which gets returned to the front-end. This will need to get set in the AuthProvider (we need code for this) and then the user sent to the home page.We can land this before or after #2148, and then update the front-end to use this new route.
I've updated and expanded the tests to show how this all works, and to make sure we don't break it. I also refactored the routes to make them a bit less overwhelming to read, putting all the various bits that are related into separate files.