uWSGI 使用基于数据库的方式会话

添加数据库配置

 

DATABASES = {     'default': {         'ENGINE': 'django.db.backends.sqlite3',         'NAME': '/tmp/cache_session.db',                       } }

   

生成数据库

 

[root@mail my_django]# ./manage.py  syncdb Creating tables ... Creating table auth_permission Creating table auth_group_permissions Creating table auth_group Creating table auth_user_user_permissions Creating table auth_user_groups Creating table auth_user Creating table auth_message Creating table django_content_type Creating table django_session Creating table django_site   You just installed Django's auth system, which means you don't have any superusers defined. Would you like to create one now? (yes/no): y Please enter either "yes" or "no": yes Username (Leave blank to use 'root'): E-mail address: Error: That e-mail address is invalid. E-mail address: m1@xx.com Password: Password (again): Superuser created successfully. Installing custom SQL ... Installing indexes ... No fixtures found

   

    生成的这个/tmp/cache_session.db，我们可以直接查看，由于它是包含非ASCII码因此，可以使用stings命令，例如：

   

[root@mail tmp]# strings  cache_session.db |more

 

admin的使用

 

    为了测试cookie的使用，我们来使用一下admin。

 

    在settings文件中添加以下配置，注意黑体字部分：

 

LANGUAGE_CODE = 'zh-CN'   INSTALLED_APPS = (     'django.contrib.auth',     'django.contrib.contenttypes',     'django.contrib.sessions',     'django.contrib.sites',     'django.contrib.messages',     'django.contrib.staticfiles',     'django.contrib.admin',     'django_memcached', )

   

    在urls文件中添加以下配置，注意黑体字部分：

 

from django.contrib import admin from django.conf.urls.defaults import * admin.autodiscover()     urlpatterns = patterns('',       # Uncomment the next line to enable the admin:      url(r'^admin/', include(admin.site.urls)),       ('^hello/$', hello),

   

    生成数据库：

   

[root@mail my_django]# ./manage.py  syncdb Creating tables ... Creating table django_admin_log Installing custom SQL ... Installing indexes ... No fixtures found.

 

安装sqlite3的客户端程序

 

    为了更好的访问sqlite数据库，我们下载并解压它的客户端：

 

[root@mail ~]# wget http://www.sqlite.org/sqlite-shell-linux-x86-3070701.zip   [root@mail ~]# unzip sqlite-shell-linux-x86-3070701.zip Archive:  sqlite-shell-linux-x86-3070701.zip   inflating: sqlite3

   

    它的使用非常简单，只要将其解压并执行就好了，例如：

 

[root@mail ~]# ./sqlite3  /tmp/cache_session.db SQLite version 3.7.7.1 2011-06-28 17:39:05 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> sqlite>

   

    简单的了解一下用法：

 

    查看数据库中有什么表：

 

sqlite> .tables    auth_group                  auth_user_user_permissions auth_group_permissions      django_admin_log          auth_message                django_content_type       auth_permission             django_session            auth_user                   django_site               auth_user_groups sqlite>

   

    查看表的结构：

 

sqlite> .schema django_session CREATE TABLE "django_session" (     "session_key" varchar(40) NOT NULL PRIMARY KEY,     "session_data" text NOT NULL,     "expire_date" datetime NOT NULL ); CREATE INDEX "django_session_3da3d3d8" ON "django_session" ("expire_date");

   

    查看auth_user表中的记录：

 

sqlite> select * from auth_user ; 1|root||| m1@xx.com |sha1$a616f$a2bea4cf31633f80e9e6138ae3ca956635643f7b|1|1|1|2011-07-30 16:45:57.927539|2011-07-29 21:03:35.348291 2|me||| m2@xx.com |sha1$283e3$4d5152213b8885bed35a6210c97385d3e544614e|1|1|1|2011-07-30 12:35:52|2011-07-30 12:35:52 sqlite>

   

    查看auth_user表中的记录：

 

sqlite> select * from django_session;

   

    返回为空，可见现在还没有任何数据，因为我们还没有进行过任何访问。在下面的访问测试之后，将会被存储数据。

 

访问测试

 

    打开浏览器接受cookie，按照以下步骤：

 

    分为五步来完成，首先找到浏览器的“工具”选项——>“隐私”——>“高级”，在高级这个界面上，选择“覆盖自动cookie处理”，如下图：

 

   

 

    然后就可以访问http://www.xx.com/admin/:

 

   

 

    点击登录后，我们再来查看django_session表的存储情况：

 

sqlite> select * from django_session; 5c12085d19ea9cb938efbe03e7641ea1|YmNmMjA0ZDg2NDIxMTFhNDc2YmE1ZjBjNjRhYWRiN2U2NjVlNTU0ZDqAAn1xAShVEl9hdXRoX3Vz ZXJfYmFja2VuZHECVSlkamFuZ28uY29udHJpYi5hdXRoLmJhY2tlbmRzLk1vZGVsQmFja2VuZHED VQ1fYXV0aF91c2VyX2lkcQRLAXUu |2011-08-13 18:16:06.568622

   

    注意，看黑体字部分“5c12085d19ea9cb938efbe03e7641ea1”，它就是session_key，也就是我们将要在客户端浏览器cookie中看到的“sessionid”，最后是expire_date，中间的当然就是session_data了，它是经过base64编码的，我们解码后看一下：

 

bcf204d8642111a476ba5f0c64aadb7e665e554d:│[1]}q(U_auth_user_backendq[1]U)django.contrib.auth.backends.ModelBackendq U _auth_user_idq Ku.

   

