Django登录/会话不粘滞 [英] Django Login/Session Not Sticking

问题描述

我的网站在生产中启动并运行了一段时间后，突然我的用户登录出现了问题.

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

我已经使用login_required装饰器保护了某些视图/页面，并且我也在使用django admin. 当匿名用户访问这些页面中的任何一个时，他将被重定向到登录页面. 当该匿名用户添加其凭据时，POST请求成功，并且将其重定向到初始页面.同时，用户获得一个新的sessionid(如预期的那样) 但是，现在的结果变得非常不可靠.当按下重新加载或导航到其他页面(需要登录)时，可能会出现以下两种结果之一: a)识别用户并正确显示页面 b)用户被重定向到登录页面. 我已经通过外壳检查了会话的内容，并且那里什么都没有改变.

I have protected certain views/pages with the login_required decorator and I am also using the django admin. When an anonymous user hits any of these pages, he is redirected to the login page. 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) 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.

通过负载平衡器和8个应用程序服务器为生产站点提供服务.甚至更陌生:如果我在测试服务器上测试相同的代码(具有相同的设置)，那么负载均衡且基本上没有流量，则一切正常.

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.

我在SSL上以守护程序模式在Apache和mod_wsgi上在Ubuntu上运行Django 1.6，并且正在使用会话数据库后端.我正在使用django-allauth.account进行帐户管理/登录.我的会话设置如下:

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

更新

要获取更多调试信息，我创建了以下中间件:

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

如果我点击刷新按钮10次，

If I hit the refresh button 10 times,

• 8次，我将获得以下标头: igv0xshezhdxh50kks9x00r0l67mx0sk，无，---，无
• 2次，我将获得此标头:X-Meta-Requ:igv0xshezhdxh50kks9x00r0l67mx0sk，330619，django.contrib.auth.backends.ModelBackend，330619

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

所以我有以下问题/想法?

So I have the following questions/ideas?

1. 这是否与负载平衡有关?我的理解是，使用数据库会话后端时，Django不需要粘性会话.

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.

这与线程问题有关吗?

这与高负载有关吗?

这是否与解码问题有关: https://github.com/django/django/blob/master/django/contrib/sessions/backends/base.py#L83 .但是为什么那个解码问题应该不一致.而且我还没有找到任何引用会话数据已损坏"的日志条目.

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

欢迎其他提示.

推荐答案

即使有人遇到此问题，也可能是由于SECRET_KEY定义不一致引起的.

Just in case someone is having this issue, it can also be caused by SECRET_KEY definitions not being consistent.

我在设置文件中生成了我的照片(一个错误的决定). 在开发模式下很好，但是一旦WSGI为应用程序提供服务后，就创建了多个实例，每个实例具有不同的密钥. 这将导致哈希中的混合，并报告损坏的会话.

I had mine generated in the settings file (a bad decision). It was fine in development mode, but once the application was served by WSGI, multiple instances were created, each with different keys. This causes the mixup in the hash, and the corrupt session to be reported.

这篇关于Django登录/会话不粘滞的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！