追蹤
Tagtoo開發日記
關於部落格
  • 89250

    累積人氣

  • 4

    今日人氣

    0

    追蹤人氣

大家來學GAE - 1

假設你正在實作一個網站  要儲存使用者個人化的資料  
以便根據不同使用者去決定要顯示的資訊  那麼你大概需要實做會員系統
供每個使用者登入 / 登出  此時就必須要用到session(參考1,  參考2) 的概念

最初網頁設計只是用來呈現靜態頁面  用戶端向伺服器端發出請求  索取網頁檔
每當換一個頁面  舊有頁面就完全消失  沒有辦法儲存任何狀態
所以像是我們現在很愛用的Gmail  Youtube  Yahoo拍賣  等雲端服務
只要登入後便可知道你是誰  根據你的身分決定要顯示什麼資訊給你
那時基本上是不存在的  session是一個保存在伺服器端
可持續(在頁面切換之間)保有網站設計者想保存的資訊
而session保存在伺服器端  伺服器端腳本程式只要去讀取對應的session
便可知道目前使用者的狀態為何  而後做對應的處理(簡單的範例
期間資料處理完全不涉及用戶端  也不會在網路上傳遞
所以不怕用戶端設法去改動它(例如企圖假冒身分)  或是傳送過程中被人截取
如此便可實現會員系統

好了  簡單介紹過session  但GAE並無內建session機制  那當我們需要會員系統時  該怎麼辦哩?
以下簡單敘述一下我目前看到的兩種方式  或許將來還有更好的方法  會隨時補上:

1. 利用GAE 的使用者API來實作: GAE提供了內建的API讓應用程式判斷使用者是否有登入Google帳號
只要 from google.appengine.api import users   這個users模組  便可使用像是
users.get_current_user()  來取得當前登入的user物件  以下的程式碼是最基本的範例:

user = user.get_current_user()
if user:
        # 當使用者已登入Google帳號做的處理
else:

        # 當使用者尚未登入Google帳號做的處理

而當使用者有登入時 user.email()  可取得他的email address
使用者尚未登入時  可利用users.create_login_url()  來將使用者導向登入Google 帳號的頁面
而且create_login_url()  方法可以輸入一參數  來決定登入成功後要重新導向哪個頁面

以上的模式是很典型的程序  所以Google 亦有提供一個更簡潔的做法
只要 from google.appengine.ext.webapp.util import login_required  
便可使用其提供的login_required 函式裝飾器(decorator)  範例如下:

from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import login_required

class HomePage(webapp.RequestHandler):
        @login_required
        def get(self):

        .....

這樣一來  當使用者造訪HomePage這個頁面時  若沒有登入Google帳號  就會被導到Google帳號登入頁
待登入完成後再導回原頁面  反之便可正常執行

使用這套機制的網站  使用者用Google帳號來登入  本站以使用者的email address來識別其身分
本站的資料庫只儲存email address 和 本站使用者編號的對應關係

這樣的好處是:
A. 讓使用者可以不必填資料來註冊新的帳號  增加使用意願  
B. Google已經提供方便的模組來判斷使用者是否登入Google  
C. 我們開發的web app 完全不經手使用者的Google帳號資料(僅能取得其email)  
     使用者沒有資料外洩的疑慮

壞處是:
A. 對使用者資料的掌握度較低


2. 設計user 的資料物件欄位來模擬session:
在每次使用者成功登入後  發給他一串隨機的亂數  同時候台也保留一份相同的亂數(通常存在資料庫  開一seesion欄位)  當用戶端接收到這串亂數後  開一cookie儲存之  並設定一特定期限的到期時間(expire time; 超過此期限cookie資料會自動清除)  例如一天 

當使用者造訪你的網站  首先會檢查此cookie值是否存在  若不存在則為未登入狀態  若存在則將其值送到後台檢察  必須和後台保留的那份亂數一模一樣才代表登入  否則仍視為未登入  當然  若有其它需要保存的資料(例如使用者的偏好設定)  亦可新增資料庫欄位儲存之

這種做法的缺點是身分驗證過程涉及用戶端的資料存取以及前後台資料傳輸  如此一來我們不能完全保證cookie沒有被偽造的可能  也不能保證在傳輸的過程中識別亂數沒有被攔截的可能  目前唯一想到的解法是將資料加密  讓資料即使被偉造或攔截  也無法達成冒充身分的目的 


關於GAE的參考資料
1. 介紹文-1
2. 介紹文-2
2. 付費方式
相簿設定
標籤設定
相簿狀態