Django Login/Session Not Sticking

[Juergen Schackmann]

Hi all, 

this question refers to this previous question: https://groups.google.com/forum/#!topic/django-users/8IXEvfU72S4. However, it seems like the problem is slightly different, I decided to open a new question:

After my site has been up and running for a while in production, I suddenly have a problem with my users loging into it.

1. I have protected certain views/pages with the login_required decorator and I am also using the django admin.
2. When an anonymous user hits any of these pages, he is redirected to the login page.
3. When this anonymous user adds its credentials, the POST request is successful and he is redirected to the inital page. At the same time, the user gets a new sessionid (as expected)
4. However, now the results get very unreliable. When pressing reload or when navigating to other pages (that require a login), either of the 2 outcomes might happen:

• a) The user is identified and the page is displayed correctly
  
• b) The user is redirect to the login page.

I have checked the content of the session via the shell, and nothing is changing there.

The production site is served via a load balancer and 8 application servers. Even stranger: if I test the same code (with the same settings) on a test server, that is not load balanced and basically has not traffic, everything is working fine.

I am running Django 1.6 on Ubuntu with Apache and mod_wsgi in daemon mode behind SSL and I am using the Session database backend. I am using django-allauth.account for account management/login. My Session settings are like this:

SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_AGE = 60*60*24
SESSION_COOKIE_SECURE = True

So I have the following questions/ideas?

1. Can this be related to loadbalancing in anyway? My understanding was that Django does not need sticky sessions, when the DB session backend is used.

2. Can this be related to a threading issue?

3. Can this be related to high load?

4. Can this be related to a decoding issue: https://github.com/django/django/blob/master/django/contrib/sessions/backends/base.py#L83. However, I have not found any log entries that refer to "Session data corrupted".

Any other hints are welcome.

[Juergen Schackmann]

PLEASE HELP: I am not sure if this is a bug or caused by my code. But this is a serious issue for my production site.

To get some more debug information, I have created this Middleware:

from django.conf import settings

class SessionDebugMiddleware(object):

    def process_response(self, request, response):

            session = request.session

            user = getattr(request, 'user', None)

            if user:

                user=user.id

            session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME, None)

            response['X-Meta-Requ'] = '{0},{1},{2},{3}'.format(session_key, session.get('_auth_user_id'), session.get('_auth_user_backend','---'), user)

            return response

If I hit the refresh button 10 times, 

8 times I will get this header:  X-Meta-Requ:igv0xshezhdxh50kks9x00r0l67mx0sk,None,---,None

2 times I will get this header: X-Meta-Requ:igv0xshezhdxh50kks9x00r0l67mx0sk,330619,django.contrib.auth.backends.ModelBackend,330619

It seems be be random and does not follow any logic.

[Erik Cederstrand]

Den 04/06/2014 kl. 13.55 skrev Juergen Schackmann <juergen.s...@gmail.com>:

> The production site is served via a load balancer and 8 application servers. Even stranger: if I test the same code (with the same settings) on a test server, that is not load balanced and basically has not traffic, everything is working fine.

Are you sure all app servers are running the same code? Same settings.py? DNS load balancing you forgot about? Maybe you have some lingering app server processes that were never shut down? Check the start date of all WSGI processes to be sure.

Erik


PS: You may have sweaty palms, but please don't triple post the same question to the list.

[Juergen Schackmann]

- all app servers are running the same code with same settings.

- DNS load balancing was never used

- just did a htop, no unexpected or old processes

[Mario Gudelj]

I know this may sound silly but is there some kind of JavaScript code that may be messing things up? Had a similar issue before and it was related to JavaScript stupidity.

--
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/593d1369-a6a2-4457-b911-952bb0576877%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Juergen Schackmann]

none of my js is fiddling with sessions/cookies. but there are numerous third party js packages included (for ads etc). so any of those could do strange things, this would also explain why it broke all of a sudden. could you provide more details on the underlying issue that you had. this would help me to search for the issue.

[Juergen Schackmann]

I do have the same issue with django admin, and definitely no custom js there. any other ideas???

[Erik Cederstrand]

Den 10/06/2014 kl. 09.08 skrev Juergen Schackmann <juergen.s...@gmail.com>:

> I do have the same issue with django admin, and definitely no custom js there. any other ideas???

You need to reduce the problem. Scale down to only one app server and re-run your tests. If the problem disappears, it's a concurrency issue (e.g. not using transactions, race conditions in your session code etc.). If not, something is invalidating your sessions.

Log any db activity related to the session table to rule out actual changes to your session data. Then, review any code related to session handling and cookies, including session and cookie timeouts. Also, re-run your tests in a browser where javascript is turned off to rule out client-side session mangling.

Erik

[LaPerl]

Hello all,

I'm not sure if you  discovered the problem, but if you have different types of authentication backends, maybe the problem is on the session objects. Did you do a delete?.

See the NOTE in this chapter: https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#specifying-authentication-backends

Hope it helps

El dimecres 4 de juny de 2014 6:55:38 UTC-5, Juergen Schackmann va escriure: