Changes between Version 8 and Version 9 of MultipleAuthBackends


Ignore:
Timestamp:
02/27/2006 04:55:28 PM (10 years ago)
Author:
Simon Willison
Comment:

Open ID link

Legend:

Unmodified
Added
Removed
Modified
  • MultipleAuthBackends

    v8 v9  
    118118
    119119== Suggestions ==
    120 It makes a lot of sense to store a cache of a user object as a django model, no matter what the authentication scheme, so it might very well be useful to just go ahead, reduce the Users models to its barest core, and I would add an (optional) Expiration date for automatic cache/culling (ie, always check the db first, then try everything else).  (It may even be useful to add Expiration dates to permissions/groups.)  I'm also thinking that many of the Credential types should just all be models in their own right with a Many-to-Many relationship with the base User class (a user could be very likely to have multiple Credentials, and there might be the occaisional need for "Group Credentials"). Once the subclassing system is in place, all of the Credential models should be subclasses of each other, probably, for good Pythonic OO-ness.  Probably most DB Credentials would want Expiration dates, too.  This would be a useful generic/easy system for those GET confirmation Credentials that people do.  Finally, keep in mind that not all Credentials will have a username/password combo.  GET Credentials will probably be some random string or hash.  OpenID Credentials are URLs (tied to remote server response signatures and remote server spam white/blacklists).  Making Credentials first-class models would help make it easier to remove most of the cases where a seperate User model might be necessary (ie, OpenID users could share the same base User model that Django users do, and someone can use the very same base model if they happen to use both). --Max Battcher
     120It makes a lot of sense to store a cache of a user object as a django model, no matter what the authentication scheme, so it might very well be useful to just go ahead, reduce the Users models to its barest core, and I would add an (optional) Expiration date for automatic cache/culling (ie, always check the db first, then try everything else).  (It may even be useful to add Expiration dates to permissions/groups.)  I'm also thinking that many of the Credential types should just all be models in their own right with a Many-to-Many relationship with the base User class (a user could be very likely to have multiple Credentials, and there might be the occaisional need for "Group Credentials"). Once the subclassing system is in place, all of the Credential models should be subclasses of each other, probably, for good Pythonic OO-ness.  Probably most DB Credentials would want Expiration dates, too.  This would be a useful generic/easy system for those GET confirmation Credentials that people do.  Finally, keep in mind that not all Credentials will have a username/password combo.  GET Credentials will probably be some random string or hash.  [http://openid.net/ OpenID] Credentials are URLs (tied to remote server response signatures and remote server spam white/blacklists).  Making Credentials first-class models would help make it easier to remove most of the cases where a seperate User model might be necessary (ie, OpenID users could share the same base User model that Django users do, and someone can use the very same base model if they happen to use both). --Max Battcher
    121121
    122122
     
    132132
    133133I don't believe zope does things that way anymore. That first link looks to be more a step along the way than a final implementation. --Joseph Kocherhans
    134 
    135 == Open ID ==
    136 
    137 Whatever solution is created for this should support the [http://openid.net/ Open ID] authentication model. There is already [http://www.openidenabled.com/openid/libraries/python a Python module] implementing most of the protocol.
Back to Top