Changes between Version 4 and Version 5 of ContribAuthImprovements

Timestamp:

Mar 22, 2012, 8:37:50 PM (13 years ago)

Author:

Alex Ogier

Comment:

added solution 2a (a USER_MODEL setting independent of auth.User)

ContribAuthImprovements

@@ -102 +102 @@
  * Has unpredictable failure modes if a third-party app assumes that User has a certain attribute or property which the project-provided User model doesn't support (or supports in a way different to the core auth.User model). 
 
+== Solution 2a: `USER_MODEL` setting ==
+
+Similar to solution 2. Specify a User model via a setting, but don't mount it at django.contrib.auth.User.
+
+=== Implementation ===
+
+Introduce an `USER_MODEL` setting (not necessarily related to `AUTH` at all) that defaults to `"auth.User"`. 
+
+Here is a branch of django trunk that implements the basic idea:
+
+ * https://github.com/ogier/django/tree/auth-mixins Also refactors !auth.User into authentication, permissions and profile mixins
+
+=== Advantages ===
+
+ * Allows any user model, potentially independent of contrib.auth entirely.
+ * Existing projects require no migration (though distributable apps might become outdated if they don't respect the setting).
+ * Apps can explicitly signal their support of this new setting by using it and not referring to django.contrib.auth.User. For example, foreign key fields can be specified as `models.ForeignKey(settings.USER_MODEL)`.
+ * Doesn't have the circular dependency issue of solutions 1 and 2.
+
+Optionally:
+
+ * Split off as much of !auth.User into orthogonal mixins that can be reused.
+ * Modify !auth.User to inherit these mixins. Care must be taken to ensure that the database expression of the new User model is identical to the old User model, to ensure backwards compatibility.
+ * Unrelated and third-party apps can indicate that they depend on various orthogonal mixins. For example, contrib.admin can specify that it works with !auth.User out of the box, and with any model implementing !PermissionsMixin if you supply your own login forms.
+ 
+Exposing pieces of !auth.User as mixins is optional, and potentially advantageous for any solution that allows you to define your own user models, such as solution 2.
+
+=== Problems ===
+
+ * Doesn't address the !EmailField length problem for existing users. We could address this by having a User model (reflecting current field lengths) and a new !SimpleUser (that reflects better defaults); then use global_settings and project template settings to define which User is the default for new vs existing projects.
+ * Doesn't solve the analogous problem for any other project.
+
 == Solution 3: Leverage App Refactor ==