is_staff, is_active, is_superuser are attributes.
is_anonymous, is_authenticated are methods.
This is insecure if you are not careful while programming:
....# Always true, since it is a method!
It would be nice to find a solution. Here is what I thought:
Make is_authenticated a property which returns a object
which evaluates to the proper boolean value. This object
has a method __call__ which returns the same value.
This is backwards compatible.
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/df236217-bc38-4ceb-8d1e-1da18268c81c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I think we should be asking.. why not? If there's not a good reason not to, let's make it a callable and a property.
I cannot think of much we could do besides monkey-patching the custom-user model.
Do you think the backwards incompatibility is justified here or do you prefer some other solution?
Absolutely not, what are you basing your justification on?
I haven't read the entire thread, did you account for custom user models
that don't inherit from AbstractBaseUser? Do the system checks stil
work? A Metaclass certainly would not, would it?
The problem with these suggestions is that they create a user object during
checks, and that might be an obstacle for some users (side effects and required
initializer parameters are the two most obvious issues).