Skip to content
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

Use HarperDB's user/role system to create a simple auth system #16

Open
Ethan-Arrowood opened this issue Feb 13, 2018 · 1 comment
Open
Labels
Authentication 🔒 Anything to do with user authentication (including admin auth) Beta 🚀 Issues describing features for our Beta release

Comments

@Ethan-Arrowood
Copy link
Member

Ethan-Arrowood commented Feb 13, 2018

Combine with json web tokens and JSON web key sets to make a super secure API I'd love to do all that but it would require an additional server and I truly believe we can make BorrowIt "serverless"

@Ethan-Arrowood Ethan-Arrowood added Beta 🚀 Issues describing features for our Beta release Authentication 🔒 Anything to do with user authentication (including admin auth) labels Feb 13, 2018
@Ethan-Arrowood
Copy link
Member Author

Idea 1:

User signs up using basic sign up form (Username (cannot be changed), Email (will not be changed except via an Admin override), Password (user can change at any time))
This data is sent to HDB with the add_user operation

If everything checks out* the callback function should dispatch a secondary insert operation that contains the username (hash_id) and the user's email. This is stored in a users table.

*Satisfies DB user rules (available username, syntactically acceptable password). The client will do a preliminary validation check of username, email, and password. Before add_user operation is sent, use an asynchronous username check against list_users. (Actually don't do this because then we gotta send a ton of data to the client and its unnecessary). The add_user operation will return an error if something goes wrong; share the error with the user appropriately.

The user is then asked to fill out some additional information:

  • Name
  • School (Optional)
  • Company (Optional)

Information provided is added to their user record in the users table. Their email is stored in this record as well.

When a user logs in successfully, create the Basic authorization token and store it in localstorage. Whenever the user makes a request from the client send the HarperDB request with their token.

Additional Details:

  • Requires a customer role with proper access configuration in order to use with BorrowIt
  • A user can reset their password or request it to be reset by providing their username. In order to do this safely I believe we should send an email to the email on file under the provided username. In this email will be random key (this key has been added to the user record under passwordResetSecret). They return to the page (from which they requested to reset their password). Enter the key as well as their new password. The client makes a request to HDB and asks for the passwordResetSecret from the user record. If this key matches the one in the email then a secondary request is made to HDB that updates the user's password via alter_user.
  • Email can be changed using a similar method but must be done from within the app maybe? I think restricting email changes (unless facilitated via an Admin account) would be a good move at first. Good DTR feature.
  • This auth system will let us use the user's account across multiple HackWITus applications as it is not tied to any specific application. At first the users table should exist under the BorrowIt schema; however, if we were to create another application then we can move all our users to a more general schema such as HackWITusUsers. This is super DTR but just putting it here because ✨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Authentication 🔒 Anything to do with user authentication (including admin auth) Beta 🚀 Issues describing features for our Beta release
Projects
None yet
Development

No branches or pull requests

1 participant