I think I've found a bug in auth.login.
user = User.objects.get(username=request.POST.get('username', ''))
if user.check_password(request.POST.get('password', '')):
login(request, user)
This raises the following exception:
Exception: 'User' object has no attribute 'backend'
Locatio
Hi --
On Thu, Sep 23, 2010 at 1:38 PM, Yo-Yo Ma 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 contributio
You need to obtain the user by calling auth.authenticate, this sets the
backend to the user.
auth.login expects an user created this way and stores the backend in the
session, if you want to avoid the auth.authenticate you will have to set a
backend in the user yourself.
On Thu, Sep 23, 2010 at
For reference:
http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.login
(look
at the note at the end of "login()" called "Calling authenticate() first")
On Thu, Sep 23, 2010 at 3:56 PM, Santiago Perez wrote:
> You need to obtain the user by calling auth.authenticate, this sets
Hey Jacob, understood. Here's some more details that might help:
class LoginForm(Form):
username = fields.CharField(max_length=40)
password = fields.CharField(max_length=40,
widget=widgets.PasswordInput)
def backend_login(request):
from django.contrib.auth.models import User
from
It should also be noted that I don't have installed "contrib.admin" as
I don't need it. I hope that doesn't matter regarding a separate app,
but I thought I'd mention it.
On Sep 23, 12:53 pm, Jacob Kaplan-Moss wrote:
> Hi --
>
> On Thu, Sep 23, 2010 at 1:38 PM, Yo-Yo Ma wrote:
> > I think I've f
On Thu, Sep 23, 2010 at 2:18 PM, Yo-Yo Ma 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()
I'm simply proposing the idea of having the development server
explicitly set something to indicate a "in development" status, so
that if that does not exist you can make the assumption that the
project is live. I don't like having to check for specific things
like to see if I'm in live or develop
On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma wrote:
> I'm simply proposing the idea of having the development server
> explicitly set something to indicate a "in development" status, so
> that if that does not exist you can make the assumption that the
> project is live.
This is exactly what the set
As for running different configs:
manage.py runserver --settings=settings_test
etc..
On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss wrote:
> On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma wrote:
>> I'm simply proposing the idea of having the development server
>> explicitly set something to ind
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
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. See http://www.joe
Btw, yes I am aware of the paragraph below explaining the confusing
dilemma. That's how I fixed my issue. Thank you Santiago.
On Sep 23, 5:02 pm, Yo-Yo Ma 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
Thanks David, but I'm talking about having something built in. For
instance, passing a variable to the "Development" server to tell it
you're in "Development" seems a bit redundant, no?
On Sep 23, 3:39 pm, "David P. Novakovic"
wrote:
> As for running different configs:
>
> manage.py runserver --s
Did you read my post?
> I don't like having to check for specific things
> like to see if I'm in live or development mode in my settings
I'm talking about having 2 sets of settings, and differentiating them
without having to use stuff like ``import os`` or web server specific
things to discern b
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-
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
previous
The thing is, in production mode you normally have to define where
your settings are anyway, so you pass the unusual settings file name
there, and just use the regular settings.py for your development.
So then you are passing the settings configuration information once in
the production server's c
This link and the comments suggest some good stuff... particularly the
comment from Malcolm and the original post.
http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-production-why-the-hoops/
On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
wrote:
> The thing is, in product
Thanks for the link David. I'm gonna check it it now.
On Sep 23, 6:16 pm, "David P. Novakovic"
wrote:
> This link and the comments suggest some good stuff... particularly the
> comment from Malcolm and the original post.
>
> http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p...
>
> 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 think its fairly simple and definitely positive. If we apply the DRY
principle to the mailing lists this would be a
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 auth
22 matches
Mail list logo
