GAE：餅乾vs數據存儲

尋找一種在我的應用中進行會話的好方法，我發現了GAE Boilerplate和GAE Sessions。我不需要聯邦登錄，也不需要默認的用戶結構，但我喜歡設計結構以及他們解決某些問題（路線，表單，...）的方式。我不需要聯邦登錄，也不需要默認的用戶結構。GAE：餅乾vs數據存儲

GAES很簡單，但功能強大的治療會議。我最喜歡的是它將所有內容存儲在cookie中的方式，在這種情況下，它會將完整的用戶實體存儲在cookie中，以便在下一次頁面調用時不會完成其他數據存儲區命中：用戶數據始終從cookie中讀取（這種需要，如果用戶更新某些東西，通常不會更新數據）。另一方面，GAEB只存儲用戶ID，然後在每個頁面調用中檢索用戶名和用戶電子郵件。這是因爲它採用了BaseHandler部分的代碼（GAEB使用NDB模型）：

@webapp2.cached_property 
def username(self): 
    if self.user: 
     try: 
      user_info = models.User.get_by_id(long(self.user_id)) 
      if not user_info.activated: 
       self.auth.unset_session() 
       self.redirect_to('home') 
      else: 
       return str(user_info.username) 
     except AttributeError, e: 
      # avoid AttributeError when the session was delete from the server 
      logging.error(e) 
      self.auth.unset_session() 
      self.redirect_to('home') 
    return None

相同的電子郵件，並在render_template功能它這樣做：

def render_template(self, filename, **kwargs): 
    .... some code..... 

    # set or overwrite special vars for jinja templates 
    kwargs.update({ 
     'app_name': self.app.config.get('app_name'), 
     'user_id': self.user_id, 
     'username': self.username, 
     'email': self.email, 
     ... more vars ... 
    }) 
    kwargs.update(self.auth_config)

似乎讀2由於這個funcs使models.User.get_by_**field**(long(self.user_id))

我唯一不知道的是@ webapp2.cached_property是什麼意思，這可能意味着所有這些數據存儲讀取是從緩存中完成並且真的不需要h它是數據存儲。

有人可以告訴我什麼是更好的解決方案來保存點擊數據庫？看起來最好是將所有的用戶數據都放在一個cookie中（顯然是安全的），並且不要在每次調用頁面時都訪問數據存儲區，但也許我錯了（我對GAE相對不太熟悉），而所有這些讀取到數據存儲緩存，然後免費。

來源

2013-07-17 Eagle

在cookie

保存會話數據被高度氣餒：

它具有與每個請求被轉移（慢速移動的連接）
可以傳輸到GAE HTTP報頭大小是有限的（ 64KB，如果我沒記錯的話） - 這就是上限數據的你可以存儲
即使你加密和簽名會，你仍然是脆弱的回覆攻擊（你不能執行安全註銷）

我不知道你提到的實現，但我們在CMS中有一個會話實現，請參閱https://bitbucket.org/viur/server/src/b2e9e3dca3adabee97e1761d630600a387a02c44/session.py?at=master。一般的想法是生成一個隨機字符串（用作會話標識符）。會話加載數據存儲「get by key」被執行（它被緩存，所以如果該對象仍然在memcache中，它根本不會碰到數據存儲）。

只有當會話內存儲的數據發生變化或者會話不是最近5分鐘更新的時才執行保存。然後，您可以將用戶對象的值複製到會話中，並且不會有額外的數據存儲請求。

來源

2013-07-17 19:56:45

感謝您的回覆，我會分析您的代碼。我只看到一件很快的事情：爲什麼你不使用NDB而不是DB。更好的是，它自動緩存實體（或者應該這樣做），所以對數據庫的命中較少。順便說一下，我拒絕將完整的實體存儲在cookie中，我發現更多的複雜性，例如來自同一用戶的兩個會話在不同的設備中...... – Eagle

您的代碼似乎很好，但現在我認爲我不會使用會話因爲我只需要知道userId和他想使用的語言，因此將其存儲在受保護的cookie上就可以解決我的需求（我只是在每次調用時檢索它，這將非常少的數據檢索，大約20個字節）。 – Eagle

我們不使用ndb來簡單地指定獨立於數據存儲區條目總體緩存時間的memcache-entry的生存期。提示cookies的語言：Searchengine蜘蛛（如谷歌）不接受餅乾。如果你希望他們用不同的語言編制你的網站索引，你需要一個不同的方法:) –

GAE：餅乾vs數據存儲

回答

相關問題