2012-01-07 165 views
2

我一直花費大量的時間研究如何最好地實現從Android應用程序到Rails Web服務器的用戶認證。我知道有些引擎可以用於Rails方面的身份驗證,但我需要的並不是很複雜,所以我認爲我最好是編寫自己的身份驗證代碼。Cookie或RESTful密鑰的身份驗證?

我對REST風格的Web服務非常感興趣:在無狀態的Web服務器中,代碼更具可讀性,可維護性和可修改性,以提供一些優勢。作爲一名在這個實現上獨立工作的大學生,這些事情對我來說並不是非常重要,但我相信從編碼的角度來看,REST指導實現將是理想的。

由於我的應用程序需要維護自己的上下文的用戶帳戶,因此用戶在向Web服務器發出請求時必須進行身份驗證。如果我要以完全RESTful的方式實現這個應用程序,我不會維護任何類型的會話,而是要求Android應用程序(客戶端)傳遞當前用戶的憑據(可能是返回到Android應用程序的單個唯一密鑰在第一次登錄時從Web服務器上)在每個請求上。這將是一種有效的方法,但我擔心這可能會在服務器端產生的計算開銷。

這裏的原因:

  • 仰望由一長串用戶在以行爲對用戶的每個請求將是比具有在相關的錶行的整數用戶ID慢CookieStore會話。

  • 我可能不會在數據庫中以純文本格式存儲RESTful身份驗證密鑰。我可能會使用BCrypt並將密鑰的salt和hash存儲起來。這當然會導致這個項目符號所涉及的計算開銷:使用BCrypt在每個請求上對接收到的密鑰進行散列,以測試存儲在數據庫中的散列值。

當我最終需要託管的生產服務器,我真的承受不起支付獸,只是這樣我就可以炫耀一個REST徽章。

假設典型用戶進行10-30請求/天,和用戶的數量取決於應用的普及(我不能預測,但對這個問題的緣故,假定是平均值),是在我的具體情況下可以實現認證RESTfully?換句話說,它可能造成的計算開銷是否會顯着增加服務器的硬件需求?

謝謝

回答

0

在我的項目中,我通常使用另一種方法。

一旦用戶登錄到系統,我給他發送一個具有混合簡單和加密信息的唯一生成的密鑰。

基本上我做這樣的事情:

key = User.id.to_s + SHA1::Digest.hexdigest("#{SECRET_KEY}#{User.id}#{User.name}#{User.created_at.to_i}")

由於SHA1哈希的長度是已知的,可以提取ID,並從字符串標記,而不需要任何特殊的分隔符。 這種方式,您可以有兩個好處:

  1. 沒有要求保存在DB的關鍵,因爲它可以按需計算。
  2. 返回給用戶療法的關鍵是短(網絡的好處)和容易發(因爲在ASCII,沒有或不需要的Base64相似)

希望這有助於!