前言

最近的專案在用restful風格在寫，果然url都有了意義，功能都可以從url中推測出來，restful的url和非restful的url最大的一個感官區別就是，rest的url可能存在一些變數，比如下面這樣：/check/api/user/12345/history，這個url解釋起來就是：檢視賬號為12345的使用者的歷史資料，而非rest的url是：/check/api/user/history。那麼，現在問題就來了，許可權控制的核心是判斷url，rest的url中卻有變數，那麼，rest風格的專案如何實現許可權控制呢？

實現

其實在我我寫這篇文章之前，我的思路是把url的變數去掉，然後存許可權表中，然後判斷的時候就把訪問的url按照相同的規則處理，再在資料庫中查，如果查到了代表有許可權，反之沒有。但事實證明，這種思路只有在變數在url的結尾時才可行。

首先我貼一下許可權表的結構，這個是許可權控制的核心表。

1. -- Create table
2. createtable STAFF_POWER  
3. (  
4.   stp_id      NUMBER notnull,  
5.   stp_name    VARCHAR2(40),  
6.   create_time TIMESTAMP(6),  
7.   stp_url     VARCHAR2(100),  
8.   stp_method  VARCHAR2(10)  
9. )  
10. tablespace CHECK_ZS  
11.   pctfree 10  
12.   initrans 1  
13.   maxtrans 255  
14.   storage  
15.   (  
16.     initial 64K  
17.     next 1M  
18.     minextents 1  
19.     maxextents unlimited  
20.   );  
21. -- Create/Recreate primary, unique and foreign key constraints 
22. altertable STAFF_POWER  
23.   addconstraint STP_PK primarykey (STP_ID)  
24.   using index
25.   tablespace CHECK_ZS  
26.   pctfree 10  
27.   initrans 2  
28.   maxtrans 255  
29.   storage  
30.   (  
31.     initial 64K  
32.     next 1M  
33.     minextents 1  
34.     maxextents unlimited  
35.   );  
36. altertable STAFF_POWER  
37.   addconstraint STP_UN unique (STP_URL, STP_METHOD)  
38.   using index
39.   tablespace CHECK_ZS  
40.   pctfree 10  
41.   initrans 2  
42.   maxtrans 255  
43.   storage  
44.   (  
45.     initial 64K  
46.     next 1M  
47.     minextents 1  
48.     maxextents unlimited  
49.   );  

然後比較關鍵的一點就來了，url存的時候將變數全部換成%，為什麼這樣呢，先看下我判斷許可權的sql：

1. <selectid="selectByUrlAndMethod"resultMap="BaseResultMap"parameterType="java.lang.String">
2.     select *  
3.     from STAFF_POWER  
4.     <where>
5.         and STP_METHOD = #{method}  
6.         and #{url} like STP_URL   
7.     </where>
8.   </select>

許可權攔截器的核心程式碼如下：

1. StaffPower power=powerSer.selectByUrlAndMethod(url, method);  
2.         if (power!=null) {  
3.             boolean isPass=role.getPowers()!=null && (","+role.getPowers()+",").contains(","+power.getStpId()+",");  
4.             if (isPass==false) {  
5.                 Result<String> result=new Result<String>(BaseRestController.ERROR, Code.ROLE_NO_PERMISSION, "您沒有許可權,請聯絡管理員");  
6.                 PrintWriter pw=resp.getWriter();  
7.                 pw.print(gson.toJson(result));  
8.                 pw.flush();  
9.                 pw.close();  
10.                 returnfalse;  
11.             }  
12.             return isPass;  
13.         }else{  
14.             log.error("沒有這個許可權   "+url+"  "+method);  
15.             Result<String> result=new Result<String>(BaseRestController.ERROR, Code.PERMISSION_NO_EXIST, "該模組還沒有設計許可權，暫時不能操作");  
16.             PrintWriter pw=resp.getWriter();  
17.             pw.print(gson.toJson(result));  
18.             pw.flush();  
19.             pw.close();  
20.             returnfalse;  
21.         }  

現在資料庫中有這樣一條許可權：

我現在想看歷史，於是訪問 /check/api/sourceTp/3803140612558/history，然後sql是怎麼執行的呢，下面是執行的結果：

1. [2017-05-1110:09:54.400] - [DEBUG] [http-nio-8080-exec-9  :17561] ==>  Preparing: select * from STAFF_POWER WHERE STP_METHOD = ? and ? like STP_URL   
2. [2017-05-1110:09:54.400] - [DEBUG] [http-nio-8080-exec-9  :17561] ==> Parameters: GET(String), /check/api/sourceTp/3803140612558/history(String)  
3. [2017-05-1110:09:54.403] - [DEBUG] [http-nio-8080-exec-9  :17564] <==      Total: 1

看到這裡，它的原理應該就很清楚了，許可權控制核心是url+method的判斷，而rest的url比較特別從而導致無法像原來那樣判斷，於是我把所有的變數替換為%，而%是sql模糊查詢的符號，所以就剛好可以借用sql的模糊查詢來完成判斷（中間不做任何處理）。

總結

判斷的核心是url+method，但最最核心（而且好多人都沒想到這種方法）的是使用%，%代表任意。