Tks Carls, I completely agree with the API design, it can be improved. What I'm really trying here is to keep things simple.
I don't see that importance in keeping the authentication backend information in the http session (maybe I'm missing something), we can always use some kind of audit to handle this kind of information. Let's think straight, we don't need to tell the Auth Backend if settings.AUTHENTICATION_BACKENDS has only one element. So, I have a new proposal: If the application has only one backend we always infer it in the login function. If it isn't, the client needs to provide one explicitly. On Fri, May 22, 2015 at 5:07 PM Carl Meyer <[email protected]> wrote: > Hi Paulo, > > On 05/22/2015 01:49 PM, Paulo Gabriel Poiati wrote: > > 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. > > Logging a user in without authenticating them first is an advanced > technique with serious security implications. If someone "doesn't know > or doesn't want to know what an Authentication Backend is," then they > have no business doing this, and we should absolutely make it very hard > for them to do it without learning about authentication backends first. > > Which backend is persisted with the user in the session is not a minor > implementation detail. It's critical information, because it determines > how and from where that user will be loaded on future requests, which > could have wide-ranging effects on their permissions and authorization. > > I agree with you that the current system of annotating the user object > with an attribute that usually isn't present is bad API, and that it > would be good to have a supported, documented API for this use case. But > I strongly disagree with you that the backend is an implementation > detail which should be hidden in this API. The backend should be more > visible in this API than it is now, not less visible. > > 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/555F8C7A.4010507%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%3DJeg86cLRX9zq-YKdgakJUU9UieO9co0Ajzx2UL7ZdvoQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
