May be create AnonymousBaseUser with parts that are compatible to
AbstractBaseUser in `base_user.py` and use that as base class for
AnonymousUser. Also, update_last_login function can be moved to
`base_user.py` so that it can be reused.
--
Ticket URL: <https://code.djangoproject.com/ticket/29381>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* cc: Carlton Gibson (added)
* status: new => closed
* resolution: => needsinfo
Old description:
> This is more of an idea than bug but most of the time when need to use
> authentication without using `contrib.auth` one needs to rewrite some of
> the parts that can be reused if it were in base_user when the interface
> is similar to django.contrib.auth.
> I am mostly talking about update_last_login function and AnonymousUser
> when custom user is derived from AbstractBaseUser.
>
> May be create AnonymousBaseUser with parts that are compatible to
> AbstractBaseUser in `base_user.py` and use that as base class for
> AnonymousUser. Also, update_last_login function can be moved to
> `base_user.py` so that it can be reused.
New description:
----
This is more of an idea than bug but most of the time when need to use
authentication without using `contrib.auth` one needs to rewrite some of
the parts that can be reused if it were in base_user when the interface is
similar to django.contrib.auth.
I am mostly talking about update_last_login function and AnonymousUser
when custom user is derived from AbstractBaseUser.
May be create AnonymousBaseUser with parts that are compatible to
AbstractBaseUser in `base_user.py` and use that as base class for
AnonymousUser. Also, update_last_login function can be moved to
`base_user.py` so that it can be reused.
--
Comment:
Hi Sagar. Thanks for the input.
I'm going to close this as `needsinfo` as is. The general idea is ''Yeah,
possibly'' but it's too vague to be actionable in its current form.
If you want to push this forwards then I would recommend an exploratory
PR: make some (small) changes; what tests break?; what does it allow you
to do?; etc. From there we've got something concrete to assess. Does that
make sense?
Please feel free to re-open this issue if you come up with something
concrete along these lines!
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:1>
Comment (by Sagar Chalise):
Opened up a PR: https://github.com/django/django/pull/9948
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:2>
* status: closed => new
* has_patch: 0 => 1
* resolution: needsinfo =>
Comment:
Thanks Sagar. I'll re-open so we can have a look.
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:3>
* type: Uncategorized => New feature
* version: 2.0 => master
* component: Uncategorized => contrib.auth
Comment:
Hi Sagar. This is at least related to #20313. Q: How are you specifying
your custom `AnonymousUser` class?
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:4>
* needs_better_patch: 0 => 1
* stage: Unreviewed => Accepted
* needs_tests: 0 => 1
* needs_docs: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:5>
* needs_better_patch: 1 => 0
* stage: Accepted => Unreviewed
* needs_tests: 1 => 0
* needs_docs: 1 => 0
Comment:
Well, I hadn't thought of scenarios regarding swappable anonymous user,
the simple use case I am seeing is similar to `AbstractBaseUser` that is
recommended as base class of custom user in django documentation. The
methods and attributes that are available in `AbstractBaseUser` are
availabe in `AnonymousBaseUser`. This way I see users creating
`AnonymousUser` class based on `AnonymousBaseUser` if they need to
implement AnonymousUser on their own especially in authentication
middleware and when not using `contrib.auth`.
Maybe something like:
{{{
class AnonymousUser(AnonymousBaseUser):
pass
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:6>
Comment (by Carlton Gibson):
Yes, I see how the patch is meant to work **but** unless/until we have
#20313 in play custom anonymous users simply aren't supported. (In that
case there's little motivation for this change.)
Are you using a custom anonymous user yourself? If so, how are you
switching it in? With a custom middleware? (If not, why do you want this
change?)
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:7>
* needs_better_patch: 0 => 1
* stage: Unreviewed => Accepted
* needs_tests: 0 => 1
* needs_docs: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:8>
* needs_better_patch: 1 => 0
* stage: Accepted => Unreviewed
* needs_tests: 1 => 0
* needs_docs: 1 => 0
Comment:
Yes, when I avoid `contrib.auth` I need to rewrite the part I moved to be
used by my custom authentication middleware. I think it makes sense to
provide the interface similar to `AbstractBaseUser` for maybe
`AbstractAnonymousUser` just for code reusabilty. Obviously this can be
thought of for other stuffs such as backends as well where there is no
need of `Permission` model.
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:9>
* needs_docs: 0 => 1
* needs_better_patch: 0 => 1
* needs_tests: 0 => 1
* stage: Unreviewed => Accepted
Comment:
Please stop changing the flags on the ticket.
Accepted means "Yes, this is a reasonable ticket" — Unreviewed just means
someone else has to make the same decisions.
I reviewed the patch: it does need improvement tests and docs etc. When
those points are addressed it's OK to unflag those boxes.
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:10>
Comment (by Sagar Chalise):
Sorry for that, I was just replying to your queries and didn't mean to
make any changes to ticket status.
Replying to [comment:10 Carlton Gibson]:
> Please stop changing the flags on the ticket.
>
> Accepted means "Yes, this is a reasonable ticket" — Unreviewed just
means someone else has to make the same decisions.
>
> I reviewed the patch: it does need improvement tests and docs etc. When
those points are addressed it's OK to unflag those boxes.
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:11>
Comment (by Abhijeet Pal):
Hi, the ticket https://code.djangoproject.com/ticket/20313 was never
merged. Do you this ticket is still relevant then maybe I can contribute
to it without worrying about 20313?
--
Ticket URL: <https://code.djangoproject.com/ticket/29381#comment:12>