关于ASP.NET MVC的权限认证的一些总结
最近在学ASP.NET MVC的权限认证的一些东西，上网搜索了一阵，发现网上的方法大多数是以下几类：
一、FormsAuthentication.SetAuthCookie(admin.Name, false)或者是FormsAuthenticationTicket
感受：感觉FormsAuthentication.SetAuthCookie这种方法重在检查是否有用户登录等，需要检查权限时，要调用this.User.Identity.IsAuthenticated方法来检查是否授权等，每次要检查权限时，都要进行权限检查，这类检查对于asp页面挺适用的，但是也挺麻烦的，还要配合web.config使用，我在网上看视频讲到这一块时，就觉得挺麻烦的，然后他又讲了可以用[Authorize]特性来代替这种麻烦的写法，于是我也尝试这样做，奇怪的是我直接加[Authorize]属性的时候，就算我登录了，它也是直接给我过滤掉了，并且是回到了Account/Login.aspx页面，这是我开始最不能理解的地方，因为我在web.config文件中配置了出错应该回到Home/Index.aspx页面啊，后来我想起MVC5中微软给带的自己的一套登录页面，并且在App_Start.cs文件夹Startup.Auth.cs文件中就将 LoginPath = new PathString("/Account/Login")给规定了，于是我将其改为自己的页面LoginPath = new PathString("/Home/Index")，虽然验证还是不同过，但是已经可以跳转回我自己的页面了，我就想是不是这个Startup.Auth.cs的设置比web.config文件中的设置高呢？我故意将web.config中验证权限不通过时地址与Startup.Auth.cs文件中设置的跳转地址不一致，但是运行我发现当权限不通过时，程序执行的依然是Startup.Auth.cs文件中的配置，我仔细查看了一下web.config文件，发现
<system.webServer>
<modules>
<remove name="FormsAuthentication" />
<remove name="ApplicationInsightsWebTracking" />
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" preCondition="managedHandler" />
</modules>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
有这么一句，这意思是将配置文件中的Form验证给删除了吗？我将词句删除，然后重新尝试，发现程序执行了web.config文件配置的跳转信息。
验证不通过时跳转问题解决了，那么我直接放上去权限认证[authorize]属性运行程序，发现我明明已经登陆了，可执行该方法时，还是给我跳转回了登录页面，我又仔细看了一下这个[authorize]属性，发现它也是检查cookie信息的，想要让它有值必须得在验证前，使用FormsAuthentication.SetAuthCookie(admin.Name, false)或者是FormsAuthenticationTicket对cookie进行设置保存才行，然后看视频源代码中做到这一步已经可以正常运行了，我的还得在web.config中添加
<system.web>
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" timeout="1"/>
</authentication>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
至于为什么，我以后再研究研究。
网上说FormsAuthenticationTicket可以对角色权限进行验证，我看了几篇帖子，写的都比较详细，抽机会得好好用用。
http://www.cnblogs.com/zhwl/archive/2011/02/23/1961924.html
http://www.cnblogs.com/colder/p/4544031.html
二、是重写继承于类AuthorizeAttribute的OnAuthorization和AuthorizeCore方法
三、重写AuthorizeCore和其对应的HandleUnauthorizedRequest方法的
感受：之前感觉直接在OnAuthorization中验证权限也可以啊，为什么非要在AuthorizeCore验证权限呢，在研究了一番之后感觉两者还是有分工的，执行OnAuthorization方法时，执行base.OnAuthorization(filterContext)这一句时，会调用AuthorizeCore，所以大概明白了，AuthorizeCore就是用来验证角色权限的，而OnAuthorization就是来处理权限验证逻辑的，比如通过验证怎么样， 不通过验证怎么样等等。但是又有一种说法是HandleUnauthorizedRequest方法才是处理OnAuthorizeCore中权限不通过的处理方法的啊，那么究竟是怎么样的呢，容我仔细研究一下再来！
http://www.cnblogs.com/wangjq/archive/2011/03/08/1977092.html
http://www.cnblogs.com/jyan/archive/2012/07/24/2606646.html：该文中写的好像很明确OnAuthorization方法是从数据库或者xml中获取用户角色信息的，然后交由AuthorizeCore进行角色权限判断，然后根据判断结果返回一个HttpUnauthorizedResult对象，然后由HandleUnauthorizedRequest方法去处理未通过认证的用户的跳转路由。
http://www.cnblogs.com/yushuo/p/4538031.html
四、重写OnActionExecuting
OnActionExecuting方法继承自ActionFilterAttribute，但ActionFilterAttribute和AuthorizeAttribute都继承自FilterAttribute。
如果用OnActionExecuting也写一个属性与AuthorizeAttribute重写的属性用在同一个action上，经过验证是AuthorizeAttribute先起作用，如果AuthorizeAttribute，AuthorizeCore，HandleUnauthorizedRequest都没有处理的话，OnActionExecuting重写的方法就起作用了。
后记：关于第二种和第三种方法，搞得也是迷迷糊糊，还有几种方法的参数各种上下文对象，AuthorizationContext，HttpContextBase，ActionExecutingContext让我看的一脸懵逼，找时间还得研究研究，毕竟纸上得来终觉浅，须知此事要躬行啊！
