不管在是在service還是action加許可權驗證，實際是RBAC模組是可以分離的，我在去年的時候完成了這個模組，然後項目的時候只要把這個模組加進去就可以了。如果實際項目是可以通過url來控制許可權的，那麼就可以不用寫一行代碼。 在RBAC模組裡完全可以做到很細的控制。
資源概念(可以是url，還有剛才看到有人說.do後面的參數那不到，參數當然可以拿的的,只不過url被切分成兩部分而已，一部分就是參數.可以通過getQueryString得到)
資源就是想要的到的最終物質,我們可以給每一個資源定義一個許可權，也可以給某一類資源定義一個許可權,而web項目 url的tree特別容易用來管理資源。資源是一棵樹,如果你有管理樹根的許可權那麼就有了這顆樹的所有許可權。
許可權概念
許可權是對資源的一種保護訪問.使用者要訪問A資源前提是使用者必須有A資源的存取權限.
角色概念
實事上我們不會直接把許可權賦予給使用者，而是通過角色來賦予給使用者,因為使用者擁有某一種許可權是因為使用者扮演著某一種角色。
A是個經理,他管理著B公司,他擁有b,c,d的許可權。實際是不是A有這個許可權，而是因為Abo是經理。因為經理擁有b,c,d許可權
所以很顯然在許可權劃分上，我們會把許可權賦予給某一個角色，而不是賦予給個人。這樣帶來的好處是
如果公司換了經理，那麼只要再聘用一個人來做經理就可以了，而不會出現因為許可權在個人手裡導致許可權被帶走的情況
分組概念(分組也是一棵樹，使用者就是這裡的葉子)
只有角色是不夠的，B公司發現A有財務問題成立了一個財務調查小組,然後我們賦予了這個小組財務調查員的角色(注意是賦予小組這個角色).這樣這個小組的所有人員
都有財務調查的資格。而不需要給小組的每個人都賦予這個角色(實際上已經擁有了)，分組概念也適合部門，因為任何一個部門在公司裡或者社會上都在扮演著一個泛的角色。
使用者
使用者一定是屬於某一個分組的,不存在不屬於分組的使用者.不過使用者可以直接扮演(獲得)角色，或者通過屬於的分組來得到角色
最後一個概念
判斷使用者有沒有訪問資源的許可權就看這個使用者有沒有訪問這個資源的許可權,也就是說分組，分部門,分角色最終是以許可權來實現對資源的存取控制
