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 = request.user
session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME,
None)
x_meta_requ = '{0},{1},{2},{3}'.format(session_key,
session.get('_auth_user_id'), session.get('_auth_user_backend','---'),
user.id)
response['X-Meta-Requ'] = '{0},{1},{2},{3}'.format(session_key,
session.get('_auth_user_id'), session.get('_auth_user_backend','---'),
user.id)
return response

If I hit the refresh button 10 times,
8 times I will get this
header: 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.

Post by Juergen Schackmann
Hi all,
https://groups.google.com/forum/#!topic/django-users/8IXEvfU72S4.
However, it seems like the problem is slightly different, I decided to open
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
- 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
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?
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 = request.user
session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME,
None)
x_meta_requ = '{0},{1},{2},{3}'.format(session_key,
session.get('_auth_user_id'), session.get('_auth_user_backend','---'),
user.id)
response['X-Meta-Requ'] = '{0},{1},{2},{3}'.format(session_key,
session.get('_auth_user_id'), session.get('_auth_user_backend','---'),
user.id)
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.

[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]

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

Post by Juergen Schackmann

Post by Juergen Schackmann
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.

[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.

Post by 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

Post by Juergen Schackmann

Post by Juergen Schackmann
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.

--
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
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
<https://groups.google.com/d/msgid/django-users/593d1369-a6a2-4457-b911-952bb0576877%40googlegroups.com?utm_medium=email&utm_source=footer>
.
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.

Post by 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.

Post by 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

Den 04/06/2014 kl. 13.55 skrev Juergen Schackmann <

Post by Juergen Schackmann
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.

--
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
<javascript:>.
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
<https://groups.google.com/d/msgid/django-users/593d1369-a6a2-4457-b911-952bb0576877%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Juergen Schackmann]

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

Post by 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.

Post by 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.

Post by 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

Den 04/06/2014 kl. 13.55 skrev Juergen Schackmann <

Post by Juergen Schackmann
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.

--
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
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
<https://groups.google.com/d/msgid/django-users/593d1369-a6a2-4457-b911-952bb0576877%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Erik Cederstrand]

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

Post by Juergen Schackmann
Hi all,
https://groups.google.com/forum/#!topic/django-users/8IXEvfU72S4.
However, it seems like the problem is slightly different, I decided to open
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
- 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
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?
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.