Hi,
I would like to solicit some feedback regarding some existing tight
coupling between django.contrib.auth and django.contrib admin.
The existing, and nominally swappable user model that ships with django
assumes, for the out-of-the-box application benefit of
django.contrib.admin, that there
Hi Steve,
If it helps at least in the short-term, those fields currently don't need
to be actual database columns. I have a custom user that has these
properties/methods to make work with the admin.
Collin
@property
def is_anonymous(self):
return not self.is_authenticated
Yes, Thank you Colin, I do the same thing already as a work around, I was
just thinking it would be nice if pluggable/swappable user models didn't
have to do this workaround out of the box because this too, is a bit coarse
to my own taste: ultimately, a "superuser" is needed. My first leanings
>
>
> https://github.com/anymail/django-anymail/commit/c07998304b4a31df4c61deddcb03d3607a04691b
>
It happened for real.
--
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
Hi Collin,
Thanks. That's perfect.
Regards,
Carlton
--
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
I don't doubt that timing attacks can work in practise, but the link you've
posted is not this. From the commit message:
> There have not been any reports of attempted exploit in the wild. (The
vulnerability was discovered through code review.)
On Friday, 9 February 2018 09:27:03 UTC+11, Anssi
Hi Ian,
As you describe it here, this sounds quite reasonable. It seems worth a
Trac ticket.
* We need `Return Path` because ...
* Currently possible but ...
* Either document or add new `return_path` parameter.
My initial thought is that a `Note` block in the docs explaining the
approach
