已经迁到自己的博客,有兴趣的读者请移步到(http://jhonge.net),谢谢各位支持。

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("没有权限", "您没有权限使用此功能,请与管理员联系!");
                }
            }
        }
    }
CheckLoginAndPermission

咋眼一看,一个验证账户登录与权限的方法,如果不满足则自动的跳转到各自的页面,没有什么特别的,也没有什么问题。但是,程序的异常就是出现在这里,因此我们需要把他找出来。

各位读者第一时间想到的可能是马上按“F5”或者“附加到进程”,依赖Visual Studio 这个强大的IDE来定位哪一步出了问题。但是,别忘了,我们的程序在Windows下是没有问题的,并且当前的操作系统也不是Windows,因此Visual Studio的功能我们是无法使用的。或许,有些读者还知道有“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("没有权限", "您没有权限使用此功能,请与管理员联系!");
                }
            }
        }
    }
谎言的CheckLoginAndPermission

编译发布后再刷新页面

我们得到了这个运行时异常,图明显的跟之前的不同,那就证明,刚才的异常在此“谎言”的下方。

我们不断的把我们的“谎言”(手动添加的运行时错误)往下挪,直到它把真正的“谎言”(原本的运行时错误)引出。

通过这种方法的迭代,我们大概定位到这里:

再结合它报给我们的错误“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;
        }
GetUser

CurrentId实际上还是一个userid,通过比较两个userid的值来获得user实例。还在想为什么没有得到null吗?这里是一个陷阱,我们根本就没有登陆,所以根本就没有CurrentUserId(或者说userid的值为null),因此,GetUser方法的输出东西应该也是为null。

难道小泥鳅没有对输出为null的情况作出处理吗?答案是否定的,小泥鳅中已经有判断,不然在Windows中就已经报错了,如果用户没有登陆(没有登陆就必定没有CurrentUserId了),页面就跳转到“login.aspx”页面(登陆页面)。

逻辑上当然是这样的,但是现实却并非这样,页面没有发生跳转,或者更确切的说,程序没有到达Redirect方法之后进行重定向并终止“CurrentUserId”方法中接下来的代码。看清楚幕后的“元凶”之后,想要对付它也变得简单起来,我们只需手动的让它终止运行方法内接下来的代码就可以了。

在Redirect下方加上Return(方法内所有的Redirect都加上):

 然后再次编译发布,我们就可以看到我们的登陆页面了。

 

 

2、如果遇到大量大小写问题怎么办?

我们进入后台管理页面之后,尝试添加一篇文章:

为了添加图片,我们需要点击“插入图片/文件”:

然后就……,上面说“'UserControls/upfilemanager.ascx”不存在。

典型的大小写问题,"UserControls"文件夹的大小写。解决办法很简单,把文件夹名按照大小写改好就ok。

正如我上回合中说的,小泥鳅的大小写还是比较严格的,基本上都是大小写敏感,但是,如果我们现在面对的不是小泥鳅,而是一个比较麻烦项目,里面充斥着大量的大小写问题,我们再对此进行地毯式的搜索并修正就显得可行性极低了(还不如推倒重写呢)。

面对这种情况,我们也是有“作弊码”可以行的,我们可以通过修改jws的脚本文件,让Mono对文件目录不区分大小写(注意,是文件目录,SQL语句还是区分的,因为解析SQL语句是数据库的事情,而不是Mono的事情)。

我们只需打开“jws”文件,并把Mono的IOMAP设置为all即可(jws中只需删掉“#”号)。

重启一下Jexus,再尝试添加:

ok,我们又搞定了一个问题。

 

3、requestValidationMode?

也不记得从什么时候开始,大概是.NET FrameWork 4.0 吧,我们使用富文本编辑器的时候,提交时会出现“Form表单有危险……”之类的提示,.NET也自动的帮我们验证从页面中Post回来的报文,有尖括号之类的敏感字串会自动的被.NET拒绝接收,解决的办法也很容易,网上是大把大把的,基本上就是把验证的模式从“4.0”(或更高)改为“2.0”就ok了。

但是,在我们这里,小泥鳅是基于.NET 2.0哦,所以应该就不会出现上述这种情况吧?!我们先试着添加一点东西:

然后再点击提交:

片刻的广告之后,我们只能说“嘿嘿~~”了,Mono把小泥鳅用ASP.NET 4.0 来运行了,既然它是使用.NET FrameWork 4.0 的模式来运行,那么我们也只需使用相应的解决办法即可。

我在“web.config”中的“httpruntime”节点中加上“requestValidationMode”(在这里,我直接就用VI加了,无需重新编译发布):

 然后我们重新添加文章并保存,就可以在首页中找到了我们的文章了:

 

4、同一个房顶,却是不同的房间

整好了小泥鳅在Linux.NET中的运行异常之后,我们还需要增加一个对Sqlite数据库的支持,虽然平时经常听到这一款的数据库,但是却从来都没有真正的接触过,直到开始增加此扩展的时候还是第一次(初体验?!),多亏了通用性高的SQL语句和ADO.NET,使我在仅仅知道它有五种数据类型并从Nuget哪里获得驱动的情况下就做好了对Sqlite的扩展(于是悲剧来了)。

在Windows中测试通过之后,我们迫不及待的往Linux中发布,然后就:

 

在Linux.NET中,如果遇到DLL明明就在bin目录中,但是程序却报找不到或者无法加载之类的,一般要么就是DLL真的找不到(文件大小写问题)、还有其他依赖的DLL没有成功加载或者是直接不兼容造成的。排除了大小写问题之后,我们找找Mono中有没有带有对Sqlite作驱动的dll。

可以发现,Mono中已经自带了Sqlite的驱动,并且与在MS.NET中是处于两个不同的命名空间。此外,这里还有一个图片需要让读者们看看的:

不仅命名空间不同,大小写也是有点点差别,所以,千言万语都不说了,改吧~~!


至此,小泥鳅的改造基本上完成了,需要代码的读者可以在GitHub中找到(地址在上集中有说),能力有限,如果写得有不对的欢迎各位读者留言,有建议或者意见的也欢迎留言,我们下回见~~!

PS:今年是“码”年,在这里小蝶惊鸿给各位读者拜年,祝各位读者新年快乐,恭喜发财。

posted @ 2014-02-01 00:29 小蝶惊鸿 阅读(...) 评论(...) 编辑 收藏