If a project is using an AUTHENTICATION_BACKENDS with only the default backend in it, and then at some point they need to make some small tweak (case-insensitive lookups, perhaps), so they subclass it and now have an AUTHENTICATION_BACKENDS setting that still has only one backend, basically the same as before but now a subclass of it, I don't think this should mean that now they suddenly have to explicitly specify it in a call to `login()` whereas before they didn't. I think special handling for the default backend is _more_ magical and unexpected than special handling of length-one AUTHENTICATION_BACKENDS. I'm open to the argument that we should always require explicit selection of backend (no default in case of only one backend defined). This trades some convenience in the common case for more explicit behavior. I have no strong feeling either way there. But I'm opposed to special treatment for the default backend.
My reason to propose such a solution was because I think that the backend should be *always* specified. As a tradeoff for the case where you "don't mess with auth backends", I thought that, if unespecified, Django's default one could be used. But you are right when you say that it can be even more magical than handling the case where the auth backends setting has length one.
But, if possible, I'm in favour of following a deprecation path and requiring the backend argument to be mandatory.
-- unai -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20150525180451.GB2689%40def. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