客户端cookie的位置：

 

   

 

下面看一下浏览器保存的cookie：

 

csrftoken 739c039b3ebcd31987f41cd5cba2164a 192.168.3.139/ 1024 4221114752 30239913 2213459760 30166690 * sessionid 5c12085d19ea9cb938efbe03e7641ea1 192.168.3.139/ 1024 53524224 30169506 2284709760 30166690 *

   

 

现在我们将浏览器关闭，然后再在重新打开(关闭所有的浏览器，以IE为例)，然后重新访问http://www.xx.com/admin/，你会发现不用登录就可以这就直接进入了。

 

    下面我们在进行两项测试，第一将客户端的cookie文件删除，再访问；第二将服务器端的记录删除，再访问。

 

第一、将客户端的cookie文件删除，再访问

 

    其结果是，弹出登录界面，需要重新登录，在登录后查看客户端cookie文件，内容如下：

 

csrftoken 12c14bcf2d378b6ff101703c5014c028 192.168.3.139/ 1024 2216212864 30239916 209807872 30166693 * sessionid f35cba6f4e7b013183bd295c3d86ef03 192.168.3.139/ 1024 2493589632 30169508 427617872 30166693 *

   

    我们发现sessionid变了，为了证实一下，我们看一下服务器端的数据库：

 

sqlite> select * from django_session; 5c12085d19ea9cb938efbe03e7641ea1|YmNmMjA0ZDg2NDIxMTFhNDc2YmE1ZjBjNjRhYWRiN2U2NjVlNTU0ZDqAAn1xAShVEl9hdXRoX3Vz ZXJfYmFja2VuZHECVSlkamFuZ28uY29udHJpYi5hdXRoLmJhY2tlbmRzLk1vZGVsQmFja2VuZHED VQ1fYXV0aF91c2VyX2lkcQRLAXUu |2011-08-13 18:16:06.568622 f35cba6f4e7b013183bd295c3d86ef03|YmNmMjA0ZDg2NDIxMTFhNDc2YmE1ZjBjNjRhYWRiN2U2NjVlNTU0ZDqAAn1xAShVEl9hdXRoX3Vz ZXJfYmFja2VuZHECVSlkamFuZ28uY29udHJpYi5hdXRoLmJhY2tlbmRzLk1vZGVsQmFja2VuZHED VQ1fYXV0aF91c2VyX2lkcQRLAXUu |2011-08-13 18:34:29.323944 sqlite>

   

    可以看得出，又生成了一条记录。从这个测试中来看，如果客户端的cookie出问题，那么服务器端Django会重新下发cookie，而不是下发以前的cookie。从而我们也就看到了存储在数据库中的前一个cookie就算作废了。

 

第二将服务器端的记录删除，再访问

 

    删除服务器端数据库表的记录：

 

sqlite> DELETE FROM django_session; sqlite> select * from django_session; sqlite>

   

    第一条命令为删除数据记录，然后查看了一下确实为空了。

 

    然后再次访问http://www.xx.com/admin/，你会发现，不用重新打开浏览器，就在以前打开的基础上操作，已经是不可能的事情了，它会跳出登录窗口让我们重新登录，说明在这个过程中检测cookie有为题，再重新登录之后，我们在看一下客户端浏览器cookie的内容：

 

csrftoken 12c14bcf2d378b6ff101703c5014c028 192.168.3.139/ 1024 1456278272 30239918 3740770576 30166694 * sessionid 2d8da4bdb2a7e38edf72ca0ad35d7d4f 192.168.3.139/ 1024 1513655040 30169510 3741710576 30166694 *

   

    查看服务器端数据记录：

 

sqlite>  select * from django_session; 2d8da4bdb2a7e38edf72ca0ad35d7d4f|YjM3ODEyM2IyYzVlMTNmYzU1OTRiNjhjYTM5ODcwMmRhOTdiOWRlMjqAAn1xAVUKdGVzdGNvb2tp ZXECVQZ3b3JrZWRxA3Mu |2011-08-13 18:47:10.114229

   

   可以看得出，又生成了一条记录。从这个测试中来看，如服务器端的cookie出问题，那么服务器端Django会重新下发cookie，而不是使用存储在客户端的以前的下发cookie。

 

    如果结合实例7，那么在Nginx的配置中需要做如下调整：

 

http {     include       mime.types;     default_type  application/octet-stream;     sendfile        on;     keepalive_timeout  65;   upstream uwsgicluster {     ip_hash；     server 192.168.3.139:9001;     server 192.168.3.34:9001; }   server {         listen   0.0.0.0:80;         server_name www.xx.com;         location /               {              include uwsgi_params;              uwsgi_pass uwsgicluster;         }   }

   

    即在原有的配置中添加了ip_hash指令。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/27043155/viewspace-732227/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/27043155/viewspace-732227/