[DB Schema] User types

[vkWeb]

Discuss your ideas or share your views:

I am updating the database structure & API schemas to reflect the recent decisions we made in our meeting:

• Adding admin as a user role. So now we have three user roles: participants (not exactly a user role but still), organizers & admin(s).
• Allow multiple tags per event.

I have some questions in my mind which we can discuss and resolve. The questions are:

• How admins will create organizers or more admin(s)? like will they invite them or upgrade an existing user?
• Can admins create chapters & events?

Refers to PR #253

cc @nik-john @timmyichen @Zeko369 @ceciliaconsta3 @allella

[allella]

@vkWeb I don't have any recent experience with creating user authentication / authorization systems from scratch. However, I'll throw out another question that may preempt those above and/or help inform the schema on the user fields and tables as it relates to authentication and authorization.

I assume there are patterns, like ACL, and/or libraries out there to cover the basic structure of authentication (Quincy said we'd us just Google logins to start) and authorization (matching roles to permissions to users).

So, are we going to leverage a specific auth package(s) or pattern(s). Or, build the schema and pattern manually.

[vkWeb]

@allella I have no prior experience with any auth package(s). Though I have heard good things about Auth0, I would like to go with what other experienced developers think.

[allella]

Whatever package is used, the MVP suggestion was to support only Google logins to start, and eventually email / password (or perhaps passwordless email logins).

I'm not sure if/how auth services like Auth0 factor into the conversation. It seems like an admin would need to setup a full Auth0 account to get their Chaper instance to work, which would seem to dictate a service.

We'll have a similar 3rd-party service situation with sending email from the app, but in that case the admin should be able to chose the service and configure any SMTP, or else enabling plugins for popular services.

Authentication notes from the Nov 15th meeting.

[Zeko369]

I really think that we don't need Auth0 for MVP, because it would make it harder for users to setup chapter instances. Simple hashed password in the DB (as is currently) should be enough, we should also add email reset_token (and when the token was sent) and email_verification token

[allella]

@Zeko369 Quincy had suggested just Google sign-ins for the MVP.

This may not be MVP, but I had asked if there are suggested packages, not necessarily a 3rd party service, to implement authentication so there's a well supported pattern. That's when Auth0 was mentioned.

If we're just using Google for the MVP then presumably when the authentication is expanded, like to include email logins, then do we see any issue with it breaking MVP users?

I know this will be a beta situation, but logins have a way of causing confusion, so I'm trying to understand how the MVP schema for users / authentication doesn't cause users trouble down the road if we move to a more defined authentication / authorization pattern.

[Zeko369]

Based on the current schema it's setup in a way we can have password auth and any number of social OAuths.

Not that it'll break anything if we switched from using google only to google/fb/github and email/password, but email/password is a separate category of login type, since we're probably going to implement it ourselves and with the rest we just store a string of data from the provider.

[jakesweb]

@vkWeb I think we would have the first user in as an admin and then they can have the option to send invites to users as any of the roles necessary. There needs to be a way to change existing user's roles as they move up and out and this should be part of the admin UI, as well.

As for using any of the authentication packages. Since this is Nodejs with Express, the easiest to use would be passport.js. They have a package for using Google OAuth for the MVP and can be transitioned into other authorization services like Auth0 or others.

[QuincyLarson]

I agree with @Zeko369 that we should just stick with Google as our sole authentication method for MVP.

I've asked @Zeko369 to break any insights in this discussion down into new MVP-labeled issues, which we can then put on our project board: https://github.com/freeCodeCamp/chapter/projects/1