盤查以參數為基礎的導覽網站
掃描導覽為以參數為基礎的網站時所需配置變更的說明。
依預設，AppScan 的「冗餘路徑限制」為 5 （要求可傳送至相同 URL 的次數上限，請參閱「探索選項」視圖）。在一般網站中，這可防止不必要地重複進行測試。不過，當網站導覽是以參數為基礎時，這個低限將有效防止 AppScan® 徹底掃描網站，而且使用「一般掃描」範本執行的掃描，將幾乎無法發現及測試任何網站。
增加「冗餘路徑限制」，或是將它完全停用，並無法單獨解決此問題。事實上，它可能使 AppScan 陷入無限迴圈，或至少會建立含有過多測試的掃描，而使 AppScan 在執行時發生記憶體不足。這個問題有兩個原因：
- 在「探索」階段期間，對要求進行雜湊動作時，AppScan 會將找到的所有參數和 Cookie 併入該要求中。若取消冗餘路徑限制，便會將這些值的所有組合納入考量。
舉例來說，假設網站區段的每一個頁面，都包含某個 Script 的數百個鏈結，這個 Script 會從資料庫中擷取可銷售項目的其他資訊。這些鏈結包含一個名為
item_id的參數，它在產生新頁面中並不重要，只用來擷取項目的其他資訊。AppScan 最後會要求此項目資訊頁面的數千個實例，除非能夠將item_id從雜湊中排除。 - 在「測試」階段中，問題變得更加嚴重。假設要求包含
par1和par2兩個參數，且 AppScan 發現含有這些參數的四個鏈結：http: // site.com/content.aspx?par1=a&par2=c http: // site.com/content.aspx?par1=a&par2=d http: // site.com/content.aspx?par1=b&par2=c http: // site.com/content.aspx?par1=b&par2=d如果適用於每一個參數的測試有 400 個，AppScan 共會傳送 1600 個測試（當
par2=c及par2=d時，par1上 800 個，當par1=a及par1=b時，par2上 800 個）！因此，除了從「探索」雜湊中排除這些參數之外，還必須告知 AppScan 每個參數只測試一次：par1上 400 個測試，par2上 400 個測試。
因此，衍生自上述以參數為基礎的導覽方式掃描網站的原則如下：
- 探索階段：忽略導覽參數以外所有參數的值。
- 測試階段：當參數值變更時，請勿建立新測試，但導覽參數除外。
另請參閱：