2010年9月8日
-------------------------------------------- 總大綱 ---------------------------------
Ralasafe開源有段時間了，大約有2個月了。根據(jù)社區(qū)的反饋，我打算圍繞Ralasafe最佳實踐，書寫一系列BLOG。
大體內(nèi)容有：
1， 登錄控制： 哪些頁面需要登錄后才能訪問，登錄用戶名、密碼驗證，登錄轉(zhuǎn)向頁面；
2， URL權(quán)限控制：哪些頁面訪問需要進行角色權(quán)限驗證，怎樣驗證最簡單有效，如何處理驗證失敗情況；
3， 數(shù)據(jù)級權(quán)限管理方案探討：選擇中間件呢還是框架？
4， Ralasafe體系結(jié)構(gòu)： 用戶怎么讀取，用戶有哪些字段，怎樣與應用基礎(chǔ)；
5， 數(shù)據(jù)級查詢權(quán)限管理： 如何給不同的人分配不同的查詢數(shù)據(jù)權(quán)限，返回where條件呢，還是直接返回結(jié)果集？
6， 數(shù)據(jù)級決策權(quán)限管理： 如何給不同的人分配不同的數(shù)據(jù)操作權(quán)限，當用戶不具備權(quán)限怎么辦？
7， 其他細小的權(quán)限控制： 如下拉框顯示內(nèi)容；按鈕、鏈接是否顯示，圖片是否顯示等。
-------------------------------------------- ------- --------------------------------
數(shù)據(jù)級權(quán)限管理需求
數(shù)據(jù)級權(quán)限管理需求主要有：
1，支持不同用戶查詢到數(shù)據(jù)是不同的；
2，支持數(shù)據(jù)庫行級、列級查詢；
3，支持分頁查詢——包括2個方面：a，分頁查出數(shù)據(jù)；b，能告知總數(shù)據(jù)條數(shù)是多少；
4，支持自定義條件（比如：張三在自己的查詢權(quán)限范圍內(nèi)，查詢50w以上的訂單）。
理論分析
能夠?qū)?shù)據(jù)級權(quán)限，與業(yè)務(wù)分離出來——是多年來開發(fā)人員追求的目標。一旦遇到疑難雜癥，馬上會讓人聯(lián)想到高難度的API編程，或者絢麗的XML配置。
不過，我今天的分析，會極其簡單。不過我強烈建議大家看下去。如果對該方案有所懷疑，請使用你的應用案例進行試驗。我當時不敢確認的時候，就是這么做的。
（當初，我提出該方案的時候，我們團隊認為該方案過于簡單，不可行。我堅持讓他們實現(xiàn)該方案。等產(chǎn)品做出來后，他們略有所悟，認為該方案可行。當，我讓他們做demo的時候，將該方案運用于案例的時候，他們拍腿叫道：超級太棒了！我希望你也有該感受）
分類思想的提出
首先，我們思考這個問題：為什么我們在程序里面使用了if/else？為什么數(shù)據(jù)級權(quán)限難以處理？
原因就是：1，有很多種情況；2，我們需要針對不同的人、不同的情況做不同的權(quán)限邏輯。比如：
if 是總公司用戶？ then 查詢所有訂單；
else if 是分公司用戶？ then 查詢本分公司（${用戶的公司}）及下屬子公司訂單；
else // 是子公司用戶了
then 查詢本子公司訂單（${用戶的公司}）
在RBAC模型里面有用戶群組概念，也有不少開發(fā)人員將用戶群組引入數(shù)據(jù)級權(quán)限管理領(lǐng)域。群組很好的將用戶歸組，但不足之處是要事先將用戶歸入組內(nèi)。比如，在將張三指定到“總公司用戶組”之前，他不屬于該用戶組，即便張三的機構(gòu)屬性顯示他屬于總公司。
我們對群組進行稍微改造：使用規(guī)則來定義群組，滿足該規(guī)則的用戶，我們則認為該用戶屬于該群組。傳統(tǒng)編程里面的if/else判斷條件，基本都可以使用規(guī)則或者規(guī)則表達式組來描述。此時，張三的機構(gòu)屬性顯示是總公司，那么他就屬于總公司用戶組；如果他的機構(gòu)屬性是某個分公司，那么他就屬于分公司用戶組了。無需進行額外操作（指定、重新指派等，一切都是動態(tài)智能的）。
OK，至此，我們提出了使用規(guī)則描述的“用戶分類”。該規(guī)則應該能讀取用戶信息、上下文信息、數(shù)據(jù)查詢等，并進行相關(guān)運算（比較、集合運算等）
至此，我們可以基于用戶要分類，為每個用戶分類分配一個查詢。（該查詢可以接受相關(guān)參數(shù)，比如用戶參數(shù)、上下文參數(shù)等）
那么上述例子，使用分類思想，可以這么解決：
用戶分類：總公司用戶類 —— 查詢：查詢所有訂單
用戶分類：分公司用戶類 —— 查詢：查詢本分公司及下屬子公司訂單；
用戶分類：子公司用戶類 —— 查詢：查詢本子公司訂單。
與功能權(quán)限結(jié)合
我認為功能權(quán)限與數(shù)據(jù)權(quán)限分開非常合適。功能權(quán)限由企業(yè)IT管理員維護；數(shù)據(jù)權(quán)限由軟件開發(fā)商維護。有人會說這樣不好，比如這個案例怎么處理：
普通審查員可以審查50w財務(wù)數(shù)據(jù)；中級審查員審查50w～500w的財務(wù)數(shù)據(jù)。這個50w、500w，企業(yè)需要自行維護。
OK，我認為這50w、500w應該稱為“權(quán)限策略數(shù)據(jù)”，可以保存到數(shù)據(jù)庫里面，做為基礎(chǔ)數(shù)據(jù)或者數(shù)據(jù)字典由企業(yè)通過界面自行維護。而軟件開發(fā)商，開發(fā)的“數(shù)據(jù)級權(quán)限”策略讀取這些數(shù)據(jù)。（當然，你可以緩存。。。。）
Ralasafe方案
怎樣實現(xiàn)數(shù)據(jù)級查詢權(quán)限
為了理解本節(jié)內(nèi)容，建議下載ralasafe demo應用，對照圖形界面，更容易理解些。
Ralasafe使用管理界面來定制用戶分類、定制數(shù)據(jù)查詢。為了確保定制無誤，Ralasafe支持在線測試。比如定制用戶分類后，可以選擇一個用戶進行測試。數(shù)據(jù)查詢等都是可以在線測試的。
定制完畢后，將用戶分類和數(shù)據(jù)查詢配對，賦給特點權(quán)限。一個權(quán)限，可以賦多個（用戶分類——數(shù)據(jù)查詢）配對。和前面的理論分析一樣。
具體定制，怎樣配對，可以參考文檔，配有圖片，在此不做多說。定制用戶分類，定制數(shù)據(jù)查詢，給權(quán)限授權(quán)策略（即配對）。
怎樣與應用結(jié)合
Ralasafe提供org.ralasafe.Ralasafe和org.ralasafe.WebRalasafe兩個接口類。里面的query方法對應數(shù)據(jù)級查詢權(quán)限。在應用系統(tǒng)相應的地方，調(diào)用該方法即可。我建議在系統(tǒng)的控制層調(diào)用，即：servlet或者action。
ralasafe demo例子，EmployeServlet就是這么調(diào)用的：（demo演示員工查詢，不是訂單查詢
）
// 通過Ralasafe接口獲取當前用戶被授權(quán)查看的員工
Collection employees = WebRalasafe.query(req, Privilege.QUERY_EMPLOYEE);
// 將數(shù)據(jù)放入request，供前臺展示
req.setAttribute("employees", employees);
OK，就這么簡單。需要編程的工作量非常非常少，達到了極致。世界從此清凈了。
（WebRalasafe.query方法接受req<HttpRequest>參數(shù)，從這里讀取User。Ralasafe.query方法則直接傳入User，可供非web類應用調(diào)用）
系統(tǒng)結(jié)構(gòu)
Ralasafe由權(quán)限引擎和管理界面組成。權(quán)限引擎解析權(quán)限策略；管理界面生成、維護權(quán)限策略。如圖示：
注：ralasafe團隊博客在javaeye/baidu/blogjava等空間，同步發(fā)布。ralasafe官方網(wǎng)站：http://www.ralasafe.org/zh
posted @
2010-09-08 21:38 細粒度權(quán)限管理 閱讀(4831) |
評論 (1) |
編輯 收藏
2010年9月6日
-------------------------------------------- 總大綱 ---------------------------------
Ralasafe開源有段時間了，大約有2個月了。根據(jù)社區(qū)的反饋，我打算圍繞Ralasafe最佳實踐，書寫一系列BLOG。
大體內(nèi)容有：
1， 登錄控制： 哪些頁面需要登錄后才能訪問，登錄用戶名、密碼驗證，登錄轉(zhuǎn)向頁面；
2， URL權(quán)限控制：哪些頁面訪問需要進行角色權(quán)限驗證，怎樣驗證最簡單有效，如何處理驗證失敗情況；
3， 數(shù)據(jù)級權(quán)限管理方案探討：選擇中間件呢還是框架？
4， Ralasafe體系結(jié)構(gòu)： 用戶怎么讀取，用戶有哪些字段，怎樣與應用基礎(chǔ)；
5， 數(shù)據(jù)級查詢權(quán)限管理： 如何給不同的人分配不同的查詢數(shù)據(jù)權(quán)限，返回where條件呢，還是直接返回結(jié)果集？
6， 數(shù)據(jù)級決策權(quán)限管理： 如何給不同的人分配不同的數(shù)據(jù)操作權(quán)限，當用戶不具備權(quán)限怎么辦？
7， 其他細小的權(quán)限控制： 如下拉框顯示內(nèi)容；按鈕、鏈接是否顯示，圖片是否顯示等。
-------------------------------------------- ------- --------------------------------
數(shù)據(jù)級權(quán)限
數(shù)據(jù)級權(quán)限，無外乎這些類型：
1，數(shù)據(jù)庫行列級：比如領(lǐng)導查詢數(shù)據(jù)范圍和普通員工查詢的數(shù)據(jù)范圍不同，客戶經(jīng)理能夠查詢客戶聯(lián)系方式字段，而其他人不能查看客戶聯(lián)系方式字段。
2，字段內(nèi)容控制：比如普通審查員審查50w以下財務(wù)數(shù)據(jù)，剛?cè)肼毧蛻艚?jīng)理只能將客戶級別調(diào)整不能超過3級。
從用戶與數(shù)據(jù)的交互方向可以分為2大類：
1，從系統(tǒng)獲取數(shù)據(jù)（查詢）；
2，向系統(tǒng)提交數(shù)據(jù)之前的判斷。
現(xiàn)實困惑
這種權(quán)限與業(yè)務(wù)緊密耦合，很難找到通用方法。絕大部分系統(tǒng)仍然采用if/else來編程，而且這種邏輯分散到系統(tǒng)的各個環(huán)節(jié)，甚至還會在系統(tǒng)多處出現(xiàn)重復判斷。
也有不少網(wǎng)友嘗試5表模型等，試圖通過數(shù)據(jù)模型構(gòu)造好的ACCESS CONTROL LIST來控制。這種構(gòu)造ENTRY模式，當數(shù)據(jù)量小的時候，是可行的，維護工作量也不大。當數(shù)據(jù)量大的時候，顯然不能奏效。甚至無法運行，維護工作量非常大。
主要表現(xiàn)在：
1，where 語句里面的in(..., ..., ..., ..., ...) 子條件過長，或者使用in (select ... from ACL_ENTRY where ... )性能也是非常低下的；
2，當刪除某用戶的時候，需要在ACL_ENTRY表里面，刪除相關(guān)記錄；
3，當刪除某業(yè)務(wù)數(shù)據(jù)的時候，也需要在ACL_ENTRY表里面，刪除掉相關(guān)記錄；
4，數(shù)據(jù)量大，ACL_ENTRY數(shù)據(jù)量承幾何級增長。
也有企業(yè)嘗試使用規(guī)則引擎來解決。這是非常好的嘗試，提升了系統(tǒng)開發(fā)效率、組件復用率。
主要表現(xiàn)在：
1，首先，主動的實踐了一項最佳項目實踐：權(quán)限與業(yè)務(wù)松耦合。
2，通過松耦合，大幅優(yōu)化了系統(tǒng)結(jié)構(gòu)。
3，進一步提高了組件復用率。
只是，規(guī)則引擎畢竟不是專業(yè)于權(quán)限管理領(lǐng)域，對于復雜需求，或者有些需求實現(xiàn)起來還是很別扭?？雌饋硐駃f/else的規(guī)則表達罷了。
Ralasafe和IBM、Oracle商業(yè)產(chǎn)品一樣，都使用規(guī)則進行描述。大家的區(qū)別在于：誰滿足需求更多、更容易了。
框架or中間件
框架的好處，顯然是有個體系結(jié)構(gòu)，團隊遵循該方式進行開發(fā)、組裝即可。提供了一種標準和開發(fā)模式。
中間件的好處，顯然是提供了自由，而且易于結(jié)合、易于分工。提供了一種服務(wù)方式。
我本人希望自由，所以討厭框架，偏愛中間件。但我對選用中間件、框架的選擇標準是非常中肯的，供大家參考。
在系統(tǒng)結(jié)構(gòu)分層的場景，適合使用框架。
在系統(tǒng)功能分離的場景，適合使用中間件。
那么具體到權(quán)限管理領(lǐng)域，顯然是功能分離，中間件更合適。這么做，還將不給原有系統(tǒng)、新開發(fā)系統(tǒng)的既定框架造成沖突。一個系統(tǒng)里面使用多個框架，是非常痛苦的事情。殊不知在SSH的海洋里面，有多少人將N多時間“Kill”在沙灘上？！
Ralasafe體系結(jié)構(gòu)及應用集成
Ralasafe是中間件，采用服務(wù)模型。在業(yè)務(wù)需要的地方，調(diào)用Ralasafe接口，或者將Ralasafe接口向LOG4J那樣wrap到你的aspect里面去。
Ralasafe按照權(quán)限的方向，提供2種數(shù)據(jù)級權(quán)限管理服務(wù)，也正好對應2個接口：
1，從系統(tǒng)獲取數(shù)據(jù)， Ralasafe.query( int privilegeId, User user, CustomizedWhere where, int fromIndex, int size );
2，向系統(tǒng)提交數(shù)據(jù)之前的判斷，Ralasafe.permit( int privilegeId, User user, Object businessData);
Ralasafe還針對web應用，提供了WebRalasafe。
接口非常簡單，在接口層只要告知Ralasafe：當前這個是誰，他/她想干什么。
權(quán)限邏輯，全部在Ralasafe圖形化管理界面，點擊鼠標完成配置，并進行在線測試。無需編程。
所以，使用Ralasafe編程工作量非常少。也給不少開發(fā)人員造成“不知道怎樣與應用集成”的錯覺。
Ralasafe的用戶怎么來
Ralasafe并不會給你的應用系統(tǒng)“假定”有哪些字段。你的應用系統(tǒng)用戶可以由任意字段，通過XML文件安裝到Ralasafe即可。該XML文件，主要指明：用戶存在那張表（也可以是視圖，這樣可以從多張表關(guān)聯(lián)讀取數(shù)據(jù)。比如ralasafe-demo，就關(guān)聯(lián)到company表讀取了companyLevel和companyName字段）； 哪些字段是唯一字段； 哪些字段是主鍵；各字段對應類型。
然后，在所有權(quán)限規(guī)則里面，可以讀取這些用戶字段。比如ralasafe-demo應用（下載地址：
http://www.ralasafe.org/zh/download/download.jsp ) 用戶含有companyLevel字段，在定制“總公司”用戶分類的時候，就將該用戶companyLevel字段與總公司級別“1”進行比較。
（下期真正開始探討數(shù)據(jù)級權(quán)限管理實現(xiàn)了）
注：ralasafe團隊博客在javaeye/baidu/blogjava等空間，同步發(fā)布。ralasafe官方網(wǎng)站：http://www.ralasafe.org/zh
posted @
2010-09-06 22:58 細粒度權(quán)限管理 閱讀(2067) |
評論 (0) |
編輯 收藏
2010年9月2日
-------------------------------------------- 總大綱 ---------------------------------
Ralasafe開源有段時間了，大約有2個月了。根據(jù)社區(qū)的反饋，我打算圍繞Ralasafe最佳實踐，書寫一系列BLOG。
大體內(nèi)容有：
1， 登錄控制： 哪些頁面需要登錄后才能訪問，登錄用戶名、密碼驗證，登錄轉(zhuǎn)向頁面；
2， URL權(quán)限控制：哪些頁面訪問需要進行角色權(quán)限驗證，怎樣驗證最簡單有效，如何處理驗證失敗情況；
3， 數(shù)據(jù)級權(quán)限管理方案探討：選擇中間件呢還是框架？
4， Ralasafe體系結(jié)構(gòu)： 用戶怎么讀取，用戶有哪些字段，怎樣與應用基礎(chǔ)；
5， 數(shù)據(jù)級查詢權(quán)限管理： 如何給不同的人分配不同的查詢數(shù)據(jù)權(quán)限，返回where條件呢，還是直接返回結(jié)果集？
6， 數(shù)據(jù)級決策權(quán)限管理： 如何給不同的人分配不同的數(shù)據(jù)操作權(quán)限，當用戶不具備權(quán)限怎么辦？
7， 其他細小的權(quán)限控制： 如下拉框顯示內(nèi)容；按鈕、鏈接是否顯示，圖片是否顯示等。
-------------------------------------------- ------- --------------------------------
今天說的URL權(quán)限控制，內(nèi)容主要有：URL權(quán)限控制，當用戶訪問某URL時，進行角色權(quán)限驗證。如果有相應權(quán)限，則允許其正常訪問；否則，轉(zhuǎn)到拒絕頁面。
我們依然通過一個Filter來實現(xiàn)，這樣就無需在代碼中增加權(quán)限判斷，也無需套用任何框架。對于整個權(quán)限管理系統(tǒng)來說，本節(jié)內(nèi)容也非常簡單。
理論分析
當軟件實施人員進行系統(tǒng)實施的時候，會將一些訪問菜單定義為權(quán)限。然后定義角色，讓角色擁有權(quán)限。然后再將權(quán)限賦給用戶。
所以，當用戶請求某個URL的時候，要不該URL需要權(quán)限驗證，要不就是不需要權(quán)限驗證。
檢驗標準就是：看權(quán)限表里面有沒有該URL。檢驗的時候，唯一需要注意的是：URL參數(shù)，比如employeeManage?op=add。
數(shù)據(jù)庫模型
權(quán)限表：id<int>,name<varchar>,url<varchar>,description<varchar> | pk(id)
角色表：id<int>,name<varchar>,description<varchar> | pk(id)
角色-權(quán)限關(guān)系表：roleId<int>,privilegeId<int> | pk(roleId,privilegeId)
用戶-角色關(guān)系表：userId<int>(根據(jù)你系統(tǒng)的情況，也可能是varchar等),roleId<int> | pk(userId,roleId)
Ralasafe方案
Ralasafe權(quán)限管理中間件(
下載地址)，既可以管理和控制功能級權(quán)限，也可以管理和控制數(shù)據(jù)級權(quán)限。開發(fā)者還可以根據(jù)需求，只選擇功能級控制，或者只選擇數(shù)據(jù)級控制。
當
安裝好用戶元數(shù)據(jù)的時候，Ralasafe自動創(chuàng)建所有權(quán)限表。相關(guān)權(quán)限數(shù)據(jù)，都由Ralasafe界面進行管理（即錄入）。
Ralasafe的管理界面，在功能權(quán)限方面可以做到：
1，管理權(quán)限界面；
2，管理角色界面，并給角色賦權(quán)限；
3，給用戶分配角色界面。這里還需要注意：不同用戶管理可以給不同范圍的用戶分配角色。比如：總公司的管理員可以給所有人分配角色；分公司管理員可以給本分公司及下屬子公司用戶分配角色。
Ralasafe將最后一點視為數(shù)據(jù)級權(quán)限。詳見：
http://www.ralasafe.org/zh/guide/reference/safe.html#ralasafe 和
http://www.ralasafe.org/jforum/posts/list/11.page
將
org.ralasafe.webFilter.UrlAclFilter配置到web.xml即可，而且配置工作量極其少。
<filter>
<filter-name>ralasafe/UrlAclFilter</filter-name>
<filter-class>org.ralasafe.webFilter.UrlAclFilter</filter-class>
<init-param>
<param-name>loginPage</param-name>
<param-value>/ralasafe/demo/login.jsp</param-value>
</init-param>
<init-param>
<param-name>denyPage</param-name>
<param-value>/ralasafe/demo/noPrivilege.jsp</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>ralasafe/UrlAclFilter</filter-name>
<url-pattern>/ralasafe/demo/*</url-pattern>
</filter-mapping>
該Filter具有這些功能：
1，在用戶具有權(quán)限的時候，正常訪問；
2，在用戶不具有權(quán)限的時候，轉(zhuǎn)到拒絕頁面；
3，如果用戶沒用登錄，轉(zhuǎn)到登錄頁面，讓用戶先登錄。
其他
這里我簡單說說spring security。
spring security在控制功能權(quán)限的時候，還會幫助開發(fā)人員控制Dao/Service等組件。我個人認為這種控制是多余的。
因為，功能權(quán)限控制應該站在最終用戶角度進行考慮。Dao/Service等編程開發(fā)級的組件，并不是最終用戶關(guān)心的事情。所以無需進行功能權(quán)限控制。
另外，大家在使用spring security，我建議將功能級權(quán)限控制放在數(shù)據(jù)庫里面，而不是annotation到j(luò)ava code里面。因為annotation到j(luò)ava code里面，最終用戶就不能控制了。
注：ralasafe團隊博客在javaeye/baidu/blogjava等空間，同步發(fā)布。ralasafe官方網(wǎng)站：
http://www.ralasafe.org/zh
posted @
2010-09-02 21:55 細粒度權(quán)限管理 閱讀(2591) |
評論 (0) |
編輯 收藏
原文：
http://www.ralasafe.org/jforum/posts/list/66.page
Ralasafe自從2010年6月23日開源以來，得到廣大網(wǎng)友的支持和鼓勵，在此非常感謝。Ralasafe團隊也通過網(wǎng)站、論壇、博客、Email、QQ等各種方式與社區(qū)互動，形成交流。根據(jù)這段時間的社區(qū)維護情況，我們制定如下社區(qū)維護原則。
我們歡迎這樣的人，樂于回答他們的問題：
1，說話友好，平等切磋的人；
2，勤于學習，而不論技術(shù)高低，不論新手老手。即便你是新手，但只要你肯予學習，不斷交流，我們樂于提供幫助；
3，帶有個人偏見，但言之有物的人。
我們不歡迎這樣的人，也不想回答他們的問題：
1，出言不遜，帶有蔑視或者侮辱性語言的人；
2，懶惰的人，尤其是沒有看文檔，沒有對Ralasafe-demo進行揣摩，沒有進行基本學習的人；（文檔沒有看懂的人例外，確實我們可能撰寫方式有問題，個人理解力有差距等）
3，帶有個人偏見，且言之無物的人。
Ralasafe團隊將繼續(xù)保持開源，并致力于社區(qū)維護工作。對于新手，只要樂于學習，我們甚至會對學習難點，免費提供QQ遠程協(xié)助。
posted @
2010-09-02 15:04 細粒度權(quán)限管理 閱讀(460) |
評論 (0) |
編輯 收藏
2010年9月1日
摘要: Ralasafe是基于MIT協(xié)議開源的，數(shù)據(jù)級權(quán)限管理中間件。開源有2個月了。根據(jù)社區(qū)的反饋，我圍繞Ralasafe最佳實踐，書寫一系列BLOG。今天說的登錄控制，內(nèi)容主要有：哪些頁面需要登錄控制、登錄驗證邏輯、登錄后頁面轉(zhuǎn)向哪里，以及權(quán)限菜單等問題。雖然本系列講解權(quán)限管理，尤其是數(shù)據(jù)級權(quán)限管理。但嚴格意義來說，登錄控制，并不屬于權(quán)限管理內(nèi)容。它屬于用戶身份認證內(nèi)容。權(quán)限基本都與用戶相關(guān)，用戶首先就涉及到用戶名密碼驗證。所以我們從這里開始說起。
閱讀全文
posted @
2010-09-01 19:41 細粒度權(quán)限管理 閱讀(3717) |
評論 (2) |
編輯 收藏
2009年6月23日
摘要: 很多系統(tǒng)對于黑客不堪一擊。請看這樣的示例：
1. 前臺展現(xiàn)客戶能查看的客戶數(shù)據(jù)，而且用戶能刪除的客戶數(shù)據(jù)，就是前臺展現(xiàn)出來的數(shù)據(jù)；
2. 當用戶選擇某個用戶，點擊刪除按鈕，后臺執(zhí)行刪除操作。
比如，請求后臺刪除的url是：http://www.test.com/crm/customer.do?id=3
假設(shè)，id=13的客戶在前臺不顯示（因為當前用戶沒有對該客戶數(shù)據(jù)有刪除權(quán)限），但用戶輸入http://www.test.com/crm/customer.do?id=13 顯然id=13的客戶將被刪除掉。
有開發(fā)者建議采用id值不要使用自增長型，而改用其他型，比如hashcode等。這也不大合適，可以使用爬蟲輕松地將漏洞爬出來。
顯然，僅僅通過界面層次控制數(shù)據(jù)級權(quán)限是不夠的。
閱讀全文
posted @
2009-06-23 09:55 細粒度權(quán)限管理 閱讀(3476) |
評論 (3) |
編輯 收藏
2009年6月21日
今天是夏至，白天是一年中最長的。好好努力。此文激烈自己和同樣在努力的朋友們。
posted @
2009-06-21 21:52 細粒度權(quán)限管理 閱讀(385) |
評論 (1) |
編輯 收藏
摘要: 上一章講解通過設(shè)計器，設(shè)計出數(shù)據(jù)查詢，并在線測試。本章講解如何快速定制數(shù)據(jù)查詢，如果將業(yè)務(wù)代碼中的if else邏輯判斷去掉，如何將這種細粒度的權(quán)限集成到業(yè)務(wù)系統(tǒng)。
閱讀全文
posted @
2009-06-21 21:47 細粒度權(quán)限管理 閱讀(2116) |
評論 (0) |
編輯 收藏
2009年6月19日
摘要: 通過基于角色訪問控制，我們可以控制哪些人具有某種權(quán)限。比如總公司員工柴其貴、分公司員工李朵朵和營業(yè)部員工賈志宏，三個人都具有訪問“查詢員工”頁面權(quán)限。但，由于他們?nèi)怂诠炯墑e不同（總公司、分公司和營業(yè)部），進入查詢員工頁面，系統(tǒng)展示出來的員工數(shù)據(jù)應該是不同的。
為此，很多系統(tǒng)代碼里面充滿了if else邏輯判斷，造成業(yè)務(wù)與權(quán)限耦合。有更好的辦法去除這種耦合嗎？
閱讀全文
posted @
2009-06-19 11:52 細粒度權(quán)限管理 閱讀(2385) |
評論 (2) |
編輯 收藏
2009年6月18日
摘要: 本章詳細講解用戶角色權(quán)限關(guān)系。這也就是RBCA(Role Based Access Control，基于角色的訪問控制)?；诮巧刂颇Ｐ鸵呀?jīng)深入人心，關(guān)系并不復雜，廣泛運用于各個系統(tǒng)。通過給用戶賦予角色、角色擁有權(quán)限的模式，達到控制用戶具有權(quán)限的目的。同時，還復用了角色，這樣可以讓多個相同職務(wù)（或職能）的人擁有同樣的角色。RBCA模型怎么建立呢？又有哪些局限性。
閱讀全文
posted @
2009-06-18 10:57 細粒度權(quán)限管理 閱讀(3727) |
評論 (2) |
編輯 收藏