Telerik Fiddler Everywhere是一個安全的、現(xiàn)代的Web調(diào)試代理，適用于macOS、Windows和Linux，可用于測試端到端行為的可信調(diào)試工具。它的強(qiáng)大之處在于可以響應(yīng)到達(dá)瀏覽器之前修改響應(yīng)，以測試和調(diào)試web應(yīng)用程序。Fiddler Everywhere為Web、移動和桌面調(diào)試提供了一種簡單的方法，可以節(jié)省大量的時間和成本。
Telerik Fiddler Everywhere提供的功能允許您修改、模擬、過濾和自動處理HTTP(S)流量，開發(fā)人員可以通過動態(tài)更改請求和響應(yīng)來模擬各種場景。Fiddler的規(guī)則系統(tǒng)是高度可定制的，并且在處理網(wǎng)絡(luò)流量時提供了很大的靈活性。本文將演示使用Telerik Fiddler Everywhere可以解決的五大調(diào)試問題。
獲取Telerik Fiddler Everywhere新版下載
Telerik_KendoUI技術(shù)交流群（QQ）：726377843
1. 語法錯誤
語法錯誤是在開發(fā)過程中引起bug的主要原因之一，雖然有復(fù)雜的IDE工具用于維護(hù)手動編寫的代碼庫，但是當(dāng)語法錯誤出現(xiàn)在對在線API的調(diào)用中或作為接收到的HTTPS響應(yīng)的一部分時，很難查明語法錯誤。
Fiddler headers文件和body檢查器是跟蹤這類錯誤的好地方，讓我們通過一個示例應(yīng)用程序來演示這一點，該應(yīng)用程序調(diào)用公共NASA API來獲取當(dāng)天的Day (APOD)圖片。
我們使用的初始來源如下：
<html>
<head>
<script>
let nasa_endpoint = "http://api.nasa.gov/planetary/apod?1&api_key=";
let api_key = "DEMO_KEY";
let apod = fetch(nasa_endpoint + api_key)
.then((response) => response.json())
.then(data => {
document.getElementById('img').src = data['url'];
})
</script>
</head>
<body>
<img id="img"/>
</body>
</html>
為了演示，上面的頁面在本地https服務(wù)器上運行，地址為192.168.100.4:8080。
在使用Fiddler的瀏覽器捕獲模式時，我們可以立即看到應(yīng)用程序加載了，但是對NASA API的獲取請求失敗，狀態(tài)碼為400 （Bad request）。
雙擊會話進(jìn)一步顯示服務(wù)器的響應(yīng)消息，這表明我們使用了不正確的字段。現(xiàn)在可以使用Request選項卡中的Params檢查器來進(jìn)一步分析傳遞的查詢參數(shù)。這里，我們的API端點包含一個名為“1”的附加鍵，它沒有值——這導(dǎo)致了問題。
雖然狀態(tài)碼400不是那么具有描述性，但有時API將幫助我們使用更具體的狀態(tài)碼來識別問題。重寫上面的代碼片段，以便現(xiàn)在它使用正確的端點。但是，這次將有意地在所需API密鑰的值中引發(fā)語法錯誤。
<script>
let nasa_endpoint = "http://api.nasa.gov/planetary/apod?api_key=";
let api_key = "WRONG_KEY"
let apod = fetch(nasa_endpoint + api_key)
.then((response) => response.json())
.then(data => {
document.getElementById('img').src = data['url'];
})
</script>
這一次，NASA API返回狀態(tài)碼403（未授權(quán)）。默認(rèn)情況下，Fiddler Everywhere配置為顯示和突出顯示狀態(tài)碼4xx和5xx的會話，以便更容易地檢測有問題的會話（如果需要，您可以在流量網(wǎng)格中顯示和隱藏不同的列）。
上面立即顯示問題在使用的API密鑰值內(nèi)，開發(fā)人員可以快速修復(fù)。
2. 邏輯錯誤
像語法錯誤一樣，當(dāng)我們的代碼庫或API本身出現(xiàn)邏輯錯誤時，一個問題就會出現(xiàn)并破壞我們的web應(yīng)用程序。
稍微修改一下上面的例子：
<script>
let nasa_endpoint = "http://api.nasa.gov/planetary/apod?api_key=";
let api_key = "DEMO_KEY"
let apod = fetch(nasa_endpoint + api_key)
.then((response) => response.json())
.then(data => {
document.getElementById('img').src = data['title'];
})
</script>
你注意到邏輯錯誤了嗎？這不是顯而易見的。這里的問題是基于來自NASA端點的結(jié)果，它返回一個具有多個鍵的對象，包括指向圖像和縮略圖的URLs。在這個特定的例子中，我們的JS代碼使用title鍵的值，并將其分配為HTML圖像的源。錯誤可能不會立即被檢測到——對NASA API的初始調(diào)用按預(yù)期工作。但是，在Fiddler中運行上述代碼將顯示以下內(nèi)容：
明確在//192.168.100.4:8080上運行應(yīng)用程序，所以第一個會話是預(yù)期的。在內(nèi)部應(yīng)用程序調(diào)用//api.nasa.gov/planetary/apod，因此這也是另一個預(yù)期的會話。
但是應(yīng)用程序有一個沒有正確加載的圖像，并且我們看到第三個會話返回狀態(tài)404 （not Found）。這是應(yīng)該通過JSON鍵值對中包含的URL構(gòu)造的會話，但是我們可以立即看到添加的查詢參數(shù)不是預(yù)期的HTTP地址（指向JPG圖像），而是包含其他信息的字符串。
而在簡化的場景中，問題是由我們自己的代碼庫中的邏輯錯誤引起的（因為我們使用了data["title"]替代data["url"]），同樣類型的問題可能是后端服務(wù)器故障的結(jié)果。例如，我們可以在代碼庫中調(diào)用正確的屬性，但其值可能會被服務(wù)器API改變。在這兩種情況下，F(xiàn)iddler都允許您快速過濾和檢測該信息并應(yīng)用所需的修復(fù)。
最后，運行適當(dāng)?shù)腁PI調(diào)用。
<script>
let nasa_endpoint = "http://api.nasa.gov/planetary/apod?api_key=";
let api_key = "DEMO_KEY"
let apod = fetch(nasa_endpoint + api_key)
.then((response) => response.json())
.then(data => {
document.getElementById('img').src = data['url'];
})
</script>
現(xiàn)在我們可以看到所有預(yù)期的API調(diào)用，Fiddler甚至可以預(yù)覽圖像或HTML頁面。
3. 執(zhí)行錯誤（帶有規(guī)則的錯誤模擬）
在前面的小節(jié)中，我們討論了如何使用Fiddler來檢測web應(yīng)用程序中的語法和邏輯錯誤。
但是，您不必等到應(yīng)用程序崩潰（特別是在生產(chǎn)環(huán)境中）才測試是否有恢復(fù)機(jī)制，或者是否向最終用戶傳遞了正確的信息。
在這里，您可以使用Fiddler調(diào)試各種問題，模擬狀態(tài)碼和加載替代響應(yīng)，來充分測試您的web應(yīng)用程序處理不同場景的能力。
Fiddler最強(qiáng)大的功能之一就是它的Rules選項卡，簡單地說，這個應(yīng)用程序部分使您能夠調(diào)試、修改、過濾和/或完全模擬會話。
在使用小天文應(yīng)用程序時，我們可以使用規(guī)則來模擬各種狀態(tài)碼。您不需要訪問后臺——請求和響應(yīng)的修改發(fā)生在中間，這就是為什么像Fiddler這樣的工具被稱為MITM代理（中間人）。
例如：
1. 捕獲來自APOD應(yīng)用程序的流量。
2. 打開上下文菜單并使用Add New Rule特性。
3. 在Fiddler 的 Rules Builder中，創(chuàng)建使用Return預(yù)定義響應(yīng)操作的新規(guī)則。
通過以上步驟，您可以在幾秒鐘內(nèi)模擬服務(wù)器行為或測試不同的場景。不需要修改后端，甚至不需要訪問服務(wù)器！Fiddler站在中間，允許您模擬web應(yīng)用程序的生產(chǎn)或過渡環(huán)境。
雖然上面的示例展示了如何使用預(yù)定義的HTTP響應(yīng)列表（模擬不同的狀態(tài)碼），但您也可以創(chuàng)建完全自定義的響應(yīng)，這使您能夠測試潛在的修復(fù)或新設(shè)計——同樣無需在應(yīng)用程序或服務(wù)器中進(jìn)行更改。
例如：
-
從目標(biāo)頁面捕獲流量。
-
打開上下文菜單并使用Add New Rule特性。
-
在Fiddler的 Rules Builder中，創(chuàng)建一個使用Return Manual Response或Return File操作的新規(guī)則。
4. 運行時更改和錯誤
Telerik Fiddler Everywhere最強(qiáng)大的功能之一是它能夠在HTTP會話執(zhí)行期間“暫停”流量并對其進(jìn)行修改，可以使用Fiddler暫停執(zhí)行一個目標(biāo)API調(diào)用，然后修改它的操作，以修復(fù)錯誤或展示一個全新的現(xiàn)實，F(xiàn)iddler社區(qū)很熟悉這個特性——Fiddler斷點。
在Fiddler Everywhere中，您可以創(chuàng)建兩種類型的斷點。第一個將在HTTP請求發(fā)送到服務(wù)器之前暫停會話，而第二個將在HTTP響應(yīng)發(fā)送到客戶端之前暫停會話。
上述特性的直接效果是，您可以在實時流量到達(dá)目標(biāo)目的地之前對其進(jìn)行修改。這里的可能性是無窮無盡的——您可以測試任何API調(diào)用，看看它如何處理不同的headers、cookies和bodies，還可以在不訪問客戶端或服務(wù)器的情況下“破解”一個頁面，所需要的只是Fiddler作為代理站在中間并使用斷點。
讓我們通過一個快速演示來可視化這個過程，將使用一個知名的在線服務(wù)來模擬緩存的端點。
1. 啟動Fidder Everywhere并使用瀏覽器捕獲模式。
2. 打開一個模擬緩存響應(yīng)（如//httpbin.org/cache）的端點。
如果在HTTP請求中存在If-Modified-Since header或If-None-Match，則返回304，否則它返回與GET（200）相同的結(jié)果。如果這是您第一次訪問該頁面，它將顯示200，刷新頁面，您將收到狀態(tài)304。
我們將使用Fiddler暫停請求執(zhí)行，并在上述headers到達(dá)服務(wù)器之前顯式地添加或刪除它們。
3. 從捕獲的會話打開上下文菜單，并使用“Add New Rule”。
4. 在Rules Builder中，添加名為“Set Breakpoint”的操作，并將其指定為在 “Before Sending a Request”使用。
5. 返回到瀏覽器并刷新頁面。
此時，F(xiàn)iddler將暫停HTTP請求的執(zhí)行。一旦請求暫停，您就可以加載request檢查器并使用Raw選項卡進(jìn)行任何修改。
6. 最后取消暫停請求，會話將繼續(xù)執(zhí)行。
通過上面的代碼，我們剛剛做了一個運行時修改，改變了客戶端和服務(wù)器的操作。如前所述，在這兩個目的地都沒有實際的改變。
5. 測試性能和安全性
許多現(xiàn)代web應(yīng)用程序使用各種可能導(dǎo)致性能或安全問題的功能，一個典型的例子是身份驗證，它通常鏈接到需要為客戶端提供不間斷服務(wù)的后端服務(wù)器。測試服務(wù)器的漏洞和弱點，以幫助防止?jié)撛诘墓簦情_發(fā)人員的一項重要任務(wù)。
Fiddler Everywhere允許您測試服務(wù)器端點是否存在安全問題，例如下面的示例。您可以通過遵循最佳實踐來測試應(yīng)用程序是否具有安全的身份驗證過程，例如為連續(xù)請求創(chuàng)建指數(shù)重試。
考慮這樣一個場景：web應(yīng)用程序試圖使身份驗證請求失敗。服務(wù)器（在本例中為HTTPBin）始終返回狀態(tài)500，提示我們的應(yīng)用程序不斷重試。
使用Fiddler，我們可以從應(yīng)用程序（進(jìn)程名節(jié)點：16176）捕獲流量，并立即識別幾個問題：
-
重新嘗試的請求似乎永無止境。
-
重試的請求在一段特定時間后執(zhí)行，缺乏指數(shù)回退策略。
您可以從Request Time列中注意到這一點，或者在Fiddler Everywhere中選擇所有會話，然后切換到Overview選項卡，確認(rèn)每個請求之間沒有指數(shù)計時。
這些問題可能導(dǎo)致嚴(yán)重的問題，例如如果服務(wù)器長時間不可用，應(yīng)用程序的用戶將不斷觸發(fā)許多請求，可能導(dǎo)致自己造成的攻擊，使服務(wù)器無法響應(yīng)。
從Fiddler獲得信息后，我們可以審查申請。演示應(yīng)用使用了一個著名的NPM庫retry（它設(shè)置重試的次數(shù)和類型）和axios（用于執(zhí)行請求），快速的代碼檢查顯示重試操作配置了特定的參數(shù)。
const retry = require('retry');
function faultTolerantHttpRequest(URL, cb) {
// Initialize a retry operation with custom settings
const operation = retry.operation({
forever: true, // Retries forever
factor: 0, // Exponential backoff factor
minTimeout: 100, // Minimum timeout (in milliseconds)
maxTimeout: 10 * 100, // Maximum timeout (in milliseconds)
randomize: false, // Randomize the timeouts
});
這個配置證實了我們的發(fā)現(xiàn)——重試被顯式地設(shè)置為“forever”，指數(shù)回退因子被設(shè)置為0，這意味著沒有指數(shù)計時。為了解決這個問題，我們刪除了 “forever”設(shè)置，為重試的最大可能次數(shù)設(shè)置了嚴(yán)格的限制，實現(xiàn)了指數(shù)回退策略并調(diào)整了超時值。
const operation = retry.operation({
retries: 5, // Limits the number of retries to 5
factor: 2, // Sets an exponential timing that adds two additional times after each retry
minTimeout: 1000
maxTimeout: 60 * 1000
randomize: false
});
有了這些更改，F(xiàn)iddler中重試的請求現(xiàn)在顯示如下：
捕獲的流量顯示，我們的應(yīng)用程序只進(jìn)行了五次重試，并在第六次嘗試時接受并結(jié)束所有請求。Overview選項卡顯示了因子屬性的變化，表明指數(shù)后退策略是可操作的，并保護(hù)我們免受潛在的攻擊。
這個演示演示了如何使用Fiddler的功能，如Overview選項卡，在幾秒鐘內(nèi)診斷您的web應(yīng)用程序，而無需處理復(fù)雜的應(yīng)用程序或代碼庫。類似的方法可以應(yīng)用于測試刷新令牌、檢查無效或即將過期的API證書、創(chuàng)建規(guī)則來模擬意外的客戶端行為等。
Fiddler是Web調(diào)試的優(yōu)秀工具
Telerik Fiddler Everywhere是一個多功能的工具，具有擴(kuò)展的功能和良好的測試能力。無論您是想調(diào)試錯誤，測試回退機(jī)制，嘗試新的用戶界面還是檢查您的web應(yīng)用程序和后端服務(wù)器承受意外情況的能力，F(xiàn)iddler都提供了所有正確的工具。
標(biāo)簽：
本站文章除注明轉(zhuǎn)載外，均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載，但請務(wù)必注明出處、不得修改原文相關(guān)鏈接，如果存在內(nèi)容上的異議請郵件反饋至chenjj@fc6vip.cn
文章轉(zhuǎn)載自：慧都網(wǎng)
金喜正規(guī)買球 
18次
相關(guān)產(chǎn)品
正式授權(quán)
最新文章 
金喜正規(guī)買球相關(guān)的文章 
微信
在線咨詢
渝公網(wǎng)安備
50010702500608號
客服熱線