Templates treat non-existing variables as False; therefore; a
request.user somehow failing to get assigned would result in the
template treating the user as they are authenticated (is_anonymous
evaluates False). An is_loggedin would be a more secure option because
if request.user failed to get assigned, the template would treat the
user as anonymous.
I would much rather mistakenly treat an authenticated user as anonymous
than mistakenly treat an anonymous user as authenticated.
is_anonymous could be changed to return the negation of is_loggedin.
Thoughts?
I like this. :-)
I would prefer to declare is_anonymous as deprecated, though, rather
than just make it work transparently again. Then we can consider
removing it in some weeks/months (prior to 1.0). It will always be
dangerous if your above logic is correct -- just tying it to
is_logged_in (is_authenticated?) does not change that -- so we should
force people to use the right method.
Malcolm
To attone for my duplicate thread, I have created a ticket and patch
for this.
http://code.djangoproject.com/ticket/2332
I'm not sure how you "declare is_anonymous as depreciated", Malcom so
I'll leave that to you ;)
It seems that maybe the is_anonymous function is just a way for the
object to say it's either an AnonymousUser object or it's not an
AnonymousUser object.
Hmm ... good points. We document is_anonymous() the way you describe it
in the last paragraph. In the same document, we use it in the slightly
accident-prone fashion your original post (and the thread on
django-users) described.
Considering alternatives in order of decreasing "stuipdness": one fix is
to make improvement in the documentation: "If you are going to put a
"members only" block of text up, you should check that user.id evaluates
as True." It is guaranteed that id == None on AnonymousUser objects.
Another possibility is to call the name "not_anonymous" (but not really
that name, since it's a pretty stupid name). Does "registered" work as a
name?
I guess I prefer finding a better name, rather than hoping for "success
through documentation".
Malcolm
.is_real_user()
.is_known()
{% if user %}
I am logged in.
{% endif %}
to determine if the user is logged in. If the user is not logged in,
then the "user" template variable will not get set and then the above
would evaluate to False.
I also got to thinking about the AuthenticationMiddleware setting
request.user to None instead of an AnonymousUser object (and doing away
with the AnonymousUser class) when the user is not logged in; however,
in views and code it is probably nice to be able to things like
request.user.has_perm('myperm') without having to put an "if user:"
check before it all the time.
But in the templates, this is not the case because you can do {% if
user.has_perm('myperm') %} without doing an {% if user %} check since
the "user" template variable wouldn't exist and would evaluate to False.
So how can we work towards a consensus on the best name for a function
which is the negative of is_anonymous?
On a side note, in templates I don't think you can actually do {% if
user.has_perm('myperm') %} anyway.
Yes I think AnonymousUser is still helpful in python code, and yes I
think we should deprecate is_anonymous before removing it.
> So how can we work towards a consensus on the best name for a function
> which is the negative of is_anonymous?
I think I now vote for is_authenticated since the is_loggedin versions
could more easily be taken the wrong way (by trying to lookup all users
who are logged in). I would be less inclined to try and lookup all
users who are authenticated. Make any sense?
> On a side note, in templates I don't think you can actually do {% if
> user.has_perm('myperm') %} anyway.
Yes, I must have been brain dead. But it would still hold true that
the "user" template variable could just not be set instead of setting
it to an AnonymousUser instance. Hmm, this would break pretty badly
for people using {% if not user.is_anonymous %} in their templates
though since it would then treat all non-authenticated users as
authenticated. So scratch this idea.
You actually can (if you're using RequestContext)::
{% if perms.auth.can_add_user %}
...
{% endif %}
Jacob
Makes sense to me. And I agree that is_loggedin is definately the wrong
name.
Unless someone else suggests something better, my vote is for
is_authenticated too.
I was also keen on Malcom's idea of just using user.id but on further
thought it seems a bit implicit. Explicit is good, right?
Yeah, I tend to agree with this solution (changing the docs to use
is_authenticated or whatever the name of the new method is).
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
I agree -- keep is_anonymous but emphasize is_authenticated in the docs.
Jacob
So Adrian (or other submitters), do you need any more work done to
Gary's patch or can you work it from there? I guess if someone who's
good with their English wants to provide a patch for the documentation
then that would be a help.
http://code.djangoproject.com/attachment/ticket/2332/is_authenticated.2.diff
I'm going to sit down this evening and close some tickets. If nobody
gets to this before then, I'll deal with it then.
Cheers,
Malcolm
I would like to present a case for such a difference. Look at
Amazon.com. They seem to have three user authentication levels: 1)
anonymous users, 2) identified users and 3) authenticated users. I
have been trying to implement a feature like that for Django as an
application, but it dives so deep into the authentication process that
I am probably going to submit a patch.
Of course, said app (or patch) does not yet exist, but I feel the
potential need for distinguishing anonymous from authenticated users
is there.
Regards,
Joost
I'll second that. I work for a large (unfortunately non-django) commercial web property and we have the same basic set of states - anonymous, known, and authenticated. I think it's pretty common.