Rework model to separate user, account and identity

[merwok]

Rework the model to make a distinction between account (representing a person using the website or app) and identify (login information such as email/password, facebook token, google login token, client-generated opaque token for a login-less phone app).

Rename BaseUser to BaseAccount. Projects can override it to add required fields, handle multi-tenancy with an Organization or Team concept, etc. An account is linked to 0 or more identities.

Move email/password fields to EmailIdentity model and table. Add another identity model for facebook fields (#14). Each identity provider has its authentication backend to check credentials and return a token. Account admin can have an inline class for each identity model.

Subclasses of BaseAccount work as custom user model. It is really useful to integrate with everything that needs request.user.

Active sessions (#9) can have foreign key to account and generic foreign key to identity models.

In another ticket: add BaseAdminAccount, a proxy subclass with base admin (filter querysets on is_staff=True, hide is_staff in admin forms, etc). Now admin separates clearly the user accounts (can log into the site with various identities, have custom data, etc.) and the administrators (all privileges, must log with email, no app-custom data, careful zone). And it is still possible to provide automatic app access if you have an admin account with a custom identity class!

[merwok]

References:

• https://codewithoutrules.com/2018/09/21/users-considered-harmful/
• https://twitter.com/jagthedrummer/status/1037812206602252291
• internal Caravan feedback about users in django (hi @mathieuhentges)

Code Without Rules

Never use the word “User” in your code

You’re six months into a project when you realize a tiny, simple assumption you made at the start was completely wrong. And now you need to fix the problem while keeping the existing system running—with far more effort than it would’ve taken if you’d just gotten it right in the first place. Today I’d like to tell you about one common mistake, a single word that will cause you endless trouble. I am speaking, of course, about “users”. There are two basic problems with this word: “User” is almost never a good description of your requirements. “User” encourages a fundamental security design flaw. The concept “user” is dangerously vague, and you will almost always be better off using more accurate terminology.

Twitter

Jeremy Green on Twitter

“Pro tip for saas builders: Users and Accounts should be different things from day 1. Accounts own the stuff, and Users sign in to work in (one or more) Accounts. Splitting later can be hard for anything but the simplest of apps.”

edit I think I misinterpreted the second link. It’s not about naming user vs. account, but about tenancy in SaaS (ownership of created resources) in the context that workers leave companies and that should not mean losing access to stuff.

[merwok]

Another item. At the moment the signup endpoint is open, and creates a User before confirmation. This could lead to bots flooding the database.