这篇文章不整虚的，直接告诉你怎么在mvc5里搞定管理员权限，解决你登录后发现菜单乱跳、数据看不见的头疼问题。
说实话，写到现在第六篇，我都有点想弃坑了。前面的登录注册还算顺风顺水，一到权限控制这环节，头就大。很多新手朋友问我，为啥我明明登录成功了，点后台菜单却是一片空白，或者干脆404？其实不是代码写错了，是你没搞懂mvc5里那个叫[Authorize]的玩意儿。
咱们先说个惨痛教训。上周我给一个客户做后台，为了省事，直接把控制器里的所有Action都加了[Authorize]，心想这样最安全。结果测试的时候，发现连登录页面都被拦截了，直接死循环跳转。当时我对着屏幕发呆，心里那个火啊，真想砸键盘。后来冷静下来翻文档，才发现原来[Authorize]默认是拦截所有请求的，包括登录页。这就像是你给自家大门装了把锁，结果钥匙还锁在门里面，进不去也出不来。
所以，在mvc5网站开发之六 管理员 这个环节，第一步就是要学会“放行”。在Account控制器里，给Login和Register方法加上[AllowAnonymous]特性。这一步看似简单，却是很多初学者容易忽略的坑。你以为登录是特权，其实登录是基础，没登录谁给你发令牌？
接下来就是重头戏了。很多兄弟喜欢把权限判断写在每个Action里，比如if (User.Identity.Name == "admin")。这种写法不仅丑，而且维护起来简直是灾难。改一个角色，你得翻遍整个项目。咱们得用点高级点的玩法，自定义AuthorizeAttribute。
我一般是这样做的：新建一个类，继承AuthorizeAttribute，重写OnAuthorization方法。在这里面，你可以去数据库查这个用户属于哪个角色，有没有权限访问当前控制器。虽然代码多了几行，但逻辑清晰多了。这就好比你去高档小区，保安不只看身份证，还要查你是不是业主，有没有门禁卡。
这里有个细节要注意，mvc5默认的身份验证是基于Cookie的。当你登录成功后，系统会自动生成一个Ticket，塞进Cookie里。下次请求的时候，框架会自动解析这个Cookie，填充到User对象里。所以，你在任何地方都能通过User.Identity.Name拿到用户名。这点很爽，但也容易让人产生依赖，忘了底层原理。
我见过太多人，为了追求所谓的“高性能”，非要自己手写Session验证，结果搞得代码乱七八糟，bug不断。其实mvc5内置的东西已经足够好用了，除非你有极特殊的理由，否则别去造轮子。记住，能用框架提供的，就别自己写。
再说说视图层面的权限控制。有时候，不同角色的管理员看到的菜单不一样。比如超级管理员能看到“系统设置”，普通编辑只能看到“内容发布”。这时候，你可以在Layout视图里加判断。比如@if (User.IsInRole("Admin")) { ... }。这种方式简单粗暴，但有效。当然，如果菜单特别复杂，建议用动态菜单生成，把菜单配置存数据库，这样改菜单不用改代码。
最后，我想吐槽一下那些教人用全局过滤器拦截所有请求的教程。全局过滤器确实方便，但缺乏灵活性。比如，有些公开接口不需要权限，有些后台接口需要。用全局过滤器，你得在Action里一个个加[AllowAnonymous]，反而更麻烦。所以，我推荐用特性标注，哪里需要权限，就在哪里加，一目了然。
写到这里，其实mvc5网站开发之六 管理员 的核心就两点：一是身份验证要放行登录页，二是权限控制要灵活。别被那些复杂的理论吓到，代码跑起来才是硬道理。
如果你还在为权限问题头疼，不妨回头看看你的[Authorize]加对了没有。有时候，问题就出在最基础的地方。别怕犯错，我踩过的坑比你吃过的米都多。多调试，多打印日志，你会发现，其实也没那么难。
总之，建站这条路，就是不断填坑的过程。希望这篇能帮你省下几个通宵的时间。要是还有不懂的，评论区见，虽然我不一定回，但我可能会偷偷看。
本文关键词：mvc5网站开发之六 管理员
