Changes between Version 17 and Version 18 of ContribAuthImprovements


Ignore:
Timestamp:
04/04/2012 12:39:02 AM (3 years ago)
Author:
russellm
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • ContribAuthImprovements

    v17 v18  
    196196=== Problems ===
    197197
     198 * Is dependent on the App Refactor landing in trunk. This may not occur any time soon.
     199
    198200 * 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.
    199201
     
    239241{{{
    240242class User(models.Model):
    241     identifier = models.CharField()
     243    identifier = models.CharField(unique=True, db_index=True)
    242244    password = models.CharField()
    243245}}}
    244246
    245 `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.
    246 
    247 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.
     247`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.
     248
     249Other 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.
    248250
    249251Along the way, we'll also deprecate AUTH_USER_PROFILE and user.get_profile(), reflecting the fact that there isn't a single "profile" anymore.
     
    266268   - Should profiles be auto-select-related?
    267269   - 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?
    268    - 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)
    269270
    270271 * Form handling for the new User object -- especially !ModelForm handling -- hasn't been fully elaborated.
Back to Top