Support delegated authentication

[cproctor]

Problem

I want to make it possible for users to sign up, sign in, and reset their passwords without providing an email address. This would resolve multiple issues with Unfold Studio adoption in schools/districts: it would allow us to not collect personally-identifiable information, it would make us not subject to some laws, and it would route around a current issue where school-issued email addresses block all external incoming email.

Proposed solution

Some accounts would be designated as teacher accounts; teachers would be able to create groups and groups would have join codes. (Actually, all of the above are already implemented.) When a new user signs up, they choose one of the following sign-up options:

• Regular: Provide username, password, and email. Behavior as expected.
• External: Sign up with Google. After OAUTH flow, this behaves as Regular.
• Private: Provide username and password. Warning: if you lose your password, there is no way to recover it or to regain access to your account.
• Student: Provide username, password, and group join code. The teacher has sudo capabilities, providing the ability to reset the student account's password, lock their account, as well as viewing and editing all of the student's content, shared and private. When students join in student mode, the teacher can reset the student's password. Additionally, teachers have full visibility into student behavior, so they can hold students accountable for breaking school rules if necessary.

Users can move between account types in the following ways:

• Non-student accounts can become student accounts by providing a join code.
• Student accounts can become non-student accounts when a teacher has enabled the feature.

Details:

• Teachers must be regular or external members.
• User type is not stored in profile; it's inferred based on existence of email address and group memberships.
• Groups can have multiple teachers; every teacher is considered a group owner.

Implementation

This will be a broad-ranging, but not particularly complex issue.

Permissions:

• Create a new mix-in active_user which abstracts the process of identifying the current user, and which returns the active user: in most cases, this is the current user, but when a teacher is in sudo mode, returns the student the teacher is impersonating. Use this in all views and templates instead of request.user.
• Re-work the mixins which implement authentication in views: teachers should be able to view all of their students' stories.

Base template:

• When a teacher is in sudo mode, put a bar across the top of the screen saying something like "Acting as username" with a link to exit sudo mode.

Signup:

• Prior to showing the signup form, present the user with options for
• Provide a route for handling the signup URL described in the next section. New users will be prompted to select a username, with the group code already filled in. If an existing username is entered, the user is prompted to log in, then to confirm joining the group. Existing logged-in users will be prompted to confirm that they want to join the group.

Password reset:

• First prompt the user for their username, then present an appropriate response based on user type:
  • Regular or Google: Email them a password-reset link.
  • Private: Sorry, tough luck. You can't recover your password. (Consider a suggestion to email support if this account was important to you; we could handle on a case-by-case basis.)
  • Student: Send an email to the teacher notifying of the reset request. Tell the user to talk to their teacher.

Group UI:

• Teachers should see a link to groups in their profile.
• Each group detail page has the group code, a link to change the group code (changing the group code does nto invalidate existing group memberships), and a checkbox "Allow students to leave group." Then a listing of all the students in the group. Next to each student is an option to remove the student from the group, and to impersonate the student.
• Also provide a join URL the teacher can email to students, and a QR code to the same URL.

Profile UI:

• Need to rework user profiles generally; they're a mess.
• When an acting user views their own profile, there should be a link to configuration settings, URL probably /users/{username}/profile/settings.
  • When a user is a teacher, indicate this.
  • When current user is a teacher and acting user is a student, show a checkbox to lock the account. This logs out any current logins and prevents login.
  • Show the user's group memberships, with the teachers in each group. With a note explaining that those teachers can view and edit their account.
  • When allowed, show an option to leave group.
  • A field to join a new group using group code.