連接字符串生成器簡介

此代碼仍然生成相同的連接字符串，但此代碼的編寫更容易一些。另外，如果在提供連接字符串關鍵字時產生了輸入錯誤，將會產生一個編譯時錯誤。如果正在Microsoft Visual Studio中編寫代碼，并且難以記住連接字符串選項，那么可以很容易地通過IntelliSense下拉菜單使用SqlConnectionStringBuilder中的可用選項。使用這些下拉菜單還可以減少輸入字符，防止出現一些輸入錯誤，在其他情況下，需要到測試代碼時才能發現這些錯誤。

3. 處理復雜的連接字符串選項值

使用連接字符串生成器的一個間接好處是：不必再記憶如何分析、轉義或分隔連接字符串中的值。假定需要提供一個包括空格的連接字符串值，是否需要在關鍵字兩側加引號呢？用大括號？一個也不用？還是用兩個？

如果以手動方式生成連接字符串，那么這些問題不存在簡單的答案。事實上，其答案取決于所使用的.NET數據提供程序。過去使用過ODBC的開發人員可能還會記得：包含空間的ODBC驅動程序名稱必須用大括號分隔："Driver={SQL Server}"。利用連接字符串生成器來代替手動方式生成連接字符串，就不再為這些問題而費心。

如果正在使用連接字符串生成器，可以將邏輯交給生成器處理。例如，可能希望使用連接字符串選項以連接到服務器，并在過程中附加一個數據庫文件。希望使用的文件可能在路徑中包含空格或其他字符。開發人員不必擔心是否或如何分隔連接字符串中的文件名稱，只需要使用SqlConnectionStringBuilder類來生成連接字符串，如下所示：

SqlConnectionStringBuilder bldr = new SqlConnectionStringBuilder();

bldr.DataSource = @".\SQLExpress";

bldr.IntegratedSecurity = true;

bldr.AttachDBFilename = @"C:\My Complex Path\AttachMe.mdf";

//將生成的連接字符串輸出到控制臺窗口

Console.WriteLine("Resulting connection string: {0}", bldr.ConnectionString);

//以SqlConnection使用所生成的連接字符串

SqlConnection cn = new SqlConnection(bldr.ConnectionString);

cn.Open();

讀者可能出于某種原因而希望了解如何正確分隔連接字符串中的文件名稱，那么該代碼段生成以下連接字符串：

Data Source=.\SQLExpress;AttachDbFilename="C:\My Complex Path\AttachMe.mdf";

Integrated Security=True

4. 惡意連接字符串輸入，也稱為“連接字符串注入”

在編寫安全代碼時，最重要的規則之一就是“絕對不要盲目相信用戶輸入”。參數化查詢(這一主題將在第4章中詳細討論)非常有用，其原因有很多，但重要原因之一是它可以防止SQL注入。可以構建一個參數化查詢，并為參數指定由用戶提供的取值，而不必擔心用戶輸入是否會改變查詢的結構。在生成連接字符串時也存在類似問題。

您可能決定對用戶進行提示，使其輸入憑據——提供一個文本框以允許用戶輸入用戶名和密碼，然后利用以下代碼，基于連接字符串中的輸入來構造連接字符串。

string strConn;

strConn = @"Data Source=.\SQLExpress;Initial Catalog=Northwind;" +

              "User ID=" + txtUserID.Text + ";" +

              "Password=" + txtPassword.Text + ";"

Console.WriteLine("Resulting connection string: {0}", strConn);

乍看起來，這似乎是安全而符合邏輯的。現在假定有一位惡意用戶，他希望修改此連接字符串。圖3.1說明了一種方式，這種惡意用戶可以采用這種方式來修改要訪問哪個服務器。由于沒有更好的術語，我們將這種方法稱為“連接字符串注入”。

圖3.1   惡意用戶嘗試通過用戶輸入改變應用程序訪問的服務器

利用以上代碼段和如圖3.1所示的輸入，所得到的連接字符串如下所示：

Data Source=.\SQLExpress;Initial Catalog=Northwind;User ID=MyUserID;

Data Source=EvilServerName;Password=MyPassword;

可以看到，Data Source被指明兩次。在使用所得到的連接字符串時，會選用哪個值呢？是第一個(本地計算機)，還是第二個(“evil”服務器)？是否存在手動檢查用戶輸入的方式，以檢查諸如此類的可能的連接字符串注入？這些答案對于其他連接字符串關鍵字或其他.NET數據提供程序是否正確呢？開發人員能夠做些什么呢？

幸運的是，連接字符串生成器可以幫助開發人員處理來自惡意或惡作劇用戶的輸入。

5. 用連接字符串生成器防止連接字符串注入

利用SqlConnectionStringBuilder重新編寫前面的代碼段，得到以下代碼：