問題的提出：我們的需求是什么？
首先是系統(tǒng)中需要哪些權(quán)限。
權(quán)限應(yīng)該分類四類：??
? 一是系統(tǒng)方面，主要是對模塊的權(quán)限劃分 ，具體就是可見不可見，用戶能不能對該模塊進(jìn)行再授權(quán)?
? 二是數(shù)據(jù)庫操作權(quán)限，主要是瀏覽、增加，修改，刪除記錄，也可以理解為對象權(quán)限??
? 三是行級數(shù)據(jù)權(quán)限，又可以叫做對象實例級權(quán)限，主要是考慮到不是每個用戶都可以看到所有記錄的，比如在工資管理中一個部門用戶就只能看到本部門人員的工資，甚至只能看到本部門什么職位以下的人員的工資。
? 四是列級數(shù)據(jù)權(quán)限，即數(shù)據(jù)字段的權(quán)限，不是每個用戶都可以看到或是修改所有的字段的。
具體四類可能的權(quán)限劃分如下：
? 一系統(tǒng)權(quán)限，可見/可再授權(quán)??
? 二數(shù)據(jù)庫操作權(quán)限，瀏覽/增加/修改/刪除??
? 三行級數(shù)據(jù)權(quán)限，數(shù)據(jù)范圍
? 四列級數(shù)據(jù)權(quán)限，可見/修改
然后是可能存在的權(quán)限模式，現(xiàn)在考慮的是大集中模式下的權(quán)限管理
? 理解：什么是大集中模式下的權(quán)限管理。舉個例子總公司下面有分公司A和分公司B，總公司系統(tǒng)管理員分別在分公司A和分公司B中設(shè)定分公司系統(tǒng)管理員，則分公司A和分公司B數(shù)據(jù)是互不可見的，分公司系統(tǒng)管理員只對各自分公司負(fù)責(zé)，他們可以同時建立一個相同名字的角色，但這兩個角色是不同的。即下級只可以看到自己，上級可以看到所有。這個管理是可以嵌套的，即分公司A下面可能還會存在分公司，分公司下面還會有新的分部門。。。。 最近在設(shè)計權(quán)限方面的內(nèi)容，有些想法，亂彈一下。個人覺得實現(xiàn)權(quán)限系統(tǒng)主要是三個方面：
1、授權(quán)。主要是授權(quán)模型的維護(hù)，如資源、角色、用戶、部門的對應(yīng)關(guān)系等。
2、認(rèn)證。主要是用戶身份的認(rèn)證，以及取出用戶的權(quán)限。
3、校驗權(quán)限。當(dāng)用戶對某一資源進(jìn)行操作時，將用戶的權(quán)限與操作該資源所應(yīng)有的權(quán)限進(jìn)行比對校驗。
在對這三個方面進(jìn)行說明前，也想說說對數(shù)據(jù)權(quán)限的看法。什么是數(shù)據(jù)權(quán)限，很簡單，
考慮一種場景 （javaeye里的例子）
看看銷售數(shù)據(jù)
A銷售員可以看到自己的銷售情況和每一筆具體銷售業(yè)務(wù)，但是看不到B的
B銷售員可以看到自己的銷售情況和每一筆具體銷售業(yè)務(wù)，但是看不到A的
分公司銷售經(jīng)理則可以看到本部門的A和B的銷售情況，但是看不到其他分公司的銷售業(yè)務(wù)
集團(tuán)銷售Boss可以看到集團(tuán)內(nèi)所有分公司的銷售業(yè)務(wù)數(shù)據(jù)
共同點：他們都可以看到“銷售數(shù)據(jù)”這一模塊
不同點：他們讀取數(shù)據(jù)的范圍是不一樣的
這個也可以叫做實例級權(quán)限控制。有人認(rèn)為這種權(quán)限一般是放在業(yè)務(wù)里做的, 如果非要用一個固定的模型實現(xiàn),可以參考 ACL, 不過也是要在業(yè)務(wù)里寫 ACL 相關(guān)代碼的。確實，以前自己也都是放在業(yè)務(wù)里做的，但一直認(rèn)為這也應(yīng)該是權(quán)限系統(tǒng)的一部分，通過用戶的權(quán)限來構(gòu)造不同的sql語句。具體通過AOP實現(xiàn)，好象已經(jīng)有個開源的東西還沒看（lllyq的http://bba96.dev.java.net）。ACL對實例級權(quán)限控制感覺效率會有問題，個人看法。
具體來說：
1、授權(quán)
?? 具體開發(fā)里簡便的授權(quán)方式已經(jīng)成了用戶必提的要求，很明顯，僅僅基于role和權(quán)限交互是遠(yuǎn)遠(yuǎn)不夠的。現(xiàn)實中你必須把角色、用戶、部門三者全部與權(quán)限掛鉤。而這三者毫無疑問地就會存在權(quán)限繼承的問題。考慮一下，在部門A增加一個用戶，很顯然該用戶會繼承部門A的權(quán)限；同時如果在部門A下增加一個部門角色，該角色應(yīng)不應(yīng)該也繼承部門A的權(quán)限呢？也許需要一個規(guī)則接口，具體規(guī)則實現(xiàn)看客戶需求。
?? 再說說資源，這里僅討論系統(tǒng)資源不考慮數(shù)據(jù)資源。考慮一個“業(yè)務(wù)管理”的模塊，該模塊下面還有“項目管理”，“物品管理”，“采購管理”三個模塊，當(dāng)對用戶賦予了“業(yè)務(wù)管理”模塊的查看權(quán)限，用戶是否同時對“項目管理”，“物品管理”，“采購管理”具有查看權(quán)限呢？這里同樣存在資源權(quán)限繼承的問題。客戶的需求是不同的，所以同樣需要一個資源權(quán)限繼承的規(guī)則接口。
?? 最后說說授權(quán)信息的保存。考慮ACL。表設(shè)計：資源ID，權(quán)限主體ID，權(quán)限主體TYPE，資源操作權(quán)限。一開始考慮權(quán)限主體ID就是UserID，這樣會在認(rèn)證的時候效率很高，但考慮到部門A下有100個用戶，當(dāng)對部門A增加一個權(quán)限時，實際上會往ACL表里插入100條記錄，這就讓人不能接受了。
2、認(rèn)證
?? 其實就兩個方面，一是檢查是否存在這個用戶，二是取出用戶的權(quán)限。呵呵，這里有些絕對了，取出用戶的權(quán)限完全可以放到校驗權(quán)限里來做，不必這里一次性全讀出來。用戶的權(quán)限放在一個List里，對象可以構(gòu)造一個，兩個屬性：資源ID和資源操作權(quán)限。取出用戶的權(quán)限時候要用到上面定義的規(guī)則接口來組裝用戶實際的所有權(quán)限。
2、校驗權(quán)限
?? 這個就比較簡單了，個人傾向于在Action里完成這個工作，需要進(jìn)行權(quán)限檢查的Action實現(xiàn)一個接口，接口里有一個 public boolean hasPermission() ，寫個攔截器攔截即可。這里的關(guān)鍵還是通過資源權(quán)限繼承的規(guī)則接口來校驗用戶操作該資源的權(quán)限。
完全是個人亂彈，歡迎拍磚：）

