Yeah i got your point and thats totally fine - i'll definitely find a workaround ;-)
Just found a way to describe my point of view in a little different way: * Why is there a need to have Authentication and Authorization in one App - when both answer a totally different purpose? * But the answer - as you said - it might be the more convenient way in 90% of the use cases... And because of that - easier to use. => right..? Just want to make sure thinking abt it this way brings you to the same answer.. I'm a little biased, because for me the union of both is unfavorable. So thanks you took the time to think abt it. Nice job anyway! best regards ludwig Am Sonntag, 28. Oktober 2012 02:05:47 UTC+2 schrieb Russell Keith-Magee: > > > On Sat, Oct 27, 2012 at 7:25 PM, Ludwig Kraatz > <lud...@hotmail.com<javascript:> > > wrote: > >> Hi Russ, >> >> >>> >>> > - The last_login field is in the AbstractBaseUser, but it isn't >>> > documented as a required field. Is this field required for something? >>> > Is it needed as part of AbstractBaseUser? >>> >>> Yes, last_login is required - it's needed in order to generate >>> password reset tokens etc. >>> >>> It isn't documented because we *really* want people to be subclassing >>> AbstractBaseUser, not building their own User from scratch. >>> >> >> >> I totally understand u want people to subclass the AbstractBaseClass. But >> what if some Django based system just doesn't need any passwords at all? If >> All authentification might be handled by LDAP, SSO or whatever.. >> It might be *ok* then to have a password field for every user just set to >> *unusable* (but not nice at all..). But then having the user table always >> being updated on logins is just not necessary. If one (me) maybe even wants >> to store recent actions - as logins - in a completely different app / table >> / db - than the user table would definitely benefit from not being accessed >> without any need on every login. >> >> So I really don't think its the best way to force any subclassed model to >> use the last_login (and password) field. Why not having an >> AbstractPasswordUser and an >> * AbstractNaked-I-Dont-Have-Anything-except-a-username-User? >> >> I really appreciate you're offering the possibility of having Custom >> Users this easy now, but please think again about the password and >> especially the last_login field. >> >> Thanks for your feedback. However, I'm going to say no in this case, for > two reasons. > > Firstly, a framework like Django can't ever hope to suppose *every* > possible use case. That's one of the side effects of being a framework; in > order to make the framework easily usable in 90% of cases, and possible to > use in 95% of cases, you have to throw 5% of cases overboard. That's > unfortunate, but it's also the price you pay for having something easy to > use for 90% of use cases. > > Secondly, because this is Python, there's actually nothing preventing you > from doing exactly what you describe in your own code. Although Django > provides an AbstractBaseUser, there are any explicit type checks for that > specific class. We rely on duck typing when the implemented class is > actually used. The base class is just an implementation assistant, > providing the common pieces that most users will need (and, in the case of > password, we explicitly *don't* want them implementing themselves). > > So - that means that if you want to write a User object that has no > password field, you can do that; the only catch is that you'll need to make > sure you don't ever hit a line of code that expects the existence of a > password field. That means none of the login forms will work, none of the > user creation forms (or createsuperuser) will work, and you'll need to > write your own authentication backend. However, the important part of the > swappable User mechanic -- the ability to make ForeignKey/M2M relations > with *your* User model -- won't be encumbered at all. As far as I'm aware, > with the exception of createsuperuser, all these password-dependent places > should be user-configurable; so, for example, you can specify your own > login form and template for the login view. > > If I'm mistaken on any of this, I'm certainly open to patches that to > remove or weaken the dependency on a specific password field. However, I > don't think we need to ship a super-minimal User base class, if for no > other reason that we *really* want to discourage people from writing their > own implementation of a password field. > > Yours, > Russ Magee %-) > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/3DKNLBzKuVwJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
