Re: #3011 - Custom User Models -- Call for final review
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. Best regards ludwig -- 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/-/c_YYptksV1AJ. 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.
Re: #3011 - Custom User Models -- Call for final review
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 > > > 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 th
Re: Custom user models in 1.5, not flexible/dry enough?
If you ask me this just points out to some point i mentioned in the original Custom UserModel Thread. I'm trying to reframe it again. I think the current django.contrib.auth *app* somehow behaves like some mixture of django.core._mixins_everyone_should_use_to_make_apps_interoperability and contrib.auth As Ross pointed out in this original thread: it is usefull that everyone uses the AbstractBaseUser - and i'm interpreting now - *because it would be better for interoperability and security* I think its possible and not bad designed at all to have this kinda stuff as core material. So - most apps use authorization features as .*has_perm()* or .* is_superuser*... If decoupling it into clear interfaces this could make custom development much easier without loosing interoperability. i would suggest there shouldn't be a default user attributes like .*is_superuser* because thats very restrictive and nasty to workaround. And its clearly an authorization and no authentication feature. So why not having it somehow like this? (pythonic pseudocode) core.mixins.authentication: *AuthModelMixin*: -abstract- *UniqueIdentifier* *get_authentication_id*(): return UniqueIdentifier *get_long_name*(): return UniqueIdentifier *get_short_name*(): return UniqueIdentifier *DjangoAuthModelMixin*(AuthModelMixin): -abstract- *UniqueIdentifier* *password* *last_login* #(for password reset token etc.) *check_password*() .. *set_password*()... core.mixins.personalyzation: *PersonalDataModelMixin*: -abstract- *first_name* *last_name* *get_long_name*(): return first_name+last_name *get_short_name*(): return first_name core.mixins.authorization *PermissionModelMixin*: IS_SUPERUSER = "not_as_an_user_attribute_necessarily__is_superuser" IS_STAFF = "not_as_an_user_attribute_necessarily__is_staff" -abstractmethod- *has_perm*(): # or maybe even as property for backwards compatibility *is_staff*():return False *is_superuser*(): return False *DjangoPermissionModelMixin*(PermissionMixin): *has_perm*(permission): return self.is_superuser() or self._check_for_permission(permission) *_check_for_permission*(permission): if permission == IS_STAFF: return self.is_staff() else: super(django1.5a.contrib.auth.User,self).has_perm(permission) and contrib.auth: *User*(Mixina,b,c,d): *date_joined* . Didn't think abt every detail - just ment to point out what i would suggest to possibly fit all needs. Best regards and sry for this *little* novel ludwig -- 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/-/36x8Ecpj9scJ. 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.
RedirectView supporting View-Names
Hi, is there a specific reason why the RedirectView does not have a "view_name" attribute and out-of-the-box supporting to reverse it? if self.url: url = self.url elif self.view_name: url = reverse(self.view_name, kwargs=kwargs, request=request) else: return None best regards ludwig -- 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/-/YaZrSyhb7fEJ. 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.
Re: RedirectView supporting View-Names
Well, ... I know about reverse_lazy
Sorry for not explaining myself good enough:
reverse_lazy can't do:
url( 'bar/foo/(?P[0-9]*)/', *RedirectView*( url=
*reverse_lazy*('foo_stuff')
),
url( 'foo/(?P[0-9]*)/', some_view_func, name = 'foo_stuff' ),
What a RedirectView supporting URL Names (...) could do:
url( 'bar/foo/(?P[0-9]*)/', *RedirectView*( view_name = 'foo_stuff' ),
url( 'foo/(?P[0-9]*)/', some_view_func, name = 'foo_stuff' ),
I'm handling it as a view-name instead of url name, because in my opinion,
a view in -some specific URL-Context- always has a name that can be chosen,
that even if the URL changes in some detail, it would remain the same:
* posts_by_specific_user * or something like that - if it is located in
'/user//posts/' or
'/department//users//posts/'
An URL... well i wouldn't know why to name a URL - a URL is more or less
something like a name / identifier. Just not this intuitive understandable
or in some cases longtime-persistent. Changing a URL would somehow result
in changing the url-name (because otherwise the name would result form
something else than the URL itself) - and thats just a real pity because
something that does the same would be named differently.
Benefit for using it like this:
- Caused by whatever decisions (this shouldn't happen but most likely
always will..) the url of a specific VIEW changes, one can now support the
legacy URL because other sites might have linked to it and 301 (Moved
Permanently) Redirect it to the new URL, specified by the view name.
- Or in some other case for APIs when representing a Resource: when
having the same resource at two different URLs, one can easily 302 redirect
it to one *base* view (once again, the URL might change. especially when
using versioned URLs)
What would needed to be changed in *RedirectView*:
By having something like this in the *get()* method:
*get_redirect_url(request, args=args kwargs=kwargs)*
and in *get_redirect_url:*
*elif self.view_name:*
*url = reverse( self.view_name, args=args, kwargs=kwargs)*
one could dynamically pass those url args and kwargs, of a dynamic url
regarding to https://code.djangoproject.com/ticket/15273:
i don't understand why such a basic concept like named urls/views are
somehow integrated in django (template tag: url) but in this case just
accessible
through nasty workarounds (reverse_lazy). In my opinion a workaround like
this often just points out, that something is probably unfinished. And in
my opinion this is definitely the case when looking at RedirectView and
those .. view-names .. because some important functionality is not
available.
So - i would really appreciate having this functionality (as far as i don't
miss anything you guys thought about, that speaks against it).
best regards
ludwig
--
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/-/39XYBkpXwncJ.
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.