開發(fā)中遇到這么一個要求，用戶USER這個PO里需要保存用戶的照片。一般情況下有兩種處理方法：一是直接保存圖片到數(shù)據(jù)庫；二是保存圖片到服務(wù)器端，PO字段保存一個聯(lián)接。考慮到用戶照片一般較小，采用第一種方法。

頁面里面，直接用webwork的FileUploadInterceptor攔截

xwork.xml里的配置

引用默認(rèn)的攔截器棧，棧里已經(jīng)包含F(xiàn)ileUploadInterceptor攔截，這里配置FileUploadInterceptor攔截的參數(shù)，設(shè)定上傳的文件為圖片
格式
Action類

這樣就OK了，考慮一個問題，就是action 必須要指定一個result ，實際這里的圖片顯示僅僅是要一個輸出流

而我的配置里面是

不知道這會不會有什么影響。或者這樣？

好久都沒有更新過BLOG了，別的原因沒有，就是變懶了。工作還算可以，加班不是太多。買了輛二手
自行車，修車就花了20，天天蹬著車往返于公司和家之間。又有新的樓盤開盤了，價格還是高得嚇人，
女朋友天天想著什么時候住上自己的房子，真是一件苦惱的事情。油價漲了我還有腿，可房價漲了呢？
在對自己重新補課，現(xiàn)在確實感到一些東西你不記下來忘得還是飛快的。節(jié)繩記之還是必須的。呵呵，
重新開始寫B(tài)LOG吧。

