restful專案的許可權控制實現技巧

2021-07-31 22:03:41 字數 2758 閱讀 2138

最近的專案在用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的結尾時才可行。

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

-- create table

create table staff_power

( stp_id number not null,

stp_name varchar2(40),

create_time timestamp(6),

stp_url varchar2(100),

stp_method varchar2(10)

)tablespace check_zs

pctfree 10

initrans 1

maxtrans 255

storage

( initial 64k

next 1m

minextents 1

maxextents unlimited

);-- create/recreate primary, unique and foreign key constraints

alter table staff_power

add constraint stp_pk primary key (stp_id)

using index

tablespace check_zs

pctfree 10

initrans 2

maxtrans 255

storage

( initial 64k

next 1m

minextents 1

maxextents unlimited

);alter table staff_power

add constraint stp_un unique (stp_url, stp_method)

using index

tablespace check_zs

pctfree 10

initrans 2

maxtrans 255

storage

( initial 64k

next 1m

minextents 1

maxextents unlimited

);

每個欄位的意思我解釋一下,id是主鍵,name是這條許可權的名字,time是建立時間,由系統自動生成,url是url,method是訪問方式。

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

select *

from staff_power

and stp_method = #

and # like stp_url

我用的mybatis。

許可權***的核心**如下:

staffpower power=powerser.selectbyurlandmethod(url, method);

if (power!=null)

return ispass;

}else

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

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

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

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

Vue專案的前端許可權控制

本文主要介紹在vue專案中如何進行前端許可權控制。路由許可權 路由許可權就是使用者只能訪問到自己有許可權訪問到的頁面,對於無許可權的頁面可以跳轉到404頁面或者無許可權提示。下面通過兩種方式來實現對路由的許可權控制。1.動態生成路由表 第一種方式是動態生成路由表,前端原始的路由表中只儲存一些基礎的路...

專案管理(八) 控制專案的範圍

接著上篇,確定了專案的利益相關者之後,先別急著進入開發階段,我們接下來要做的是先控制專案的範圍,專案的範圍控制好了才能保證後續的開發不會因為專案範圍變更而做大量無用功,看下面介紹 一 確定專案不做什麼 實踐經驗告訴我們,在進行專案範圍變更時,或者說在劃分專案邊界時,確定專案不做什麼比確定專案做什麼更...

專案管理 關於專案的工期控制

引言 專案工期的控制,應該是開發人員,專案經理,產品經理最為之關心,也最頭疼的問題。關於工期的控制,我有幾點思考 具體實施 在需求階段,應該對專案的可行性進行分析。結合團隊的技術實力,客觀的分析。制定每個階段,可量化的需求標準。需求不確定或者根本就是不行的專案,工期控制是無從談起的。在實施階段,對於...