#18616: New auth signal: user_login_failed
-------------------------------------+-------------------------------------
Reporter: micolous | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Ready for
Has patch: 1 | checkin
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by PaulM):
I'd strongly prefer that we didn't send the password in a signal. I
realize that this could be (ab)used for things like "you just tried to log
in with your mother's maiden name, and we've switched to requiring the
name of your first dentist!", or it could be used slightly more
legitimately to chain into some other kind of system that acts kinda like
a backend but not really. Those use cases should really be their own auth
backend. I think this is primarily useful for logging (and acting on)
failed login attempts. In that case, the actual password used probably
shouldn't be passed along.
As the original poster said, since the credentials are a dict we don't
know in advance which field is the password (or otherwise sensitive). Can
we re-use the filtering system we already have in place to remove
passwords from tracebacks?
--
Ticket URL: <https://code.djangoproject.com/ticket/18616#comment:15>
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
