在ASP.NET当中,如果遇到用户已经登录,但是获取不到用户名(User.Identity.Name=""
),并且User.Identity.IsAuthenticated
的值依然为false
的情况,或者调用FormsAuthentication.SignOut()
方法注销用户账户,但是获取User.Identity.IsAuthenticated
后得到的值还是为true
。只要是遇到类似这两种无法实时获取用户身份信息的情况,就要注意当前用户的身份信息是否还没有进行创建/更新,是否没有进行重定向重新触发身份验证事件?这个问题主要和ASP.NET的身份验证机制有关!
在鼓捣一个项目的时候引发了HttpAntiForgeryException (0x80004005)异常,并提示:提供的防伪标记适用于用户“admin”,但当前用户为“”。从异常信息可以很直观看出问题产生的原因所在,主要在于身份认证和授权的状态发生改变,导致防伪令牌没有更新正确的身份信息从而验证失败。
上篇文章主要是从源码入手,解析并了解AntiForgeryToken
防伪标记的生成过程。这篇文章还是会结合源码,对ValidateAntiForgeryToken
属性的验证逻辑进行分析和说明,搞懂防伪标记的验证逻辑到底是怎么一回事,也能对ASP.NET MVCV的防伪标记有着更加深入的理解。
之前开发某个ASP.NET MVC项目的时候遇到了一个和防伪标记有关的问题,结果不知不觉深入到了源码的研究。本篇主要从AntiForgeryToken
(防伪标记/令牌)的生成过程入手,搭配mono的ASP.NET源码进行分析。
其实MvcHtmlString
这个类在ASP.NET MVC中是经常出现的,只要是使用HtmlHelper
帮助器生成的HTML控件,最终返回的值都是一个MvcHtmlString
对象。例如在使用Razor模板引擎的视图中,使用诸如@Html.TextBox
、@Html.CheckBox
、@Html.Editor
、@Html.Hidden
这类方法生成的input元素,只要在VS中按F12查看方法定义都可以看到返回值类型是MvcHtmlString
。
在ASP.NET MVC中是可以通过代码手动控制防伪标识(AntiForgeryToken)的更新。另外在介绍更新令牌的具体方法前,会先说明如何获取防伪令牌,毕竟要以此为基础才能实现。
如果某天发现网站的URL突然多了个小尾巴:AspxAutoDetectCookieSupport=1,那么肯定是设置了配置文件中sessionState元素的cookieless特性,并且将它的值为"AutoDetect"。
去年很早的时候写过几篇关于ASP.NET MVC异常处理的方法和总结,后面遇到有网友留言,感觉在看过文章后虽然知道了多种全局异常处理的方案,但是在如何选择上出现了困惑,这里我就根据自己的一些项目经验来分析和说明下。
当初建立这个博客的时候,是考虑做全站静态化的,为了朝这个目标发展我为博客开发了许多静态化功能。但时至今日,我却取消了博客大部分的静态化操作,本文就当是一个总结,记录本博客在静态化方面遇到的一些问题和经验。
这几天稍微研究了下ASP.NET MVC的全局异常处理以及捕获,相比ASP.NET Web Form,ASP.NET MVC的处理方式有所不同,以往是通过注册Global.asax文件中的Application_Error事件进行全局异常捕获,现在MVC可以使用强大的过滤器进行自定义错误的处理。本文作为学习笔记,将ASP.NET MVC中,我已知的几种全局异常捕获及处理的思路进行整理和对比分析。
ASP.NET MVC 默认提供了一个异常过滤器HandleError特性,使用该特性可以极为方便的捕捉并处理控制器和操作抛出的异常,也可以将此特性注册为全局异常过滤器从而捕捉项目中所有Action方法抛出的异常。如果想要简单的消灭错误黄页(错误详细页),使用HandlerErrorAttribute是不错的选择!
FilterConfig类是ASP.NET MVC 5和4中新增加的配置类,刚刚使用新版框架的朋友可能会产生疑问,这个FilterConfig是干什么的?有什么用?简单来说,它就是一个专门用来注册全局过滤器的静态类。