擴展ASP.NET角色提供者

Question

因爲RoleProvider接口似乎只將角色視爲簡單字符串，所以我想知道是否有任何非用戶可以在每個用戶的基礎上爲角色應用可選值的方法。

我們當前的登錄管理系統將角色實現爲鍵值對，其中值部分是可選的，通常用於闡明或限制角色授予的權限。例如，「編輯者」角色可能包含用戶'barry'，但對於'barry'，它將有一個可選值'raptors'，系統會解釋這意味着Barry只能編輯下面提交的文章'猛禽'類。

我在其他地方看到了一個建議來簡單地創建額外的分隔角色，比如'editor.raptors'或somesuch。這並不是真的很理想，因爲它會大大增加角色的數量，我可以說這將是一個非常難以推銷的替代我們目前的實現（這也是非常不理想，但具有定製的優勢與我們的用戶數據庫一起工作）。

我可以告訴你，上面提到的連接方法會涉及很多繁瑣的字符串分割和部分匹配。

有沒有更好的方法？

編輯：我最初的目標是在內置ASP.NET功能使用較多。例如，通過Web.config中的<authorization/>元素控制訪問。據我所知，這樣做需要自己實施角色。除了這一限制之外，我們目前的系統認證概念似乎很適合。

回答mnemosyn的問題

1. 是。我們有一個用於用戶，應用程序及其授權的中央數據庫。這是一個核心繫統，並沒有圍繞它。
2. 目前我們的系統不是分層的，實際上需要花費很多精力來維護。創建應用程序時，會定義一組授權（例如'admin'，'user'，'poweruser'，'看門人'，'keymaster'等）。然後，將用戶與具有可選值的授權關聯起來，以實現用戶和（特定於應用程序）授權的獨特組合。
3. 你能詳細說明你說的這些'類別'嗎？

Answer 1

這聽起來像是一個架構問題。

首先，您需要確切地確定您需要什麼。在第二步中，將其映射到具體的實現。爲了提高這一點：除了最簡單的情況外，我不會使用內置的提供程序。此外，這個問題很快變得非常複雜，所以我會盡量保持簡單。

要闡述你的需求，嘗試確定：

• 你真的需要角色的概念映射到數據庫中，就像在一個CMS？或者對角色系統進行更改意味着對系統進行修改。在這種情況下，你可以尋求一個更簡單的解決方案，並將一個枚舉放入用戶中。這將節省大量的數據庫訪問，加入簡單的選擇等。
• 你想通過你解釋的多角色概念來實現什麼？它真的是你需要的角色嗎？個人權限如何？例如，您是否擁有層次結構，以便每個節點都可以擁有一組與其相關的權限，就像Windows的文件安全概念一樣？
• 如果它只是類別，爲什麼不將類別映射到用戶，即給每個用戶在每個類別中的某個角色。這將需要一些默認類別的調整等。

有一些提示：不要去白名單，總是使用黑名單。控制白名單是一種痛苦，尤其是，當很多規則走到一起。例如，在Drupal中，我認爲這是主要缺陷之一（這就是爲什麼他們將它重建爲在版本7中使用黑名單）。允許用戶做他們不應該做的事通常是一個比其他方式更大的問題。

Windows文件訪問的概念非常複雜，因爲它既有黑名也有白名單，還可以繼承 - 所以儘量讓你的解決方案比這更簡單。

字符串連接thingie對我來說聽起來相當危險，我會在任何情況下尋求更乾淨的解決方案。這種類型的元邏輯令人頭痛。