??? 來博羅調(diào)研已經(jīng)是第七天，后天的機票返回北京。短短的幾天給我的印象卻非常的深。
??? 這是我第一次出差調(diào)研和客戶打交道，習(xí)慣了面對機器，習(xí)慣了每天的編碼，或許自己從來沒有料到自己會出來面對人來交流。出公司的時候，領(lǐng)導(dǎo)說這是一次難得的鍛煉機會，現(xiàn)在來看確實是這樣。
印象一：工廠
??? 項目是廣東惠州市博羅縣的電子政務(wù)。從深圳機場出來到惠州，沿路兩旁全部是廠房和宿舍，一片接著一片，多得讓人吃驚，車子在高速路上飛馳，看不見田野，看到的是山是樓房。司機開玩笑說，我敢說你穿的衣服一定有一件產(chǎn)自廣東。人說中國是世界的工廠，那廣東一定是中國的工廠。
印象二：喝湯
??? 第一頓飯是在縣機關(guān)飯?zhí)贸缘谩３燥埱跋冉o打來了一盆湯，喝湯。習(xí)慣了吃完飯喝湯，這里卻是先喝湯再吃飯。以后在哪里吃飯都是這樣，先上湯，喝得差不多了再上菜。再就是早上出去吃早飯，沒有豆?jié){，沒有油條，更沒有包子，只有米線。第二天早上跑了大半個街道，不好意思，只有米線。
印象三：亂
??? 這個亂不是指這里的治安，指得是調(diào)研。其實在我來之前，公司已經(jīng)有過兩次前期的調(diào)研，大致的需求已經(jīng)清楚，我們所做的事把需求進(jìn)一步完善，五一后就開始正式開發(fā)。情況出乎我的意料，非常的不順利。在對工作流的演示完畢后，各種各樣的情況就來了：我們的領(lǐng)導(dǎo)不會打字，你們要想想辦法；流程已經(jīng)到下一個流程，上一個流程節(jié)點的人員可不可以強行把流程回退。種種情況讓我感到迷惑。很多概念都要解釋很長一段時間。總的感覺就是：人為干擾流程的因素太多，流程遲遲定不下來。然后就是發(fā)言的人特多，幾乎都是同時。其實這里也有很大一部分責(zé)任在于自己：沒有對客戶做好引導(dǎo)，他們的
思維還是停留在他們自己的日常辦公上。OA的實施不僅僅是我們要適應(yīng)他們，他們也要適應(yīng)一定的規(guī)范。對客戶如何引導(dǎo)，我想，這對我來說還是一個要好好思考的問題。
印象四：累
??? 其實來廣東之前已經(jīng)連續(xù)加了一個多禮拜班了。想著是這次調(diào)研會輕松一些，甚至還帶了XML的書，打算把這方面補一補，不都web2.0了嗎：）結(jié)果卻是比編程感覺更累。白天和客戶交流，中午和晚上一有空就要寫文檔，每天晚上都到12點，中午就沒有休息過。寫文檔真是一件枯燥而又繁重的工作。每一個button都要作出詳盡的描述，讓人氣餒。而流程的描述更是繁瑣幾乎要面面俱到，中間還有權(quán)限的分配。情況卻往往是這樣：客戶提出的流程很快發(fā)生了變化。還有就是，文字的描述要符合官方的習(xí)慣。例如，縣委就一定要在縣政府的前面。這點自己也是一直并未在意，但客戶就提意見了。
??? 最后，就是，廣東話我一句都聽不懂，呵呵。