On Sat, Sep 25, 2010 at 11:13 AM, Harro wrote:
> Authentication = verification
> Login = saving the authenticated user so we remember them.
>
> Putting login on the user model is a bad idea.
> That will only make the whole auth app less flexible than it already
> is.
> What if I have another model
I hope I understand your problem correctly, but authentication is
handled by your authentication backend, not your model. Your backend
can return anything you like (eg Foo) and that is what you'll get when
you call authenticate(). This object is given a .backend attribute by
django.contrib.auth, w
How can an object other than a User login with that function? The
proprietary implementation of User logins is even more of a case to
out login on User, isn't it? If you cant even login a User object
without doing special things to it first, how can you expect to login
a Foo?
On Sep 25, 4:13 am, H
Authentication = verification
Login = saving the authenticated user so we remember them.
Putting login on the user model is a bad idea.
That will only make the whole auth app less flexible than it already
is.
What if I have another model which isn't a user but is able to login.
Besides.. is_activ
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
>
> 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
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
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-
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
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
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
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()
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
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
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
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
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
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
18 matches
Mail list logo
