Changes between Version 17 and Version 18 of ContribAuthImprovements

Timestamp:

Apr 4, 2012, 12:39:02 AM (12 years ago)

Author:

Russell Keith-Magee

Comment:

Updated some of the issues associated with solutions 3 and 5, based on recent discussions.

ContribAuthImprovements

@@ -196 +196 @@
 === Problems ===
 
+ * Is dependent on the App Refactor landing in trunk. This may not occur any time soon.
+
  * No transparent update path -- requires that third party apps be updated to be "pluggable auth compatible". This means app authors need to convert all !ForeignKey(User) into !LazyForeignKey('auth.User'), and modify any usage of forms etc. This could be considered a benefit, however; Migrating User models is a nontrivial step, and it should probably involve some opt-in engineering. 
 
@@ -239 +241 @@
 {{{
 class User(models.Model):
-    identifier = models.CharField()
+    identifier = models.CharField(unique=True, db_index=True)
     password = models.CharField()
 }}} 
 
-`identifier` is included because it's required by 99% of User models; `password` is included as an active discouragement to people reimplementing (badly) their own password authentications schemes. There is still some discussion as to whether identifier should be unique and/or indexed by default.
-
-Other user information -- name, staff/admin flags, permissions and so on -- are stored on profile models that are linked 1-1 with the User model. In order to make it easier to transition to the new user model, and to avoid coupling to specific profile models, the User model may also implement a delegate pattern for other user attributes. For example, the 'display name' for a user won't be defined by the User object itself; it will be serviced by one of the profile objects associated with the User, but you'll be able to request user.display_name to retrieve the name.
+`identifier` is included because it's required by 99% of User models; `password` is included as an active discouragement to people reimplementing (badly) their own password authentications schemes. 
+
+Other user information -- name, staff/admin flags, permissions and so on -- are stored on profile models that are linked 1-1 with the User model. In order to make it easier to transition to the new user model, and to avoid coupling to specific profile models, the User model may also implement a delegate pattern for other user attributes. For example, the 'display name' for a user won't be defined by the User object itself; it will be serviced by one of the profile objects associated with the User, but you'll be able to request user.display_name to retrieve the name. When multiple profiles specify the same attribute, an AUTH_PROFILES setting will setting the precedence order.
 
 Along the way, we'll also deprecate AUTH_USER_PROFILE and user.get_profile(), reflecting the fact that there isn't a single "profile" anymore.
@@ -266 +268 @@
    - Should profiles be auto-select-related?
    - Should profiles be auto-created if they are missing? If a profile has a required field and it is auto-created, how will that field be filled in? 
-   - How do we determine which profile will service an attribute if both provide an implementation (e.g., two profiles define a display_name attribute -- which display name is used? First registered? Last registered? How is the registration determined? etc)
 
  * Form handling for the new User object -- especially !ModelForm handling -- hasn't been fully elaborated.