1、如何使用apipost模擬手機實現請求發送

一、ApiPost中有專門針對于模擬手機請求發送的參數

首先我們新建一個接口，訪問www.baidu.com然后點擊發送

然后我們在創建一個接口，這個是訪問移動版的www.baidu.com不過這里需要設置一下頭部參數user-agent

在選擇參數值，這里ApiPost自己給我了兩個參數值

Android

版本：Mozilla/5.0 (Linux; U; Android 8.1.0; zh-cn;BLA-AL00 Build/HUAWEIBLA-AL00) Chrome/57.0.2987.132 Mobile Safari/537.36

iOS

版本：Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.113 Safari/537.36

這樣就實現了移動端的接口測試了

二、設置User Agent的原因

Web端和移動端它們發送請求的時候請求是不一樣的，如何才能更好的去完成移動端的接口測試，就需要去了解User Agent。現在很多網站都同時有web端和移動端，但是用web瀏覽器和移動端瀏覽打開它們展示的界面并不是一樣的。不一樣的原因是User Agent的不同。

User Agent

中文含義用戶代理，簡稱為UA。它是一個特殊字符串頭，使得服務器能夠識別客戶使用的操作系統及版本、CPU 類型、瀏覽器及版本、瀏覽器渲染引擎、瀏覽器語言、瀏覽器插件等

Web  端常用的User Agent：

1. Chrome  目前使用的User Agent：

MAC：Mozilla/5.0(Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/50.0.2661.102 Safari/537.36

Windows：Mozilla/5.0 (Windows; U; Windows NT 5.2)AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13

2. Firefox

目前使用的User Agent：

MAC：Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11;rv:49.0) Gecko/20100101 Firefox/49.0

Windows：Mozilla/5.0 (Windows; U; Windows NT 5.2)Gecko/2008070208 Firefox/3.0.1

                   Mozilla/5.0 (Windows; U; Windows NT 5.1) Gecko/20070309 Firefox/2.0.0.3

                   Mozilla/5.0 (Windows; U; Windows NT 5.1) Gecko/20070803 Firefox/1.5.0.12

移動端常用的User Agent：

1.   iPhone ：

Safari：

Mozilla/5.0 (iPhone; CPU iPhone OS10_1_1 like Mac OS X) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0Mobile/14B100 Safari/602.1

