我知道你說帳戶:密碼包似乎有點「過度殺傷」,但實際上並不是這樣。你在那裏獲得的是可插拔的用戶界面(通過accounts-ui和其他構建它的軟件包)。我採取的方法是這樣的(即使對於支持多用戶的應用程序,這種情況也能正常運行,因爲最終你還是需要引導啓動用戶)。
首先,我使用帳戶的組合:密碼和alanning:角色。如果你絕對不需要角色部分,那麼你可能會離開它,但在我個人的情況下,我發現爲不同用戶提供多級ACL是很有用的。我們可以進行關於使用角色/組來鎖定各個功能的完整哲學討論,但這是本次討論的一個非主題。
接下來,您需要引導用戶(s)。在某處,/server
文件夾,你會做這樣的事情:
if (Meteor.users.find({}).count() == 0) {
// No users created...create default users
Accounts.createUser({
username: 'myuser',
email: '[email protected]',
password: 'myp4ssw0rd!',
profile: { profileProp: 'propVal` }
});
// Add new user to whatever roles needed
}
有一些更多的事情我通常在這裏做的,像檢查,看看是否存在我的角色,如果沒有,創建它們之前,我嘗試處理用戶,但這裏的關鍵是在服務器啓動時這麼做。
一旦您創建了用戶和角色,就需要檢查/驗證您的應用中的用戶/角色。對於菜單項,您可以根據用戶是否已登錄和/或具有特定角色來顯示/隱藏內容,還應該在應用程序中驗證需要ACL的路線,例如管理員路線。另外,還可以在所有出版物中使用用戶標識以限制用戶可以看到的數據。不要單純依靠隱藏菜單選項......通過默默無聞的安全性是行不通的。
爲什麼我建議這樣做?首先,它並不是那麼多的代碼。你可以從字面上做到這一點大概20行,最大,並有一個完整的身份驗證設置。這些代碼行的好處大大超過了您需要的30分鐘的上限,因爲您現在將在應用中擁有「真正」的用戶身份驗證功能,並且有能力在未來決定使用OAuth。最重要的是,您可以解鎖無需編碼的預構建UI插件,幫助檢查ACL的內置和附加方法,以及用戶鎖定數據的功能,而且您不必嘗試實施自己的解決方案。
夠公平的,這些都是一些很好的論點 –