> About this, I just thought that the authenticate method should require > an active user. But it won't hurt to check myself or use the default > AuthenticationForm.
This was my understanding as well, from reading the docs. I would consider an "is_active = False" to be the same as user/password did not match. After all, the main logic behind is_active is we want to "delete" a user without actually deleting him (to not create missing foreign keys). I have not looked further into this, I just blindly assumed that a user that is authenticated has both supplied correct username/password and can actually login (ie. is_active). The inverse situation, where we would want to check a user/pass even if the user cannot login, is far less likely. Maybe it would be appropriate to make the situations more explicit. For example, is_valid_user() [user exists, passwords match] and is_authenticated() [is_valid_user() and can actually use the system]. The method names need work, but I think this is a valid issue -- maybe at least make this more explicit in the docs. Norbert --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
