On Thu, Sep 23, 2010 at 1:38 PM, Yo-Yo Ma <baxters...@gmail.com> wrote:
> I think I've found a bug in auth.login.
Thanks for the report.
However, for this to be useful, we're going to need a *lot* more
information -- a complete traceback, the code you used to trigger the
error, etc. Quoting from the contribution guide [1]: "Do write
complete, reproducible, specific bug reports. Include as much
information as you possibly can, complete with code snippets, test
cases, etc. This means including a clear, concise description of the
problem, and a clear set of instructions for replicating the problem.
A minimal example that illustrates the bug in a nice small test case
is the best possible bug report."
Remember: this code is used every time anyone logs into any Django
site. That means across the entire Web this code path gets executed
roughly seventy gazillion times a day. So if there is a bug in it,
it's a very specific edge-case. We need to know exactly what that edge
case is.
Thanks again!
Jacob
[1] http://docs.djangoproject.com/en/dev/internals/contributing/#reporting-bugs
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
As Santiago mentioned, you need to call authenticate() before calling
login(). See http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.login
for details.
Jacob
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
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
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?
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?
Django's auth design is fine for a huge number of django developers, I
get the feeling that people here are skeptical that you have found an
architectural/design bug. If you're absolutely certain this isn't
possible for you, then keep pursuing this. But be wary that doing so
might distract a lot of people from other tasks, I hope it's worth it!
I like the idea of improving the exception raised when .backend is
missing. I think working on a patch to improve the exception raised
would be a perfectly sensible improvement to django.
Cheers,
Will
As far as django.contrib.auth is concerned it does. If your login
forms extend from django.contrib.auth.forms.AuthenticationForm, you
wouldn't be able to log in using an inactive account.
The help text for is_active also clearly indicates the intended usage
of this flag:
"Designates whether this user should be treated as active. Unselect
this instead of deleting accounts."
Of course, if you work around all that, and don't use most of the
contrib.auth framework, then you can use it to mean anything you like.
Cheers
Tom