Mozilla/5.0 (iPhone; CPU iPhone OS5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206Safari/7534.48.3

QQ瀏覽器：MQQBrowser/38 (iOS 4; U; CPU like Mac OS X; zh-cn)

UC瀏覽器：IUC(U;iOS 5.1.1;Zh-cn;320*480;)/UCWEB8.9.1.271/42/800

微信自帶瀏覽器：Mozilla/5.0(iPhone; CPU iPhone OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, likeGecko) Mobile/9B176 MicroMessenger/4.3.2

2.   Android ：

自帶瀏覽器：Mozilla/5.0(Linux; U; Android 4.0.3; zh-cn; M032 Build/IML74K) AppleWebKit/534.30 (KHTML,like Gecko) Version/4.0 Mobile Safari/534.30

QQ瀏覽器：Mozilla/5.0 (Linux; U; Android 4.0.3; zh-cn; M032Build/IML74K) AppleWebKit/533.1 (KHTML, like Gecko)Version/4.0 MQQBrowser/4.1Mobile Safari/533.1

UC瀏覽器：JUC (Linux; U; 2.3.7; zh-cn; MB200; 320*480)UCWEB7.9.3.103/139/999

微信自帶瀏覽器：Mozilla/5.0 (Linux; U; Android2.3.6; zh-cn; GT-S5660 Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko)Version/4.0 Mobile Safari/533.1 MicroMessenger/4.5.255

2、API接口簽名驗證_MD5加密出現不同結果的解決方法

系統在提供接口給第三方系統使用時，通常為了安全性會做接口加密。
設計原則 ：使用HTTPS安全協議 或 傳輸內容使用非對稱加密，這里采用后者。

在對參數進行加密，生成sign時，相同的參數兩次加密的結果不一樣。

加密規則：

1.拼接出來的字符串不一致
測試時，在加密前將要加密的字符串打印出來比較，發現兩次字符串一致。

2.編碼問題
加密時，兩次的默認編碼不一致。
在上述加上默認編碼： byte[] btInput = content.getBytes("utf-8"); ，問題解決。

簡單實現：
1.接口調用方和接口提供方約定好統一的參數加密算法。
2.接口調用方在調用時把加密后的signature放在參數中去請求接口。
3.判斷時間戳有效期。
4.將參數用約定號的加密算法進行加密，與參數中的signature進行比較，一致則調用接口。

3、常見認證機制總結

閱讀這篇文檔你可以了解到一些常見的認證方式及其優缺點，在實際場景中該如何去搭配各種認證方式​。​

了解 Authorization 前，需要先了解以下術語

認證是對身份的一種確認過程；也可以說是身份有效性的確認；Are you who you say you are?

授權是指對行為或資源允許的過程；Are you allowed to do this action?
對應的是鑒權，是對行為或資源是否允許的確認過程

資源的擁有者，一般都是用戶自己

資源的認證服務器，提供 Authorization Endpoint 及 Token endpoint

請求 authorization API

請求 access_token API

資源服務器，具體的 Service 上的 API

需要申請訪問資源的應用，可以是 APP、JS APP、Server 等

Access token 是由 Authorization Server 通過安全認證后，生成臨時用于訪問 Resource 的憑證；
JWT 就是一種具體的實現方式.
可以標識身份；
也可以是 self-contain 認證權限信息；
一般有效期較短；
用于 Resource Server 的請求中

可以參考 JWT ，
有個使用中的小問題，記錄下
Base64URL 與 Base64 算法
Base64 有三個字符+、/和=，在 URL 里面有特殊含義，所以要被替換掉：=被省略、+替換成-，/替換成_ 。這就是 Base64URL 算法。JWT 會使用 Base64URL 編碼的，主要是考慮到一般 jwt Token 會直接被放在 URL 上。

Refresh token 是由 Authorization Server 通過安全認證后，生成用于長時間內獲取 access_token 的憑證；
僅用于 Authorization Server 的請求中（不可傳輸給其他服務）；
若 access_token expire 了，則使用 Refresh token 去 Authorization Server 重新獲取；
refresh token 可以管理 access token，防止 access_token 被多個 client 使用；

參考

參考

該方式在調用 API 前需要先在該 API Provider 那申請一個（對）API key，如 APPID 和 APPSecret，在請求的過程中在 query 或 header 中加上這個（對）API key；其中 APPSecret 一般都是在 Server-to-Server 的場景中使用，而 APPID 可通過終端 JS 傳遞到后端服務器，然后獲取內存中的 APPSecret，一起放在 query 或 header 中轉發到 API 服務；

圖中因為僅考慮認證的機理。
優點：
這種認證模式的好處就是簡單且能識別 API 調用者的身份；
有 APPSecret，所以一般都是在 Server-to-Server 的場景中使用；

該方式其實就是采用了 base64 對 username 及 password 進行混淆編碼后放在 header 中，形如

該方式比較簡單，但是如果在互聯網傳輸，那么需要保證協議是 https 的，防止被攔截解碼獲取明文。

該方式是一種更高級別、更安全的授權方式，API provider 與 API caller 事先約定一個 Secret Key 及算法，然后保證只有雙方知道，Caller 在調用 API 時，按照雙方規定的算法對請求進行簽名，得到 signature，并將該 signature 一并發到 Server 端，Server 端同理對請求進行簽名，也得出一個 signature，然后對比兩個 signature 是否 match，match 則認證通過，否則拒絕；

該方式重點就是在保存 Secret Key，所以一般 Web 或能直接查看到 JS 源碼的場景都不適用；一般在 IOS、Android 等 Native 應用中使用場景較多；

優點：

OAuth2.0 主要是解決了在互聯網上 Resource Owner 與 Client Application、third-parties 訪問數據安全的問題。提供了一套安全的認證標準。

該認證方式是一種較安全的認證方式（雖然流程看起來復雜），其中主要是涉及到兩個步驟一個是授權服務請求 authorization 過程，另一個是 Application client 請求 access_token 過程（這里有 CORS 問題，所以 Authorization Server CORS 必須是 allow 的），在網上找到以下圖，完美使用了 Authorization Code 的認證方式；

解析

雖然目前 Authorization Code 的方式還是使用的比較多，但據 APP 開發童靴了解到，在 APP 端惡意的 APP 的確能攔截到 Authorization Endpoint 的響應，獲取到 code，然后去獲取 access_token 的問題。具體的問題可參考 IETF，感興趣童鞋可搜索【IOS 逆向安全】相關話題。

下圖是 Authorization Code 認證方式擴展后的認證方式即 PKCE，主要差異有兩點：

該方式是一種 Authorization Code 的簡化后的認證方式，它將交換 Authorization Code 請求直接簡化（刪除），Application Client 直接攜帶 client_id 去發起 request access_token 的請求，即省略了圖中的 ⑥⑦ 步驟，直接跳到 ⑧ 返回 access_token。

【前世今生】
該方式最初是為了給 Native APP 和 JS APP 使用的，它所出現的原因是因為最初瀏覽器有 CORS 的困擾，POST 請求只能在同 domain 下訪問 Authorization Server（見圖中 ⑤ 輸入賬號密碼后向自己的 AuthorizationServer 請求認證）而 ⑦ 步驟是 POST 請求且跨域，無法實現，所以省略了 ⑥⑦ 步驟，是一種妥協的方案；而如今 CORS 已不是什么問題，只要 Server 允許就可以訪問，但現在已經推薦使用 PKCE 的方式去實現。
authorization 請求

其 response 僅僅是采用了 access_token

IETF 規定 Authorization Server 上 Authorization Endpoint 必須同時支持 POST 和 GET 請求，而 Token Endpoint 必須僅支持 POST 請求。

認證流程，如圖

邏輯相對較簡單，對于用戶而言，基本沒有授權可言（可能用戶就不知道有后面這一步）。
2 中請求

認證流程，如圖，該認證方式一般在安全可信且是 https 的 server-to-server 場景中使用

1 中請求

目前在國內大部分云廠商都是采用 AK/SK 的認證模式；一般都是先在云廠商平臺注冊應用，并生成一對 access key 和 access secret，然后對請求參數及其它按照云廠商提供的算法生成簽名，簽名與 access key 一起發送到服務器端，然后使用相同的算法生成簽名，比較。這種方式相對其它的認證方式會更安全，一般使用場景是在 machine-to-machine（M2M），保證了 access secret 不會被泄露且不會在網絡中傳輸，一般情況下生成簽名的算法也都是不可逆的，所以即使被攔截也無法篡改數據；

大致描述了 AK/SK 的簡單過程，signature 的算法也可以參考該地址
可以與 HMAC 進行對比下，可能會發現比較相似，可以認為是升級版。

最后推薦一個網站，需要設計 Authorization Portal 的可以參考一波。

https://aaronparecki.com/oauth-2-simplified/

https://tools.ietf.org/html/rfc7636#section-1.1 PKCE
https://www.ibm.com/support/knowledgecenter/zh/SSPREK_9.0.4/com.ibm.isam.doc/config/concept/oauth_pkce.html PKCE

https://oauth.net/2/ OAuth

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS CORS

https://tools.ietf.org/html/rfc6749#page-21 Token Endpoint 及 Authorization Endpoint

https://support.huaweicloud.com/devg-apisign/api-sign-algorithm.html AK/SK

https://juejin.im/post/5c9ada58e51d453fea4a99bc

https://jwt.io/introduction/ JWT

https://tools.ietf.org/html/rfc7519 JWT

4、淘寶調用接口(API)時需要對請求參數進行簽名驗證。

根據參數的升序排序,連接起來,然后加上密鑰進行MD5加密,產生SIgn用于數據安全校驗,他們API那邊也會以相同的方式加密,然后對比,一致的話,就通過,不一致的話,就拒絕訪問.!

5、如何通過json把簽名一起反饋

應用基于HTTP POST或HTTP GET請求發送Open API調用請求時，為了確保應用與百度REST服務器之間的安全通信，防止Secret Key盜用、數據篡改等惡意攻擊行為，百度REST服務器使用了參數簽名機制。應用在調用百度Open API之前，需要為其所有請求參數計算一個MD5簽名，并追加到請求參數中，參數名為“sign”。百度REST服務器在接收到請求時會重新計算簽名，并判斷其值是否與應用傳遞過來的sign參數值一致，以此判定當前Open API調用請求是否是被第三者偽造或篡改。
應用在調用Open API之前需要通過 百度OAuth2.0服務獲得用戶或平臺的授權，獲取到授權后將會拿到以下3個重要參數：
access_token：基于https調用Open API時所需要的訪問授權碼；
session_key：基于http調用Open API時所需要的訪問授權碼；
session_secret：基于http調用Open API時計算參數簽名用的簽名密鑰。
其中，session_secret這個參數就是做參數簽名時所需要的簽名密鑰。這與Facebook、人人網等平臺稍微有所區別，這兩個平臺在做參數簽名時所用的簽名密鑰一般有2個：
如果是通過應用服務端調用Open API，則注冊應用時所拿到的應用密鑰（即API Key）就是參數簽名密鑰；
如果是通過JavaScript、ActionScript等客戶端語言調用Open API，則應用獲取到用戶授權后所拿到的Session Secret就是參數簽名密鑰。當然，通過服務端調用Open API時也可以用Session Secret作為簽名密鑰。
簽名算法
假設參與參數簽名計算的請求參數分別是“k1”、“k2”、“k3”，它們的值分別是“v1”、“v2”、“v3”，則參數簽名計算方法如下：
將請求參數格式化為“key=value”格式，即“k1=v1”、“k2=v2”、“k3=v3”；
將格式化好的參數鍵值對以字典序升序排列后，拼接在一起，即“k1=v1k2=v2k3=v3”；
在拼接好的字符串末尾追加上應用通過百度OAuth2.0協議獲取Access Token時所獲取到的session_secret參數值；
上述字符串的MD5值即為簽名的值。
注意：計算簽名時的請求參數中不要包含sign（簽名）參數，因為sign參數的值此時還不知道，有待計算。
另外，計算簽名的時候不需要對參數進行urlencode處理（“application/x-www-form-urlencoded”編碼），但是發送請求的時候需要進行urlencode處理，這是很多開發者最容易犯錯的地方。

轉載請帶上網址：http://m.fzog.com.cn/posjitwo/111170.html