ITPub博客

首页 > Linux操作系统 > Linux操作系统 > uWSGI 使用基于数据库的方式会话

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

原创 Linux操作系统 作者:nginx_web 时间:2012-06-08 07:06:05 0 删除 编辑

添加数据库配置

 

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/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 安装virtualenv 2
请登录后发表评论 登录
全部评论

注册时间:2012-06-06

  • 博文量
    54
  • 访问量
    410223