#20313: AnonymousUser should follow custom User implementation
-------------------------------------+-------------------------------------
Reporter: thinkingpotato@… | Owner:
Type: New feature | thinkingpotato
Component: contrib.auth | Status: assigned
Severity: Normal | Version:
Keywords: | Resolution:
Has patch: 0 | Triage Stage: Accepted
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by thinkingpotato):
Replying to [comment:4 ptone]:
> The obvious workaround in current code is to just check if user is
authenticated first, as documented here:
> Is there something more than code conciseness that would be enabled by
setting up a custom anon user? Perhaps I'm missing some of the argument in
favor of doing this.
Let's say you ask an outsourced programmer to write a module that will
enable some kind of model-level authorization mechanism or whatever
requiring user based on current request. And that programmer has no idea
about Django internals. All you define is the interface you both will be
using, which is quite straigthforward: passing MyUser instance as the
first argument. But suddenly it's not MyUser instance anymore,
```request.user``` becomes a AnonymousUser that is substantially different
class, implementing different methods and behaviour. Moreover, you can't
even change that. It just makes no sense. Code conciseness, even if was
the only reason for solving this issue, in my opinion is the most
important one to let people do their stuff easily and logically. Speaking
of my personal preferences, I would rather put one line in my custom User
class, rather than repeat ```is_authenticated``` ~80 times (after looking
at my recent code).
Replying to [comment:5 russellm]:
> Accepting on the basis that there is something that needs to be
addressed here. @ptone makes a good point about checking is_authenticated
first, but I can see how being able to "just use it" could be useful under
some circumstances, and we've been encouraging that behaviour in the days
of non-swappable User models.
>
> Personally, I'm not completely sold that get_anonymous_model() or
ANONYMOUS_USER_MODEL is needed here - that feels a bit like overkill.
However, I'm not sure I've got a substantially better option, other than
some sort of implicit contract about has_* methods returning True (or
something similar)
It feels a bit like overkill to me as well, but on the other hand seems
like a price you have to pay for tight integration between different
Django services.
If I understand you correctly, developers would not be able to use methods
starting with a keyword reserved by Django. Personally, I would be scared
if framework interfered my design decisions so much. On the other hand, I
bet that the first day after introducing it #django IRC would be flooded
with questions on how to use it. Defining a class is clean and simple.
Once sentence in the docs. Everyone who did object programming will
understand it.
--
Ticket URL: <https://code.djangoproject.com/ticket/20313#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/082.b8dd69f18e1319ccf5a92ab917ac66f1%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
