先看如下 web.config 的程式碼：
<system.web>
    <compilation debug="true" targetFramework="4.0"/>
    <httpRuntime requestValidationMode="2.0" />
    <pages validateRequest="false"></pages>
</system.web>

validateRequest 這句我們知道是關閉驗證，也就是說提交帶標籤，比如 <strong>粗體</strong> 這樣的值時，ASP.NET 不會報錯。

但在 4.0 中還多了一個 requestValidationMode，這是什麼意思呢？

requestValidationMode 有兩個值：

    2.0僅對網頁啟用請求驗證。是啟用還是關閉取決於 validateRequest。
    4.0 預設值。任何 HTTP 請求都會啟用請求驗證，也就是說不光是網頁，還包括 Cookie 等。此時強制啟用，不管 validateRequest 為何值。

由於 requestValidationMode="4.0" 是強制啟用，所以我們會發現在 .NET Framework 4.0 中僅靠設定 validateRequest 是關閉不了請求驗證的，還得將 requestValidationMode 設定為 2.0。

 

ASP.NET中的請求驗證特性提供了某一等級的保護措施防止XSS攻擊，之前版本的ASP.NET的請求驗證是預設啟動的,但是他緊緊應用於ASP.NET頁面中(.aspx檔案和.aspx.cs檔案)。

而在ASP.NET4中，請求驗證預設對所有型別的請求啟動，因為它在BeginRequest被呼叫之前啟動,結果就是對所有資源的請求都要經過請求驗證，而不僅僅在.aspx檔案和他們的類檔案中,甚至包括web service和自定義的httphandler。同樣，在自定義httpmodules讀取http請求的時候，同樣要經過請求驗證。

上述原因引發的最終結果就是在ASP.NET4中會引發請求錯誤，例如檢測到有潛在危險的Request.Form值等等，為了解決這個問題，可以通過將驗證模式設定為ASP.NET之前的版本。具體步驟是在web.config中加入以下配置：

<httpRuntime requestValidationMode=”2.0″ />

設定了請求模式後，再設定

<system.web>
<pages validaterequest=”false”/>
</system.web>

 

MVC框架中，在控制方法前加入：

[ValidateInput(false)]屬性。

 

 

那麼就可以禁止請求驗證了。但是這會引發安全問題，對安全問題的討論請看這裡：點選這裡檢視

另外還有一種方法就是實現自己的請求驗證類，首先需要在web.config中指定請求驗證類型別：

<httpRuntime requestValidationType=”Globals.CustomRequestValidation”/>

然後實現自己的請求驗證類，這個類必須從RequestValidator類中繼承，具體程式碼如下：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Util;
namespace Globals
{
/// <summary>
/// Summary description for CustomRequestValidation
/// </summary>
public class CustomRequestValidation : RequestValidator
{
public CustomRequestValidation() { }
protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, outint validationFailureIndex)
{
//block script tags
var idx = value.ToLower().IndexOf(“<script”);
if (idx > -1)
{
validationFailureIndex = idx;
return false;
}
else
{
validationFailureIndex = 0;
return true;
}
}
}
}

IsValidRequestString函式返回true則驗證通過，否則驗證失敗，還會出現文章開頭所說的錯誤訊息。此請求驗證類當檢測到<script>標籤時就會出現錯誤，防止指令碼注入攻擊等等。

 ============================================

 

DW與ACCESS連線字串本地和遠端

 一、在本地“瀏覽”除錯網站時的連線方法
　
　　在 DW 或本地的 IIS 伺服器下瀏覽、除錯網站訪問資料庫時，自定義連線字串中使用資料庫的絕對路徑，操作如下：
　
　　開啟 DW，建好站點，開啟所需網頁，例如主頁檔案 index.asp，在彈出的“自定義連線字串”對話方塊中“連線名稱”欄填寫自定義的名稱（為了養成好的程式設計習慣，最好名稱前加上 conn 字首，表明這是一個數據庫的連線名稱，例如本來你想起的連線名稱為 test，加上 conn 字首後的連線名稱為 conntest）。在“連線字串”欄中填寫：
　
　　"Driver={Microsoft Access Driver (*.mdb)};DBQ=你的資料庫的絕對路徑"
　
　　把本文開始處假定的具體引數代進去就是：
　
　　"Driver={Microsoft Access Driver (*.mdb)};DBQ=F:\try\data\aaa.mdb"
　
　　一定要注意：Driver 和 (*.mdb) 之間有個空格，不要寫錯了！寫錯了不能通過“測試”，當然也連線不上資料庫。上面連線字串兩端的雙引號在輸入時可以省略，DW 會自動為你補上的。
　
　　在“Dreamweaver 應連線”項中，應選擇“使用此計算機上的驅動程式”。填寫完畢後，點選右邊的[測試]按鈕，如果操作沒有問題的話，就會彈出“成功建立連線指令碼”的資訊牌。點選[確定]完成連線的建立。
　
　　此時回到 DW 的“應用程式”面板中的[資料庫]，可以看到我們建立的資料庫連線已經生效，並能檢視資料庫的結構和相關資訊。
　
　　在資料庫的資料表圖示上單擊右鍵，選擇“檢視資料”，可以檢視到該資料表中的詳細內容。
　
　　在“檔案”面板中，我們可以看到 DW 自動生成了一個 Connections 的資料夾，其中包含了一個以我們剛才自定的連線名稱 conntest 命名的 asp 檔案，這個就是儲存連線字串的地方。之後的繫結記錄集操作因不是本文主題，故略去。
　
　　到此，與資料庫連線的網頁在本地 IIS 伺服器和 DW 下可以正常訪問資料庫進行“瀏覽”了，但不能保證你的網站上傳到遠端伺服器的空間後也能正常。
　
　　二、讓資料庫的連線同時適應本地和遠端伺服器環境
　
　　我們在連線中使用了資料庫的絕對路徑 F:\try\data\aaa.mdb，而當我們把網站上傳到遠端伺服器後，伺服器上你的資料庫的絕對路徑可能和本地路徑不一樣，相關程式就會出錯。為了避免這種情況，我們應在程式中使用相對路徑。
　
　　在 DW 下雙擊開啟連線檔案（本文中是 conntest.asp），切換到[程式碼]編輯方式，找到其中的這一行：
　
　　MM_conntest_STRING = "Driver={Microsoft Access Driver (*.mdb)};DBQ=F:\try\data\aaa.mdb"
　
　　在這一行前加一個單引號“'”把它變成註釋行，然後在下面新建一行，輸入如下程式碼：
　　　MM_conntest_STRING = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="&Server.Mappath("data/aaa.mdb")
　
　　很多人也許會奇怪，為什麼我們不在建立連線時就使用相對路徑呢？其實這是有原因的。在 DW 中的連線字串中只能使用絕對路徑，而 DW 有個特點，就是檢測連線檔案（這裡是 conntest.asp）時，會連註釋（以單引號開頭的行）一起解釋、執行，在 DW 中“瀏覽”網頁、執行資料庫的連線時，只認第一個出現的連線字串，而不管它前面是否有作為註釋標記的單引號；而在遠端 IIS 伺服器中解釋檔案時會忽略掉註釋（即繞過有註釋標記的行），執行上面我們另加的第二個連線字串。根據這個特點，我們就實現了在本地 IIS 伺服器和 DW 下除錯程式使用絕對路徑，在遠端伺服器上瀏覽時使用相對路徑定位資料庫，使得網站與資料庫的連線在網站存放地點不同的情況下能“自動”隨機應變，暢通無阻。