權限設計 -- 轉載

很多人都知道以角色為基礎的權限管理設計（RBAC），但是大部分人似懂非懂，不知道完整的權限管理系統都包括哪些內容。 在此以權限管理的使用場景來說明一下完整的權限管理內容。一是鑒權管理，即權限判斷邏輯。 1. 最基本的權限管理就是菜單管理，用戶沒有權限的功能模塊在菜單節點上是不顯示的。（很多人以為這就是權限管理！） 示例：普通業務人員登錄系統后，是看不到【用戶管理】菜單的。 2. 功能權限管理，B/S系統的功能體現為URL，所以功能權限管理主要是針對URL訪問的管理。（很多人都不清楚權限管理的對象是什么？） 示例： 經過授權，部門經理可以查看【用戶管理】菜單，并查看部門用戶信息，但權限設計要求，該部門經理沒有添加用戶的權限。 所以在訪問【添加用戶】的功能（URL）時，應該有沒有授權的提示信息。 同時在【用戶管理】頁面上，【添加用戶】的按鈕應該灰色顯示，不能點擊。 3. 行級權限管理 示例： 論壇管理員，權限設計要求 A能管理論壇 【新聞版塊】，不能管理論壇 【技術交流】 此時的權限設計就應該根據論壇的相應ID來判斷權限信息。 4. 列級權限管理 示例： 業務權限設計要求，除銷售人員以外，其他用戶不能看到客戶的聯系方式信息。 此時的權限設計要判斷相應的字段（列）是否可以顯示。 5. 組織機構/部門級數據權限管理 示例: 業務權限設計要求，銷售一部的人員只能看到本部門的銷售訂單，銷售二部的人員只能看到本部門的銷售訂單，但銷售經理可以同時看到 銷售一部和銷售二部的銷售訂單。 此時的權限設計就要根據銷售訂單數據本身的部門屬性來做判斷 6. 范圍型業務數據權限管理 示例： 大賣場銷售人員在下銷售訂單時，要選擇相應的產品所在倉庫信息。 業務權限設計要求，【國美】的銷售人員在選擇倉庫的下拉列表中不能看到【廣州倉庫】，而【大中電器】的銷售人員在選擇倉庫的下拉列表中不能看到【北京順義倉庫】二是授權管理，即權限分配過程。以上的權限管理內容都要通過系統的授權功能來分配給具體的用戶，授權功能應該足夠靈活。 1. 直接對用戶授權，直接分配到用戶的權限具有最優先級別。

　 用戶權限字符串==直接綁定每個菜單的ID，再用0表示具備權限，1表示不具備權限；如人員基本信息修改頁面的ID為18，張三的權限字符串中有個“181”的子字符串，那么代 表張三不具備查看人員基本信息修改頁面的權限。

ps:常在ispostback中判斷userid是否為空來表示是否登錄，如果用戶登入后直接在瀏覽器中鍵入url來訪問頁面，那么就悲劇了，so，要在ispostback中加入權限判斷，切記切 記。 2. 對用戶所屬崗位授權，用戶所屬崗位信息可以看作是一個分組，和角色的作用一樣，但是每個用戶只能關聯一個崗位信息。 3. 對用戶所屬角色授權，用戶所屬角色信息可以看作是一個權限分組，每個用戶可以關聯多個角色。

如用戶(游客，普通登入用戶，Vip用戶)，管理員（產品管理員，客戶管理員），超級管理員。

4. 角色直接關聯具體的功能權限（URL），也可以關聯負權限，即此角色關聯的權限不能使用負權限功能。負權限具有優先級別。 5. 分級授權，系統管理員可以將自己擁有的權限信息授權給其他用戶。即可以設置分級管理員和超級管理員。

只有個別人員才具備授予權限功能，且只能授予小于或等于自身的權限。

ps:可以把1、3、5相結合，既可為每個用戶單獨指定權限，又可避免繁瑣的權限勾選操作。

6.權限登記系統。

　 如，把一類頁面的權限設為1，另一類頁面的權限設為2，那權限為1的用戶只能查看權限為1的頁面，權限為2的用戶可查看1和2的頁面。

弊端ps:不適用于論壇等類似系統，原因：采用以上方法，會造成一個論壇的版主能操作權限等級相同或小于自身權限的版塊的現象。