AnonymousUser has no attribute is_staff/is_superuser (django.contrib.auth)

& a similar problem with AnonymousUser? raising a NotImplementError? if you try to get groups (user.groups.all())

Probably worth fixing the groups issue too then.

Please fix it.

I'm not convinced that there's an issue here; code which doesn't know whether it's been handed a "real" user or an AnonymousUser should always be checking is_authenticated() before doing anything which assumes the user is authenticated.

Something has to be fixed here. From documentation http://www.djangoproject.com/documentation/authentication/:

django.contrib.auth.models.AnonymousUser is a class that implements the django.contrib.auth.models.User interface, with these differences: ...

So documentation should be changed or AnonymousUser? should implement all the methods and fields.

Replying to hauser:

Something has to be fixed here. From documentation http://www.djangoproject.com/documentation/authentication/: django.contrib.auth.models.AnonymousUser is a class that implements the django.contrib.auth.models.User interface, with these differences: ... So documentation should be changed or AnonymousUser? should implement all the methods and fields.

It also says:

set_password(), check_password(), save(), delete(), set_groups() and set_permissions() raise NotImplementedError?.

So maybe we should add to this list **every** possible method from User (yes: .objects, .get_profile() and so on) or simply say:

This class only implements .is_anonymous() and is_authenticated() and .has_perm() so you should **first** check .is_authenticated if you plan to use any other function from User, do not assume that AnonymousUser? has everything User has.

Maybe .is_staff and .is_superuser could be implemented to be a bit more DRY (if you want to place an "admin" link in a site it doesn't make sense to place two 'if' blocks:)

   {% if user.is_authenticated %}{% is user.is_staff %}<link to admin>{% endif %}{% endif %}

On the other methods, for me, it doesn't seem a good idea as AnonymousUser? is not a model and User is, so not all methods make sense.

Comment on this to make a docs patch (the easiest, hence my favourites :P), or decide whether to implement all methods from User...

Hi,

I think AnonymousUser? should have an is_superuser attribute like real users.

The above patch inserts a method (not an attribute). Attention: then " is u.is_superuser" is allways true!.

Marc Fargas, your example is incorrect - placing two {% if %} blocks is not required (a sole internal {% if user.is_staff %} works just fine). Template engine silently skips non-existent attributes/methods calls (see http://www.djangoproject.com/documentation/templates/#variables).

As for the python code which would fail at request.user.is_staff if the user is not logged on, the current behaviour is properly documented. If we want to change that behaviour, we need a design decision here.

I'm attaching a better patch, which uses properties instead of member methods, as per User model contract. It also has groups and user_permissions property implemented, using new class django.db.models.managers.EmptyManager? (which naming conforms to already-existent django.db.models.query.EmptyQuerySet?). The documentation is updated to reflect the changes.

Added tests.

(In [6299]) Fixed #3032 -- Added some useful methods and attributes so that AnonymousUser? can proxy for a User a bit more logically. Patch from semenov.