689 user columns and endpoints

[schroerbrian]

This adds name and organization columns to user table, which we will need for saving case worker users. This also creates a UserController with a create endpoint as well as a user_exists endpoint. The f/e checks the user_exists prior to making requests to create a new user in both Auth0 and our DB. This PR also adds tests for said endpoints.

[katerina-kossler]

can you add a description to your PR?

[schroerbrian]

can you add a description to your PR?

Sure, I have just added one

[schroerbrian]

I have a few security concerns about the changes here. I think due to its central role in our user identity system, the UsersController probably needs authentication and authorization logic on all of its controller methods. I've forgotten the details about exactly what Auth0 sends us, but if you have any questions and have that info handy, I'm more than happy to talk more about the security concerns and how we can safely deal with this.

Thanks for reviewing, Richard! I think I can rejigger things to lock this down. I am going to lay out the current order of operations just to clarify it in my own mind.

1. User submits sign-up form
2. We hit the userExists endpoint to check if user exists in our DB
3. If not, we create them in Auth0
4. User verifies email on our site, we forward to Auth0
5. Auth0 creates user. NB: If they already exist, Auth0 will simply auth them against their servers
6. Following successful Auth0 creation, we hit the create endpoint
7. We establish the user session in React/Front-end

[schroerbrian]

I have a few security concerns about the changes here. I think due to its central role in our user identity system, the UsersController probably needs authentication and authorization logic on all of its controller methods. I've forgotten the details about exactly what Auth0 sends us, but if you have any questions and have that info handy, I'm more than happy to talk more about the security concerns and how we can safely deal with this.

Thanks for reviewing, Richard! I think I can rejigger things to lock this down. I am going to lay out the current order of operations just to clarify it in my own mind.

1. User submits sign-up form
2. We hit the userExists endpoint to check if user exists in our DB
3. If not, we create them in Auth0
4. User verifies email on our site, we forward to Auth0
5. Auth0 creates user. NB: If they already exist, Auth0 will simply auth them against their servers
6. Following successful Auth0 creation, we hit the create endpoint
7. We establish the user session in React/Front-end

Okay so here is the brand new order of operations, woohoo. For a more detailed and clearer explanation see the documentation that I'm working on (WIP)

1. User submits sign-up form
2. User receives verification code in email and submits it in site modal
3. (We store user sign up data [email, name, org] in sessionStorage)
4. Auth0 either signs-up user or logs them in if they already exist (the process is the same). User is redirected to homepage
5. Upon success redirect, we have user info from Auth0 (decoded from url access_token param), this includes JWT token and user ID
6. We make request to our Rails user#create endpoint - we pass user data (from sessionStorage) and user ID in body; we pass JWT token as Authorization header
7. Rails endpoint grabs JWT token and makes request to Auth0 validation endpoint to ensure its validity. Success returns some data including userID
8. The create action checks this userId against the one received from the frontend. If it matches we assume the user is who they purport to be. We create user. If user exists already, we don't care, we don't create user, but we don't send any kind of specific error back either

I will now work on spec'ing this out in a document! Document here (in progress): https://docs.google.com/document/d/1Esfvw3nXnRgeiulCyH0Uc6XQY5FXqSZ_cR8t8XM7_go/edit