乙個客戶系統最基本的功能是對客戶的建立，修改，刪除和查詢。實現這樣的功能通常是在資料庫中建乙個customer表，然後通過程式實現以上基本功能。在乙個個人環境的應用中，乙個使用者可以對所有的客戶進行任意操作,基本不存在許可權控制問題。在多使用者系統中，客戶屬於乙個人或者一群人，而對客戶的操作許可權也不可能是人人一樣。所以需要對使用者的操作做許可權控制。
這裡有必要先對許可權控制方式本身做一下討論，有些系統用選單進行許可權控制，比如"新建客戶"，"瀏覽客戶",往往用操作名加上乙個資源名代表乙個許可權，這樣的許可權控制有乙個缺陷，就是一般漏掉了乙個資源範圍，比如瀏覽什麼樣的客戶，就沒有說明。當然也可以加上，比如瀏覽個人客戶，瀏覽部門客戶，瀏覽公司客戶，但是隨著需要控制資源型別的增加，通過不斷增加選單項來進行控制，並不是乙個很好的方法。在b/s系統中的選單控制，有2重意義，一是真正的選單，沒有許可權的使用者就看不到相應的選單項，另外乙個為了防止使用者任意提交資訊，在伺服器端對使用者提交的url進行檢查，看是不是有這個許可權。比如對於使用者請求的listcus.do就要先檢查使用者是否有訪問這個url的許可權：
public class listcusaction extends action
} 另外一種控制辦法是對操作和操作資源定義許可權，比如使用者a可以對客戶進行修改操作。這樣細粒度的許可權控制對程式的擴充套件性和安全性有很大好處，但實現比前一種費時，下面通過分析說明2種方式的特點。
作為客戶系統最簡單的一種考慮，是每個使用者管理自己的客戶。這種請況下，我們通過在customer表中增加乙個使用者字段，就可以知道這個客戶對應於哪乙個使用者。如下面的類所示：
public class customer
那麼通過選單的控制方式，我們認為每個有客戶建立權的使用者都可以建立屬於自己的客戶，什麼叫客戶建立權，就是可以看到和選擇「新增客戶」選單項的使用者。同時，「客戶瀏覽」就表示瀏覽屬於自己的客戶，這樣一來，建立客戶的使用者可以看到自己的客戶，並進行操作，我們通過選單控制許可權方式完成了這個需求。需要注意的是：在使用者進行相應操作前，我們先判斷這個客戶是不是屬於這個使用者，是就可以操作，不是就不可以。如下例所示：
public class delcusaction extends action
} 進行這個判斷是出於安全性考慮的，特別在b/s架構的軟體系統中，你無法阻止客戶向伺服器端任意提交資訊。比如使用者a不使用選單，向伺服器請求"delcus.do?ctmno=no1",而no1屬於使用者b,如果不進行判斷，客戶就被刪除掉了。所以光靠控制選單項的顯示完成許可權控制，並不完整。
現在我們接觸乙個更複雜一點的需求，就是客戶轉移，把客戶從乙個使用者，指派給另外乙個使用者。在上面的實現基礎上，只要新增乙個介面，改變客戶所屬的使用者，問題也就解決了。如下：
public class changeuseraction extends action
} 每個使用者現在可以管理自己的客戶，也可以把客戶交給別人管理，問題解決得完美。我們再考慮實際的情況，乙個客戶可能可以被乙個使用者看，但是不可以被修改或者刪除。我們怎麼控制這樣的許可權，加乙個選單項-"察看客戶"，使用者a可以執行這個操作，但是不可以選擇選單項-"修改客戶"，針對每乙個動作，我們加了乙個選單項。我們需要控制的內容變得越來越多。再深入分析，可以發現，其實上面的方案已經不能滿足需求。 2個客戶我們如何知道乙個可以被使用者a看，乙個不可以，出現了乙個資源的管理問題，必須有另外的方案來進行這種許可權的控制。我們設計乙個資源類：
public class customerresource
再設計乙個資源管理類：
public class customerresourcemanager
//從資料庫裝載相應使用者的客戶操作許可權。
private static void retrieveresources(string userid)
//檢查相應的許可權是否在resources中存在。
private static boolean checkpermit(customerresource permit)
} 客戶端使用類：
public class delcusaction extends action
...
} }
在採用了上面的許可權檢查方式後，我們可以對每乙個客戶指定相應操作人的許可權，對客戶的操作就限制在了操作型別的多少上，基本的有「update,insert,delete,list,view」等，其餘也可以定義「submit」等操作，具體取決於系統需求。這樣的好處是許可權控制非常靈活，客戶可以作為資源在使用者之間自由流動。但是作為乙個給使用者最終使用的許可權系統，這樣的卻體系不適合於出現在使用者許可權系統設定裡面，不能叫每個使用者都去自己指定自己建立客戶的操作範圍，最好是通過這種方式實現預設的業務和許可權設定，滿足了使用者需求，又遮蔽複雜性。在完整的系統中，基於選單的控制也是必不可少，這樣的方式方便使用者使用，也更易於使用者理解。 2者通常應結合使用。
簡單客戶系統的許可權控制實現
乙個客戶系統最基本的功能是對客戶的建立，修改，刪除和查詢。實現這樣的功能通常是在資料庫中建乙個customer表，然後通過程式實現以上基本功能。在乙個個人環境的應用中，乙個使用者可以對所有的客戶進行任意操作,基本不存在許可權控制問題。在多使用者系統中，客戶屬於乙個人或者一群人，而對客戶的操作許可權也...
簡單的許可權控制
手上的專案涉及到許可權控制，可是許可權，角色，資源訪問都非常easy，所以就沒有寫特麼複雜。所以將每乙個使用者的角色直接儲存到了該使用者的具體資訊中。所以每乙個使用者在登入系統時，在頁面載入時推斷該使用者中角色屬性值 詳細 例如以下 yyry yyry yyry session.getattribu...
NHibernate 實現系統的許可權控制 一
nhibernate 實現系統的許可權控制 一 資料物件分析 許可權管理是一般的管理系統都必須具備的基本功能，同時也是必須具備的。所以準備設計乙個許可權管理的功能，由於時間問題置於ui部分，可能暫時不能完成，為了學習 新技術，所以決定用nhibernate來做 o r，當然這裡只用了 一些基本的功能...