Did you look into why both methods exist in the first place? I didn't know
the reason.
is_anonymous() preceded is_authenticated(). The concern was that template
code like this:
{% if not user.is_anonymous %}Content for logged in users.{% else %}Content for
non-logged in users.{% endif %}
would show authenticated user content to anonymous users if the user
variable didn't get put in the template context somehow [0].
User.is_authenticated() was added in Django 1.0 to mitigate this [1].
My concern is that if a project doesn't see the deprecation warnings and
doesn't have adequate tests, they may not catch the fact that template code
like:
{% if user.is_anonymous %}
Anonymous content
{% else %}
Authenticated content
{% endif %}
will start showing authenticated content to anonymous users after the
method is removed. I think it's hard to argue that removing the method is
work this risk. Maybe there's room to reduce confusion by deemphasizing
usage of is_anonymous(). This might include removing its usage within
Django itself and undocumenting it.
[0] http://thegarywilson.com/blog/2006/is_authenticated-vs-is_anonymous/
[1] https://github.com/django/django/commit/51705f60b1
On Saturday, April 2, 2016 at 9:37:38 AM UTC-4, Jeremy Lainé wrote:
>
> I have been working on solving #25847 (making User.is_authenticated a
> property), and in the process I was wondering whether we want to keep
> User.is_anonymous at all in the long run.
>
> My reasoning is:
>
> - the documentation makes it quite clear you should use
> request.user.is_authenticated instead of request.user.is_anonymous
>
> - there is no guarantee that request.user.is_authenticated !=
> request.user.is_anonymous. This means a custom user model could make a
> User both anonymous and authenticated (or neither) and we would end up
> with rather surprising results depending on how authentication is
> checked (using is_authenticated or is_anonymous).
>
> Do we know of any custom user models with this unconventional behaviour?
>
> Incidentally I found there is only one place were we django uses
> .is_anonymous internally : django.contrib.auth.backends.ModelBackend,
> all other places use user.is_authenticated as recommended in the
> documentation.
>
> Thanks in advance for your insights!
> Jeremy
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/7726d8f7-210c-4a45-b52c-6d64fb60304a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
