#16262: ValueError when authenticating
-------------------------------------+-------------------------------------
Reporter: mitar | Owner: nobody
Type: New | Status: reopened
feature | Component: contrib.auth
Milestone: | Severity: Normal
Version: 1.3 | Keywords: auth backend
Resolution: | Has patch: 1
Triage Stage: Design | Needs tests: 1
decision needed | Easy pickings: 0
Needs documentation: 1 |
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by jezdez):
* needs_docs: 0 => 1
* type: Bug => New feature
* stage: Accepted => Design decision needed
Comment:
Replying to [comment:13 mitar]:
> Isn't one of Django's principles also loose coupling? I think that in
this particular case it means that the password field of User model could
contain something else than what Django is expecting. OK, it is normal
that `check_password` function cannot be magical and validate the password
if the field contains garbage (from its perspective). But it should also
not blow up.
Django specifically doesn't provide a pluggable interface for the password
hashing algorithm, so arguing for "loose coupling" is kinda a moot point.
I agree the auth system shouldn't blow up of course -- if used as
expected. If you're using it in ways it wasn't meant to be used, that's a
different story.
> Crypt was just an example, the same holds also for apr1 (Apache runtime)
hashing algorithm. Or any other value I would like to store in the
password field of User model which might not contain exactly two `$`.
Right, in that sense it's not at all a bug but a feature request, which is
part of a bigger discussion about the auth backends.
> So concrete case: I cannot store this value
`$1$JDE7PpXQ$8bV7aOArT3P91NHFaI7vpg` in the password field of the User
model. And my other authentication backend knows what to do with that. But
my authentication backend is never called because Django's one throws an
exception. I also cannot store `$apr1$HSSoQQ2h$1S454HzbLe/ewAAWhmSnv.` to
use in another of my backends.
Right, again this is a known limitation of the auth system, but not a
"bug" you trying to make out of that. Marking as DND because I'm not sure
how this should look like. Feel free to bring this topic up on the django-
developers mailing list for further discussion about extending the auth
backend for pluggable password hashing. Note, there might have already
been a discussion about that, so please search the Groups first.
> I really do not understand why it is so hard to add that try/except
around? It would allow Django users to have their own values in the
password field. It is just something useful and good.
Because adding a try block hides the fact that the password you're using
with Django's auth system isn't officially supported by it.
--
Ticket URL: <https://code.djangoproject.com/ticket/16262#comment:14>
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 this group at
http://groups.google.com/group/django-updates?hl=en.
