linux.NET實戰手記—自己動手改泥鰍（下）

在上回合中，我們不痛不癢的把小泥鰍的數據庫從只能供在Windows下運行的access數據庫改為支持跨平臺的MySQL數據庫，毫無營養的修改，本回合中，我們將把我們修改后得來的項目往Linux中部署、調試，讓它適應Linux.NET的運行環境。

在本回合中，我們將討論研究：

　　1、由一個謊言引出另一個謊言

　　2、遭遇大量大小寫問題怎么辦

　　3、requestValidationMode？

　　4、同一個房頂，卻是不同的房間

1、由一個謊言引出另外一個謊言

當我們把小泥鰍部署上Linux之后，首頁一般是沒有問題的（首頁能夠打開，并且能夠閱讀里面的文章），但是當我們點擊后臺管理時，頁面就開始變得奇怪起來，它沒有像我們想象那樣，出現一個填寫用戶名密碼的界面，而是如下圖所示的“問題”頁面：

通過閱讀堆棧跟蹤，我們大概知道程序用一個“AdminPage.CheckLoginAndPermission”的地方進去之后就開始報錯，為此，我們需要先確定這個叫做“CheckLoginAndPermission”的東西到底是Mono或其他三方類庫里的東西還是我們代碼里的。

判斷的方法也挺簡單，對著Visual Studio 按“Ctrl+Shirt+F”，沒錯，就是查找功能，只要我們能夠在項目中找到相關的代碼，那就證明改方法是我們項目中自己的東西。

通過搜索，結果還真讓我們找到癥結的所在，于是，我們就順藤摸瓜的進入到該方法里面，該方法的代碼如下：

/// <summary>    /// 檢查登錄和權限    /// </summary>    PRotected void CheckLoginAndPermission()    {        if (!PageUtils.IsLogin)        {            HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl));        }        UserInfo user = UserManager.GetUser(PageUtils.CurrentUserId);        if (user == null)       //刪除已登陸用戶時有效        {            PageUtils.RemoveUserCookie();            HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl));        }        if (StringHelper.Getmd5(user.UserId + HttpContext.Current.Server.UrlEncode(user.UserName) + user.PassWord) != PageUtils.CurrentKey)        {            PageUtils.RemoveUserCookie();            HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl));        }        if (PageUtils.CurrentUser.Status == 0)        {            ResponseError("您的用戶名已停用", "您的用戶名已停用,請與管理員聯系!");        }        string[] plist = new string[] { "themelist.aspx", "themeedit.aspx", "linklist.aspx", "userlist.aspx", "setting.aspx" ,"categorylist.aspx","taglist.aspx","commentlist.aspx"};        if (PageUtils.CurrentUser.Type == (int)UserType.Author)        {            string pageName = System.IO.Path.GetFileName(HttpContext.Current.Request.Url.ToString()).ToLower();            foreach (string p in plist)            {                if (pageName == p)                {                    ResponseError("沒有權限", "您沒有權限使用此功能,請與管理員聯系!");                }            }        }    }

咋眼一看，一個驗證賬戶登錄與權限的方法，如果不滿足則自動的跳轉到各自的頁面，沒有什么特別的，也沒有什么問題。但是，程序的異常就是出現在這里，因此我們需要把他找出來。

各位讀者第一時間想到的可能是馬上按“F5”或者“附加到進程”，依賴Visual Studio 這個強大的IDE來定位哪一步出了問題。但是，別忘了，我們的程序在Windows下是沒有問題的，并且當前的操作系統也不是Windows，因此Visual Studio的功能我們是無法使用的?；蛟S，有些讀者還知道有“Mono Develop”這個IDE，該IDE可以在Linux中使用，可惜，我們的Linux中并沒有安裝這個工具，甚至連Xwindows也沒有安裝，Linux的運行級別也只是“init-3”級別，要弄“Mono Develop”太麻煩了，我們需要一些有趣的手段來定位我們的問題。

先回想一下，既然成功發布，那就證明項目是成功的編譯，而在運行時出現卻報錯，則表示，這個是一個運行時異常。運行時異常，其實我們也會經常遇到，譬如讓程序讀一個不存在的文件、數據庫連接字串寫錯之類的，這些都屬于運行時異常，只有程序運行到這一步出現錯誤的時候，程序才終止繼續運行并提示錯誤。

