uWSGI 使用基於資料庫的方式會話

nginx_web發表於2012-06-08
資料庫會話

新增資料庫配置

 

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/，如需轉載，請註明出處，否則將追究法律責任。

相關文章