search

freeCodeCamp / classroom

BSD 3-Clause "New" or "Revised" License
143 stars 120 forks source link

Create a RBAC implementation for separation between students and teachers #72

Closed raisedadead closed 2 years ago

raisedadead commented 2 years ago

Originally posted by @utsab in https://github.com/freeCodeCamp/classroom/issues/56#issuecomment-1124009913

We need to create a "role-based access control (RBAC)" implementation for separating things that regular student and teacher users of the app can do.

This needs some additional investigation and proposals.

raisedadead commented 2 years ago

_From https://github.com/freeCodeCamp/classroom/pull/73#discussion_r871815775_

NextAuth (or whatever providers it is configured with) only has the job of verifying and telling you who a user is.

It's the application's job to look at the user (email, user-id, etc.), compare that against a table (with a pre-existing entry for the user's role), and send them to the correct area in the application.

Now, in our case, the sign-up and sign-in pages are technically the same (because of NextAuth), but because we are making an invite-only style application, we have the ability to do some cool things.

  1. First, we have the /login page, which is already good to go.

  2. Next, let's suppose we create a super-admin user.

    This super-admin (user-id) has God mod access across the app. We set its email-id hardwired in the DB (say as a seeding step). And only the person managing the Classroom app (hosting) has access to this email inbox.

    The super-admin uses the same /login page. But because we know who the user is, we can take them to a special "dashboard" page. More on this in a bit.

  3. Next, we create a special page for teachers (/teacher-signup?) to sign-up (with the same NextAuth implementation). When they do, they get onboarded via the verification, etc. we already have in place, but critically we add an "on-hold" flag against their user entry in the DB. The teacher sees a message that they should wait for the admins to approve them.

  4. Next, the super-admin can log in and go to the special "dashboard" where all teachers who signed up recently and are "on-hold" are listed. The admin can flick a checkbox to approve the request(s). This triggers a change in the user's role and assigns them the "teacher" role.

  5. For regular students who join via the invite, we can assign them the "student" role by default. They do not need to go through the approval step.

How does this sound about implementing RBAC? If this sounds reasonable, I can guide you further on how best to proceed with a concrete implementation.

utsab commented 2 years ago

We discussed two possibilities for the login / signup workflow:

  1. Two buttons: one for sign-up-as-a-teacher, one for login
  2. One button: Sign in

Our detailed discussion notes are here.