Auth backends don't work with HttpResponseRedirect and Django 1.4+?

[Hanne Moa]

I can't get logging in with alternate auth backends to work with Django 1.4 or newer.

Basically:

1. authenticate() works. request.user.is_authenticated() is True

2. Django's own login() seems to work, as request.user is set, request.session is set etc.

3. After the HttpResponseRedirect, request.user is AnonymousUser

This has happened twice now, with different alternate auth backends. I can't get rid of Django 1.3 before this is fixed...

In one project I can call the next view directly (with render) and it Just Works. In the current project, the next view contains a form, and the "login" doesn't survive the POST.

What am I missing? See also the non-solution in http://stackoverflow.com/questions/16119155/django-request-user-not-set-after-redirect

HM

[Sergiy Khohlov]

I have no idea why are you writing this code by yourself ?
This is already done !
Take a look at
https://github.com/django/django/blob/master/django/contrib/auth/views.py

login function is already done and you can use it . Have no sense
to write it by yourself.
Many thanks,

Serge


+380 636150445
skype: skhohlov

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CACQ%3DrreSearLz5zZyu1yZWnAx_CrSOW7u0f%3DnPdVHMMOX4DOhQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Sergiy Khohlov]

Take a look at :
if form.is_valid():
#django.contrib.auth.login
Login(request, form.get_user())
str = reverse('cm_base.views.index')
return HttpResponseRedirect(str)
else:
# Their password / email combination must have been incorrect
pass

you are verifying fields only. No more. And invalid creadentials (
correct for form) are never go to else block

Many thanks,

Serge


+380 636150445
skype: skhohlov

[Hanne Moa]

Why not assume that I have a reason not to use the ready-made stuff?

The User-object has several passwords connected, wuhch represent passwords elsewhere, which can be different. Which password to check is set on the login-page, and after login the only page available is one where those passwords can be changed.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CADTRxJO%2BwGM0GtyECQiNEAQFJq-nqSQEn5vefPGU6oJx%3DJS8PA%40mail.gmail.com.

[Hanne Moa]

That's not my code, that's the first hit on google for my problem. I use django's own login() to login the user.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CADTRxJOnf8EkaR6tU5YMcKQ64GNOrHP7ShGKy2s4Wo6%3Dq1WU%3Dg%40mail.gmail.com.

[Sergiy Khohlov]

Please post a example code.
one user with two password with different permission is not easy to
understand idea for me :-)

Many thanks,

Serge


+380 636150445
skype: skhohlov

> https://groups.google.com/d/msgid/django-users/CACQ%3Drre2CHhJdbX2gwObHOZkioZ-6H0vjCK-ujvBfYPjNewx3g%40mail.gmail.com.

[Tom Evans]

Are you sure sessions are working correctly? Are you setting cookies
(for session or otherwise) with a different host name than you are
serving from?

Use a browser that allows you to inspect and capture web requests
(chrome, firefox etc), capture the login sequence and look at the
cookies that are being set.

Cheers

Tom

[Hanne Moa]

On 14 October 2013 17:06, Tom Evans <teva...@googlemail.com> wrote:

On Mon, Oct 14, 2013 at 1:52 PM, Hanne Moa <hann...@gmail.com> wrote:

> I can't get logging in with alternate auth backends to work with Django 1.4
> or newer.

 

Are you sure sessions are working correctly? Are you setting cookies

(for session or otherwise) with a different host name than you are
serving from?

Thx for the suggestion. With 1.3.1, a secure sessionid and and a csrf token is set. With 1.5.4. the secure session id is also httponly, and the csrftoken is also set. That's the only difference cookie-wise. I think I'll dump the contents of the sessions to see what's going on.

HM

[Hanne Moa]

Turns out: the auth backend that worked in 1.3 but not in 1.4+ was missing a get_user()-method. I added it in and that was that.

HM

[Praveen Madhavan]

Hi,

    Can you please exlpain it further. I am facing the same issue. I have written a get_user() method in my customauthentication.py. My authentication is successful but the subsequent requests show up as anonymous user.

Thanks

Praveen.M

[Hanne Moa]

The fix that worked for 1.4.x did not work for 1.5.x. 

Only thing that worked for 1.5.x was changing how apache called django, by setting WSGIDaemonProcess to "processes=1" or removing "processes" entirely ("threads" can be lots more than one).​ Something has obviously changed in how django does wsgi but I won't be spending more time trying to find out why.

[Scott Simmerman]

I faced a similar issue (request.user becoming anonymous after login) and found

the following solution.  It had to do with the naming convention for the

auth backend under AUTHENTICATION_BACKENDS in settings.py.  I had a custom

auth backend class called PamBackend which I had in a file called PamBackend.py.

I listed it under AUTHENTICATION_BACKENDS as 'auth_backends.PamBackend'.  This

seemed to work ok--authentication was happening as expected, returning a valid

user--but the request.user would disappear after a page redirect.

The key is that the backend name is set in the session when authenticate() is

called (in django.contrib.auth).  It sets the name like this:

   user.backend = "%s.%s" % (backend.__module__, backend.__class__.__name__)

So in my case, the name was set to 'auth_backends.PamBackend.PamBackend'.

For a new http request, django checks the session and gets:

1) the name of the auth backend, and

2) the user id.

It then calls get_user (in django/contrib/auth/__init__.py) which does the following:

1) gets the backend name from the session,

2) checks for a match in settings, and

3) calls the appropriate get_user method from the appropriate backend.

So at this point, my backend name did not match what was in settings.py and

it returned an anonymous user.

-Scott

[shilpa rani]

I am facing similar issue.

How did you check the value of user.backend ??

Thanks,

Shilpa