'User' object has no attribute 'backend' - issue with using auth.login()
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'
Location: C:\Python26\Lib\site-packages\django-trunk\django\contrib
\auth\__init__.py in login, line 80
--
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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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 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-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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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 3:38 PM, Yo-Yo Ma wrote:
> 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'
>
> Location: C:\Python26\Lib\site-packages\django-trunk\django\contrib
> \auth\__init__.py in login, line 80
>
> --
> 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.
>
>
--
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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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 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 3:38 PM, Yo-Yo Ma wrote:
>
>> 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'
>>
>> Location: C:\Python26\Lib\site-packages\django-trunk\django\contrib
>> \auth\__init__.py in login, line 80
>>
>> --
>> 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.
>>
>>
>
--
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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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 django.contrib.auth import login
if request.method == 'POST':
form = LoginForm(request.POST)
if form.is_valid():
try:
user =
User.objects.get(username=request.POST.get('username', ''))
if user.check_password(request.POST.get('password',
'')):
login(request, user)
messages.success(request, 'You\'re now logged
in!')
return
HttpResponseRedirect(reverse('backend_login'))
except User.DoesNotExist:
messages.error(request, 'Incorrect username / password
combo.')
return HttpResponseRedirect(reverse('backend_login'))
else:
form = LoginForm()
data = {
'form': form,
'title': 'User Login'
}
return render_to_response('backend/base.html', data,
RequestContext(request))
Traceback:
File "C:\Python26\Lib\site-packages\django-trunk\django\core\handlers
\base.py" in get_response
100. response = callback(request,
*callback_args, **callback_kwargs)
File "D:\dev\myproject\apps\backend\views.py" in backend_login
25. login(request, user)
File "C:\Python26\Lib\site-packages\django-trunk\django\contrib\auth
\__init__.py" in login
80. request.session[BACKEND_SESSION_KEY] = user.backend
Exception Type: AttributeError at /backend/login/
Exception Value: 'User' object has no attribute 'backend'
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 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/#reportin...
--
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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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 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/#reportin... -- 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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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() before calling
login(). See
http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.login
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 at
http://groups.google.com/group/django-developers?hl=en.
Something.is_live instead of implementation specific is_live settings
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 development mode in my settings. This smells leaky. Think abstraction. A quick search for Django development settings shows http://www.ninjacipher.com/2008/03/02/django-alternate-development-settings-file/ I don't have a solution (well, I do but it involves the addition of an application top-level object). Any thoughts on this topic? -- 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.
Re: Something.is_live instead of implementation specific is_live settings
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 settings.DEBUG flag is for. Use it. Love it. 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 at http://groups.google.com/group/django-developers?hl=en.
Re: Something.is_live instead of implementation specific is_live settings
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 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 settings.DEBUG flag is for. Use it. Love it. > > 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 at > http://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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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 wrote:
> 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() before calling
> login(). See
> http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.login
> 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 at
> http://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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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.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"
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 wrote:
> > 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() 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 at
http://groups.google.com/group/django-developers?hl=en.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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. 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"
> 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
> > wrote:
> > > 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() 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 at
http://groups.google.com/group/django-developers?hl=en.
Re: Something.is_live instead of implementation specific is_live settings
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 --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 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 settings.DEBUG flag is for. Use it. Love it. > > > 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 at http://groups.google.com/group/django-developers?hl=en.
Re: Something.is_live instead of implementation specific is_live settings
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 between the two settings files. Telling your application to use "Live" settings should not have to be coupled to your deployment strategy. Did you look at the link I posted. The blog post offers a terrible solution to a problem that shouldn't exist. On Sep 23, 3:25 pm, 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 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 settings.DEBUG flag is for. Use it. Love it. > > 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 at http://groups.google.com/group/django-developers?hl=en.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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 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. See http://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"
> 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
>> wrote:
>> > 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() 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 at
> http://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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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
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 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. See http://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"
>> 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
>>> wrote:
>>> > 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() 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 at
>> http://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.
Re: Something.is_live instead of implementation specific is_live settings
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 configuration, not every time you run your development server. I think people with any decent sized project have addressed this issue in their own way that suits their own needs. For example we have lots of settings files and just import the relevant settings into a final file. For testing I do what i mentioned in my previous email. Like anything on here, you need to ask whether what you are suggesting would actually be better off as part of the core or if it works just fine as something that people can choose to use themselves... I think most people use whatever system they are happy with and it doesn't get in the way of deployment/development. Thus this fails to meet one of the critical requirements for consideration for inclusion into core. D On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma wrote: > 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 --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 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 settings.DEBUG flag is for. Use it. Love it. >> >> > 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 at > http://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.
Re: Something.is_live instead of implementation specific is_live settings
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 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 configuration, not every time you run your > development server. > > I think people with any decent sized project have addressed this issue > in their own way that suits their own needs. > > For example we have lots of settings files and just import the > relevant settings into a final file. > > For testing I do what i mentioned in my previous email. > > Like anything on here, you need to ask whether what you are suggesting > would actually be better off as part of the core or if it works just > fine as something that people can choose to use themselves... > > I think most people use whatever system they are happy with and it > doesn't get in the way of deployment/development. Thus this fails to > meet one of the critical requirements for consideration for inclusion > into core. > > D > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma wrote: >> 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 --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 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 settings.DEBUG flag is for. Use it. Love it. >>> >>> > 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 at >> http://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.
Re: Something.is_live instead of implementation specific is_live settings
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... > > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic > > > > wrote: > > 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 configuration, not every time you run your > > development server. > > > I think people with any decent sized project have addressed this issue > > in their own way that suits their own needs. > > > For example we have lots of settings files and just import the > > relevant settings into a final file. > > > For testing I do what i mentioned in my previous email. > > > Like anything on here, you need to ask whether what you are suggesting > > would actually be better off as part of the core or if it works just > > fine as something that people can choose to use themselves... > > > I think most people use whatever system they are happy with and it > > doesn't get in the way of deployment/development. Thus this fails to > > meet one of the critical requirements for consideration for inclusion > > into core. > > > D > > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma wrote: > >> 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 --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 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 settings.DEBUG flag is for. Use it. Love it. > > >>> > 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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
> > 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 good way to prevent the same issue being brought to the lists repeatedly. -- 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.
Re: 'User' object has no attribute 'backend' - issue with using auth.login()
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"
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
>
>
>
> 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 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"
> >> 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
> >>> wrote:
> >>> > 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() 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
