移動端與PHP服務端介面通訊流程設計 增強版

2022-04-29 02:30:07 字數 1688 閱讀 1991

增強地方一:

再增加2張表,乙個介面表,乙個授權表,設計參考如下:

介面表欄位名

字段型別

注釋api_id

int介面id

api_name

varchar(120)

介面名,以"/"作為分割線,如 blog/index/addblog

api_domain

varchar(256)

所屬領域

is_enabled

tinyint(1)

是否可用  1:可用 0:不可用

add_time

int新增時間(戳)

(注:只列出了核心字段,其它的再擴充套件吧!!!)

授權表欄位名

字段型別

注釋client_id

int客戶端id

api_id

intapi編號

api_name

varchar(120)

介面名,以"/"作為分割線,如 blog/index/addblog

is_enabled

tinyint(1)

是否可用  1:可用 0:不可用

add_time

int新增時間(戳)

expire_time

int過期時間(戳)

(注:只列出了核心字段,其它的再擴充套件吧!!!)

執行過程如下:

1、移動端與服務端生成的 api_token 進行對比,如果不相等,則直接返回錯誤,否則,進入下一步;

2、根據介面url,組裝 api_name,再加上客戶端傳回的 client_id 為引數,查詢 「授權表」記錄,如果記錄存在,且有效(是否可用,是否過期),則表示許可權驗證通過,返回介面資料,否則返回錯誤資訊;

增強地方二:

對於一些很特殊的介面,怎麼特殊,哪些算特殊,我也不知道,總而言之,就是感覺http請求有可能被劫取,傳遞引數有可能被竄改等情況,還是舉個例子來說吧:

有個直接轉賬介面,頁面上 我輸入的是5元,表示我要給對方某某轉賬5元,結果在http傳遞過程中,被人劫取並竄改成了 10000元,而且入賬物件改成了「黑客」的賬號,那不是虧大發了,思考了一下,應該有2種方案解決這個問題,

方案一:走https,這個就不多說,比較公認的安全機制;

方案二:走數字簽名,實現原理如下:

乙個http請求,假如需要傳遞如下3個引數

引數名1=引數值1

引數名2=引數值2

引數名3=引數值3

我們可以再追加乙個引數,該引數的名為identity_key (名字是什麼不重要),該引數的值為前幾個引數值按順序相加,再加密後的結果。

即:identity_key = md5('引數值1' + '引數值2' + '引數值3' + '加密金鑰');

於是,最終傳遞的引數有:

引數名1=引數值1

引數名2=引數值2

引數名3=引數值3

client_id=client_id值

identity_key=md5('引數值1' + '引數值2' + '引數值3'+ 'client_id值' + '加密金鑰')

服務端接到引數後,再按相同的加密規則重新生成乙份identity_key,服務端的identity_key和客戶端的identity_key 進行校對,如果不相等,表示被竄改過,接下來怎麼操作,自己看著辦吧!

移動端與PHP服務端介面通訊流程設計 基礎版

非開放性平台 公司內部產品 介面特點彙總 1 因為是非開放性的,所以所有的介面都是封閉的,只對公司內部的產品有效 2 因為是非開放性的,所以oauth那套協議是行不通的,因為沒有中間使用者的授權過程 3 有點介面需要使用者登入才能訪問 4 有點介面不需要使用者登入就可訪問 針對以上特點,移動端與服務...

移動端與PHP服務端介面通訊流程設計 基礎版

非開放性平台 公司內部產品 介面特點彙總 1 因為是非開放性的,所以所有的介面都是封閉的,只對公司內部的產品有效 2 因為是非開放性的,所以oauth那套協議是行不通的,因為沒有中間使用者的授權過程 3 有點介面需要使用者登入才能訪問 4 有點介面不需要使用者登入就可訪問 針對以上特點,移動端與服務...

移動端與PHP服務端介面通訊流程設計 基礎版

針對 非開放性平台 公司內部產品 介面特點彙總 1 因為是非開放性的,所以所有的介面都是封閉的,只對公司內部的產品有效 2 因為是非開放性的,所以oauth那套協議是行不通的,因為沒有中間使用者的授權過程 3 有點介面需要使用者登入才能訪問 4 有點介面不需要使用者登入就可訪問 針對以上特點,移動端...