上周一个新的应用场景，带出来了关于django session管理的问题。
公司的另一个App以Widget的形式嵌入我们的页面，就是我们提供一些url，另一个App通过iframe的形式嵌入这些url的respone页面到自己的页面中。
QA发现，当两个App都session timeout后，重新sso登录另一个App, 当打开Widget页面，发现iframe里面嵌入的我们App的页面还处于session timeout状态，只有通过强制刷新才能重新获得respone，不然没有反应。
我开始感觉有点儿奇怪，因为不管我们的App是否session timeout，只要Widget的页面发出url请求，我们的App就会进行相应的响应，没有session timeout直接返回请求内容，session timeout了，进行sso验证，然后进行App自身的authentincation验证，验证通过就解析url请求，进行相应的响应。只要account进行了sso登录，并且在我们App的user表里这个account是可用的，我们就会正常返回。
显然是中间某一步出了问题，因为我本人对django的session管理并不是很熟悉，这块儿的代码的开发者已经不再这个项目中，骤然接手，改起来相当吃力，故周末先学习一下django的Session管理。
django框架启动session只需要在setting.py中配置默认的session中间件，如果自定义了session管理中间件，要配置在django中间件的下面。
MIDDLEWARE_CLASSES = (
...
'django.contrib.sessions.middleware.SessionMiddleware',
'MyAuthenMiddleware.MySessionMiddleware',
...
)
INSTALLED_APPS = (
...
'django.contrib.sessions',
...
)
此后，在有请求时，django就会给request增加一个session的dict，存放session信息。
django提供了四种方式存储session，默认的是存储到DB , 除此之外，还有存储到文件，存储到cache，存储到cookie。
相应的配置也比较简单，在setting.py里面进行 “SESSION_ENGINE”相应的设置。使用cache存储时，好像只支持分布式缓存系统，因为本地缓存保存session的时间太短了。使用cookie存储的时候，django提供了验证浏览器是否支持cookie的功能。因为本项目使用的是默认的存储到DB中的方式，所以对其它方式不是很了解，就不多说了。
django是如何管理DB中的session信息的呢？
当setting.py配置好session相关的MIDDLEWARE_CLASSES和INSTALLED_APP之后，启动项目，django就会启用Session Model层的Session类，并在数据库中生成django_session视图，视图中只有三个字段：session_key,session_date,expire_data.
每当django接受一个新的请求，都会产生一个session，这个session里面会有session_key,session_date,expire_data，当然这个session_key,session_date会被加密（用django project的secret_key进行加密），然后存储到django_session表里。
如果接受到的是一个已记录的尚未expire的session发来的请求，则会更新django_session表中session_key相同的那行记录，主要更新内容包括session_data,和expire_data。
如果session timeout，即expire_data小于当前时间，当这个session发来请求时，session就变成了anonymous，同时，request中的user.name也变成了anonymouser.
以上都是django默认的session管理，当然，开发者也可以利用django提供的方法，对session进行一定的操作。
从request中获取session :session = request.session然后就可以使用相关的方法。
具体请参考: