I understand your points Carl, but I'm more inclined to think about the average django developer and the new comers. Most people don't know or don't want to know what an Authentication Backend is, they just want to write their app. That is why I don't like exposing this kind of detail in the client code. I mean, we can add an optional param to login (backend) for people like you and me but IMO it shouldn't be mandatory and we should fallback to the backend iteration if it isn't specified.
On Fri, May 22, 2015 at 2:14 PM Carl Meyer <[email protected]> wrote: > On 05/22/2015 09:44 AM, Tim Graham wrote: > > Could you elaborate on what use case you are trying to solve? > > > > On Friday, May 22, 2015 at 11:36:21 AM UTC-4, poiati wrote: > > > > Hello guys, > > > > I want to discuss the current login workflow in django. As it is we > > need to call `authenticate` before `login` because we need to set > > the authentication backend in the user model. We can use login > > without authenticate if we set the backend attr manually, but this > > need some implementation knowledge of how authentication backends > works. > > I've run into this more than once in an OAuth or SSO situation, where > I've got confirmation from the identity provider of the user's identity > and I just want to log them in, no further authentication necessary. > Usually I just manually annotate the user with a `backend` attribute and > then call `login`, but I agree with Paulo that login's dependence on > that annotation is a bad API. > > I don't prefer Paulo's proposal of "just try all backends", though; I > think it's best if any user persisted in the session is always persisted > along with explicit knowledge of which auth backend should be used to > fetch that user in future requests. Failing to do that could potentially > result in security problems, I think, depending on details of the > configured auth backends. > > What I would suggest instead is to add an optional `backend` argument to > `login`, defaulting to `None`. If provided, that argument would always > be used, and the `backend` annotation on the user would not be required > or even checked. > > At some point, I could see possibly deprecating the `user.backend` > annotation system entirely, in favor of having `authenticate` return a > (user, backend) tuple, and passing the backend explicitly through the > form back to the login view and into the `login` function. I think that > would be better, but it would also be much more invasive and require > deprecation paths on several APIs, so may not be worth it. > > In any case, adding the optional `backend` argument to `login` is a > small step in that direction that doesn't introduce any > backwards-incompatibility and makes the "manually log a user in" use > case much more straightforward. > > Carl > > -- > 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/555F63F8.3070007%40oddbird.net > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CABqSV%3DJ9pOwStSViZAn9PyuxWncEy48%2BKLT5YLJZ%2BhNwtid1VA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
