Rails 3.1 Web服務中的兩種不同授權方案

我正在使用Rails 3.1創建Web服務，該服務需要經過身份驗證的用戶帳戶以創建/管理內容。它還需要一個用於訪問內容的臨時「用戶」的授權方案 - 他們沒有賬戶，但只是提供由在他們的請求中創建內容的用戶提供給他們的密碼。Rails 3.1 Web服務中的兩種不同授權方案

我在想最好的策略是保持兩個獨立的，不爲臨時用戶創建帳戶，將他們表示爲與內容相關的單獨模型。

我的問題是這是我應該從頭開始構建的東西，還是我可以從現有的身份驗證寶石中獲得足夠的槓桿作用。如果是後者，我將如何去配置它來管理兩種不同的策略。

來源

2011-11-18 Ken Cooper

原來我並不真的需要認證寶石。雖然實現沒有完成，但看起來Rails 3.1的has_secure_password和CanCan的組合可以很好地工作。

這裏是瑞安貝特的教程使用has_secure_password：http://asciicasts.com/episodes/270-authentication-in-rails-3-1

的想法是對用戶和內容模型都使用has_secure_password，並實現CURRENT_USER，使得它創建時提供的密碼短暫用戶，設置密碼屬性。然後在CanCan的Ability類中實現init方法將根據can塊中的內容驗證瞬時用戶的密碼。

來源

2011-11-20 21:25:09

身份驗證寶石的使用不僅提供了身份驗證裝置，還提供了視圖和幫助程序。讓我們繼續...設計爲例...提供視圖，區域設置，助手，郵件通知，支持openId等... – ProxyGear

如果理解正確，您將擁有常規帳戶用戶和用戶生成的臨時帳戶，以共享訪問權限。我不認爲這個具體目的的東西存在。我認爲使用一個可靠而舒適的Auth Manager gem將需要保護user和tmp_account訪問權限。 reste，即管理user-tmp_account關係和管理tmp_account的生命期+權限，可以在沒有人工痛苦的情況下完成。我個人建立了與寶石設計類似的東西。

來源

2011-11-19 00:31:06 ProxyGear

用戶不會明確創建臨時帳戶。相反，他們會向任何對內容感興趣的人提供密碼，然後這些人將訪問受密碼保護的內容。聽起來很複雜，但適合這項服務。 –

隨着色器件：https://github.com/plataformatec/devise 你有很多選擇讓哪些賬戶能做到與否：類MasterUser 色器件：database_authenticatable，：登記的，：可證實，：採所以基本上你會有一個MasterUser +一個SlaveUser模型。 SlaveUser模型由提供密碼的MasterUser創建。具有受限設計選項的SlaveUser無法編輯，恢復密碼。 – ProxyGear

Rails 3.1 Web服務中的兩種不同授權方案

回答

相關問題