2012-02-15 88 views
3

我想知道,什麼時候是正確的時機,以及如何檢查瀏覽器的Cookie支持。如何檢查瀏覽器與金字塔餅乾支持

我知道我必須檢查下一個請求,例如,用燒杯,尋找會話密鑰_creation_timerequest.headers['Cookie'] ...並提出異常,如果沒有找到,但我不想這樣做或類似的東西爲每個請求。我的應用程序的某些部分不需要cookie,如主頁或信息,常見問題頁...

當用戶註銷時,會話被刪除或失效,我用來重定向到主視圖,如果我在那個時候檢查session key,我不會找到它,但這並不意味着有這個問題。

我在登錄視圖的開頭使用的示例:

try: request.headers['Cookie'] 
except KeyError: 
    return HTTPFound(location=request.route_url('home')) 

也請注意,如果我嘗試使用request.session.flash(msg, 'error')打印的錯誤信息,或在主頁視圖的開始再次使用該代碼段和渲染一個帶模板的消息使用一個控制返回變量,在註銷後它將被錯誤地顯示出來。

我正在尋找最優雅的方式來解決問題...也許訂閱一個事件?...寫下一個函數調用某些感興趣的視圖?

回答

3

有幾件事情可能導致你的問題。

我繼續之前... FYI金字塔使用的WebOb來處理請求和響應對象

方案1

如果調用下set_cookie金字塔,然後做一個重定向,set_cookie將不會被髮送。這是因爲重定向創建了一個新的響應對象。

大約有這幾個方面:

  1. 最直接的是隻響應頭複製到時候你養/返回重定向餅乾

    return HTTPfound("/path/to/redirect", headers=[ (k,v) for (k,v)\ 
    in self.request.response.headers.iteritems() if k == 'Set-Cookie'] ) 
    

    OR

    resp = HTTPFound(location='/path/to/redirect') 
    return self.request.response.merge_cookies(resp) 
    

    我還應該注意,MOST瀏覽器在重定向上接受cookie,但Safari不支持。

  2. 另一種方法是使用金字塔的鉤子在幕後轉換cookie。我寫了自動化這個的訂戶。他們在pypi和github上。 https://github.com/jvanasco/pyramid_subscribers_cookiexfer

方案2

有很多金字塔處理會話的兩種方式。金字塔有自己的會話庫,然後有Beaker,處理sessions爲塔,並有金字塔的支持,很多人使用。我不會說的pyramid.session,但燒杯有兩種模式,終止會話:如果調用invalidate()

delete() 
Delete the cookie, and clear the session 

invalidate() 
Clear the contents and start a new session 

,燒杯會話cookie保持不變,所有的會話數據將被清除 - 這樣你就可以開始將新數據存儲到空會話對象中。

如果您撥打delete(),cookie會像會話數據一樣被終止。如果您將新信息添加到會話IIRC中,它將進入新的sessionid/cookie。但是,正如我在上面第一部分中指出的那樣,set_cookie將被調用,但在重定向期間被拋出。因此,如果您delete()會話,然後不遷移set_cookie頭...客戶端永遠不會收到會話標識符。在金字塔的餅乾

一些示例行爲

重定向

  • 用戶訪問網站的行爲,並定的cookie:會話ID = 1
  • 用戶點擊登錄
    • 軟件會保存登錄狀態到會話「1」
    • 應用程序調用set_cookie與「LoggedIn = 1」
    • 應用程序調用重定向到/ home
    • 重定向發送,沒有曲奇餅
  • 用戶的土地上的/ home
    • 應用程序只看到餅乾的 「會話ID = 1」

重定向刪除行爲:

  • 用戶點擊註銷
    • 應用程序在會話中調用'delete()',查殺數據存儲並在request.response中放置set_cookie以使舊Cookie過期。如果創建了新的sessionid,那麼也會發送該sessionid。
    • 如果應用程序呈現一個響應,則客戶端會收到餅乾
    • 如果應用重定向,客戶端沒有收到頭過期的餅乾或設置與重定向無效的一個新

行爲:

  • 用戶點擊註銷
    • 應用程序調用 '無效()' 會話,造成數據存儲
    • 應用設置自定義 「loggedout = 0」 的cookie
    • 如果應用程序呈現的響應,則客戶端接收的cookie
    • 如果應用重定向:
      • 客戶端不接收 「loggedout = 0」 頭
      • 客戶仍然擁有舊的會話cookie,但它在後端被無效/清除,所以它們被有效地鎖定。

側面說明:我個人不喜歡使用request.headers接口 - 負責處理所有頭 - 得到的餅乾。我與request.cookies有更好的運氣 - 它返回一個餅乾字典。