根據這一原理，我們可以自己定義一些“謊言”（手動的添加一些運行時錯誤），讓程序運行到此處終止并提示錯誤，通過比較程序提示的錯誤，我們就可以定位到項目中發生錯誤的哪一行代碼了，通過一個謊言來引出另外一個謊言。

譬如我在檢查是否登陸這里添加一個“謊言”。

/// <summary>    /// 檢查登錄和權限    /// </summary>    protected void CheckLoginAndPermission()    {        if (!PageUtils.IsLogin)        {            HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl));        }        UserInfo user = UserManager.GetUser(PageUtils.CurrentUserId);        //在這里添加謊言        var a = decimal.Parse("小蝶驚鴻");        if (user == null)       //刪除已登陸用戶時有效        {            PageUtils.RemoveUserCookie();            HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl));        }        if (StringHelper.GetMD5(user.UserId + HttpContext.Current.Server.UrlEncode(user.UserName) + user.Password) != PageUtils.CurrentKey)        {            PageUtils.RemoveUserCookie();            HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl));        }        if (PageUtils.CurrentUser.Status == 0)        {            ResponseError("您的用戶名已停用", "您的用戶名已停用,請與管理員聯系!");        }        string[] plist = new string[] { "themelist.aspx", "themeedit.aspx", "linklist.aspx", "userlist.aspx", "setting.aspx", "categorylist.aspx", "taglist.aspx", "commentlist.aspx" };        if (PageUtils.CurrentUser.Type == (int)UserType.Author)        {            string pageName = System.IO.Path.GetFileName(HttpContext.Current.Request.Url.ToString()).ToLower();            foreach (string p in plist)            {                if (pageName == p)                {                    ResponseError("沒有權限", "您沒有權限使用此功能,請與管理員聯系!");                }            }        }    }

編譯發布后再刷新頁面

我們得到了這個運行時異常，圖明顯的跟之前的不同，那就證明，剛才的異常在此“謊言”的下方。

我們不斷的把我們的“謊言”（手動添加的運行時錯誤）往下挪，直到它把真正的“謊言”（原本的運行時錯誤）引出。

通過這種方法的迭代，我們大概定位到這里：

再結合它報給我們的錯誤“Object reference not set to an instance of an object”（未將對象實例化），我們可以推演出，這里有東西為null。在這里，只有user為需要實例化的類（PageUtils.CurrentKey是一個static的屬性），我們可以猜或許是user為null。

為了驗證，我們可以做如下動作：

通過驗證，我們發現我們的推理是對的，就是user為null造成了此處的失敗。

但是，為什么user為空呢？或者說，難道說小泥鰍中原程序中沒有對user作出checknull的判斷嗎？我們先追述一下user的來源，user來自于本方法中：

通過傳入一個CurrentUserId，來獲得user類，而在GetUser方法中，代碼如下：

        /// <summary>        /// 獲取用戶        /// </summary>        /// <param name="userId"></param>        /// <returns></returns>        public static UserInfo GetUser(int userId)        {            foreach (UserInfo user in _users)            {                if (user.UserId == userId)                {                    return user;                }            }            return null;        }

CurrentId實際上還是一個userid，通過比較兩個userid的值來獲得user實例。還在想為什么沒有得到null嗎？這里是一個陷阱，我們根本就沒有登陸，所以根本就沒有CurrentUserId（或者說userid的值為null），因此，GetUser方法的輸出東西應該也是為null。

難道小泥鰍沒有對輸出為null的情況作出處理嗎？答案是否定的，小泥鰍中已經有判斷，不然在Windows中就已經報錯了，如果用戶沒有登陸（沒有登陸就必定沒有CurrentUserId了），頁面就跳轉到“login.aspx”頁面（登陸頁面）。

邏輯上當然是這樣的，但是現實卻并非這樣，頁面沒有發生跳轉，或者更確切的說，程序沒有到達Redirect方法之后進行重定向并終止“CurrentUserId”方法中接下來的代碼?？辞宄缓蟮?ldqu