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

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

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

xwork.xml里的配置

引用默認的攔截器棧，棧里已經包含FileUploadInterceptor攔截，這里配置FileUploadInterceptor攔截的參數，設定上傳的文件為圖片
格式
Action類

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

而我的配置里面是

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

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

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