Thanks for the replies David. I didn't mean to sound brash with the Joel stuff. It's just that the API didn't doesn't feel right. Perhaps changing login to a method or User would fix both problems (explicit better than implicit avoids confusion) because only a User logs in. A User derived from authenticate() already has permission (almost) to log in, so why not let them do it, and raise an exception if they try when they're not .is_active?
user = authenticated('mike', 'openSesame') user.login(request) This prevents the problem from arising, without having to define a __gettattr__ on User for some edge case. It also cleans up the smell. I assume something like this could be changed in 1.4, no? On Sep 23, 5:43 pm, "David P. Novakovic" <davidnovako...@gmail.com> wrote: > To take something constructive from this.. perhaps backend could be a > property that raises a more meaningful exception when it is called the > wrong way? > > I'm not particularly for or against the idea.. but I know raising more > meaningful exceptions is an issue that has received some attention > previously. > > Thoughts anyone? > > On Fri, Sep 24, 2010 at 9:32 AM, David P. Novakovic > > > > <davidnovako...@gmail.com> wrote: > > Apart from being slightly offended at you posting a Joel Spolski link > > to make a point, I'll address the actual issue at hand :P > > > These docs pretty clearly show authenticate happening before login. > > Both in examples and the actual docs. > > >http://docs.djangoproject.com/en/dev/topics/auth/#how-to-log-a-user-in > > > Notice in particular: > > > """ > > Calling authenticate() first > > > When you're manually logging a user in, you must call authenticate() > > before you call login(). authenticate() sets an attribute on the User > > noting which authentication backend successfully authenticated that > > user (see the backends documentation for details), and this > > information is needed later during the login process. > > """ > > > The only time I could see this being a documentation issue is when > > someone is implementing their own authenticate function but this > > breaks the django convention if simply implementing a backend and > > adding it to the list of auth backends and letting authenticate() > > provide the actual authentication. > > > So yep, unfortunately this is an issue for django-users. > > > David > > > On Fri, Sep 24, 2010 at 9:02 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote: > >> It is a problem with Django. I thought it was a problem with the code > >> but it isn't. It's a problem with the documentation, or worse. An > >> function of an API that requires running of another function to alter > >> an object behind the scenes is an architectural problem that needs > >> fixing. Seehttp://www.joelonsoftware.com/articles/LeakyAbstractions.html > >> - and furthermore, if the choice is made to leave problems like this > >> unfixed, they should be documented as so. The current documentation > >> here says, "It takes an HttpRequest object and a User object.". This > >> isn't true, as as simple User object will not suffice. It should say, > >> "It takes an HttpRequest object and a User object that has been run > >> through the function authenticate() first to alter the auth backends > >> that are attached as attributes to it.". > > >> This has very bad code smell, IMHO. > > >> On Sep 23, 3:47 pm, "David P. Novakovic" <davidnovako...@gmail.com> > >> wrote: > >>> This probably should have been posted to django-users anyway. > > >>> Chances are, getting a stacktrace like this one or the last error you > >>> posted are actually problems with your code and not django itself. > > >>> Unless you can show that it is actually a problem with django and not > >>> the way you are using it, it'd be better addressed on django-users > >>> first. > > >>> David > > >>> On Fri, Sep 24, 2010 at 5:41 AM, Jacob Kaplan-Moss <ja...@jacobian.org> > >>> wrote: > >>> > On Thu, Sep 23, 2010 at 2:18 PM, Yo-Yo Ma <baxterstock...@gmail.com> > >>> > wrote: > >>> >> Hey Jacob, understood. Here's some more details that might help: > >>> > [snip] > >>> >> if user.check_password(request.POST.get('password', > >>> >> '')): > >>> >> login(request, user) > > >>> > As Santiago mentioned, you need to call authenticate() before calling > >>> > login(). > >>> > Seehttp://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth... > >>> > for details. > > >>> > Jacob > > >>> > -- > >>> > You received this message because you are subscribed to the Google > >>> > Groups "Django developers" group. > >>> > To post to this group, send email to django-develop...@googlegroups.com. > >>> > To unsubscribe from this group, send email to > >>> > django-developers+unsubscr...@googlegroups.com. > >>> > For more options, visit this group > >>> > athttp://groups.google.com/group/django-developers?hl=en. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Django developers" group. > >> To post to this group, send email to django-develop...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> django-developers+unsubscr...@googlegroups.com. > >> For more options, visit this group > >> athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.