Code

Changes between Version 4 and Version 5 of ContribAuthImprovements


Ignore:
Timestamp:
03/22/12 18:37:50 (2 years ago)
Author:
Clueless
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • ContribAuthImprovements

    v4 v5  
    102102 * 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).  
    103103 
     104== Solution 2a: `USER_MODEL` setting == 
     105 
     106Similar to solution 2. Specify a User model via a setting, but don't mount it at django.contrib.auth.User. 
     107 
     108=== Implementation === 
     109 
     110Introduce an `USER_MODEL` setting (not necessarily related to `AUTH` at all) that defaults to `"auth.User"`.  
     111 
     112Here is a branch of django trunk that implements the basic idea: 
     113 
     114 * https://github.com/ogier/django/tree/auth-mixins Also refactors !auth.User into authentication, permissions and profile mixins 
     115 
     116=== Advantages === 
     117 
     118 * Allows any user model, potentially independent of contrib.auth entirely. 
     119 * Existing projects require no migration (though distributable apps might become outdated if they don't respect the setting). 
     120 * 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)`. 
     121 * Doesn't have the circular dependency issue of solutions 1 and 2. 
     122 
     123Optionally: 
     124 
     125 * Split off as much of !auth.User into orthogonal mixins that can be reused. 
     126 * 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. 
     127 * 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. 
     128  
     129Exposing 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. 
     130 
     131=== Problems === 
     132 
     133 * 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. 
     134 * Doesn't solve the analogous problem for any other project. 
     135 
    104136== Solution 3: Leverage App Refactor == 
    105137