您不一定必須創建自定義成員資格提供程序,但您必須以不同方式考慮權限。
開始時,用「操作」在你的腦袋替換單詞「角色」。
您需要創建一個應用程序中的原子,細粒度的權限,例如:
- UserPropertiesView
- UserPropertiesModify
- CREATEUSER
- DeleteUser
- RolesView
- RolesModify
- CREATEROLE
- DeleteRole
可能很難在第一,但這個讓你在個人用戶分配操作偉大的控制和靈活性。由於不同的頁面會有不同的操作,因此您可以自定義其訪問權限。
不幸的是,開箱即用的ASP.Net成員和角色提供者都是脫離了課程粒度角色的概念。 只要你知道他們是運營,而不是角色,你會很好。
抽象是你的朋友在這裏:
public static class Permissions
{
public static bool Operation(string op)
{
//this class can be a lot better
// it can be testable, and check
// error conditions, but this is
// only an example :)
return HttpContext.Current.User.IsInRole(op);
}
}
某處你會希望將所有這些操作成角色,但是這將需要你做一些定製編程。
自定義提供者實際上並不那麼可怕,而且您可以輕鬆擴展內置的提供者。
你只想實現自己的邏輯。在'/ foo/bar'動作中說,你只是在邏輯上檢查用戶是否在角色中並允許或拒絕該動作,然後在'/ foo/baz'中再次檢查並允許或拒絕。不過,你應該注意到這會讓事情變得複雜。考慮擁有多個角色,而不是單個角色,這意味着不同控制器/操作中的不同事物。 – xdumaine
我會說看看使用多個角色。例如而不是管理員考慮使用SectionAdministrator和OtherSectionGuest。 –
您可以將AuthorizeAttribute放置在您的控制器的操作上,併爲用戶提供應該訪問特定操作的用戶屬性。 –