在前面的文章中为大家介绍了 Shrio 的基础概念。可能比較笼统。没有深入到开发过程的一些问题。如今集中在本帖中归纳一下有关问题。
FormAuthenticationFilter 表单过滤器
表单过滤器的问题，是本人在实现验证码组件时候遇到的，亦以前一度让我“抓狂”。虽然有便捷的方法实现验证码，比如在控制器中就能够推断验证码逻辑了，可是那有违 Shiro 结构体系的思想；本人也想籍此了解 Shiro 扩展实现方法，——假设都走捷径。那么学习的目的就达不到了。于是，本人就把遇到问题逐一罗列出来。
首先啰嗦下。为什么不写在控制器？
Shiro 提供丰富的过滤器，FormAuthenticationFilter 就是一种过滤器。既然使用了安全框架。那么我们就应该依照框架的方法去编码。我们知道，经典 Web MVC 中，过滤器是优于 Servlet 运行的，也是一般用作安全检測、权限校验之用的。
所以 Shiro 组件基于过滤器的思想就“名正言顺”了（所以说 Filter 能做的，Shiro 也能做，Filter 做不了的或者不适合做的， Shiro 过滤器也不会僭越）。实际从作用功效上，过滤器与 Servlet 彼此替代可能性蛮大的。也就是说，Servlet 的逻辑用在 Filter 之上亦能够，效果看起来不会差太多——反之亦然。只是，我们还是要回想下它们之间的差别：首先是前面说的。Filter 优于 Servlet 运行，Filter 拦截了，Servlet 也不会运行；其次，编码风格上 Filter 基于责任链式模式，Servlet 却不是；最后就是 Filter 不像 Servlet，它不能产生一个请求或者响应。Filter 通常仅仅是返回 true/false。当然，它们是如此地相像。以至于把 Filter 觉得是 Servlet 变种的一种亦未尝不可。
所以，我们会看到 Shiro 的一些案例中，既有 Filter。又有 Controller。比如以下我们绑定会员登录的 url 到 FormAuthenticationFilter，然后又声明有控制器。
CaptchaFormAuthenticationFilter 是扩展 FormAuthenticationFilter 的验证码过滤器。
/service/user/access/login = authcaptcha 这句就是绑定了验证码过滤器。
这样如此。应该是不用编码就能够调用 CaptchaFormAuthenticationFilter 了。
这个完整的请求还有 Controller 部分：
@RequestMapping(value = "/login", method = RequestMethod.POST)
public void loginAction(User user, HttpServletRequest request, HttpServletResponse response) {
String exceptionClassName = (String) request.getAttribute("shiroLoginFailure");
Throwable exObj = (Throwable) request.getAttribute("exObj");
String error = null;
LOGGER.info("client " + user.getName() + "登录..." + exceptionClassName);
if (UnknownAccountException.class.getName().equals(exceptionClassName)) {
error = "未知用户错误";
} else if (IncorrectCredentialsException.class.getName().equals(exceptionClassName)) {
error = "用户名/password错误";
} else if (IncorrectCaptchaException.class.getName().equals(exceptionClassName)) {
error = "验证码错误";
} else if (exObj != null && exObj.getClass().getName().equals(IllegalArgumentException.class.getName())) {
error = exObj.getMessage(); // 缺少某个字段
} else if (exceptionClassName != null) {
error = "其它错误：" + exceptionClassName;
}
// 输出 JSON
ResponseHelper rsp = new ResponseHelper(response);
boolean isOk = error == null;
String msg = error == null ? "登录成功！" : error + "详细原因：" + (exObj != null ? exObj.getMessage() : "N/A");
rsp.outputAction(isOk, msg);
}可见，这个控制器好像“打杂”的，作用比較简单，像是一些善后的工作。
可是，为什么过滤器运行不起来？
遗憾的是，声明过滤器之后却运行不起来，不能正确跳转。
訪问这个 url。即使输入合法也跳到“登录”页面（也就是未登录的页面）。然后重复搜索相关资料和样例，得知表单是 AccessControlFilter 的子类，假设訪问了一定回 isAccessAllowed() 方法，试了下果然能够，表示是否同意訪问。然后我下意识地调用验证码的 executeLogin() 方法，也就是封装的 getSubject().login(token); 的方法。难道是这样调用控制器的吗？我覺得我这样的方法有点“简单粗暴”。框架不至于推荐这么做——后来的測试也证明此法不可行，报了一个两次 redirect 重定向的异常。——这肯定是我的方法不正确！
百搜不得其解下。我十分灰心。甚至想放弃，后来我想到把 Shiro 源代码和文档附加到 jar 中，看看里面的源代码和凝视。果然人家就说明须要 POST 请求。并且要指定登陆 URL（这个是 Action 接受请求的地址。假设不设置默认是 /login.jsp，这就是导致非常多人不能成功调用过滤器的原因！）才干调用过滤器，有条件限制的，并且根本不须要运行 isAccessAllowed() 方法。
后来又发现个小插曲，——偶尔登录成功后，在尝试登录是不会运行过滤器。因此 Shiro 定义是“一次运行的”。详细原理我就没有深究了仅仅是知道有这么一个机制。測试相应的方法也非常easy。把浏览器缓存清掉，令其 session 去掉。
另外表单 POST 字段的映射，FormAuthenticationFilter 也考虑到了，參见配置中的 <property name="usernameParam" value="name" />：
<bean id="captchaFormAuthenticationFilter" class="com.ajaxjs.framework.user.captcha.CaptchaFormAuthenticationFilter"> <property name="usernameParam" value="name" /> <property name="loginUrl" value="/service/user/access/login" /> </bean>
这里的是 Spring 的配置方法。
小结一下 Shiro 认证
Shiro 就是这样，提供现成的组件方便我们调用，我们也能够从中了解其机制，——反正都是开源的。
过滤器是认证的第一板斧，是创建 token 的那一步。有了 token 才干运行 AuthenticatingRealm.doGetAuthenticationInfo(AuthenticationToken authcToken)，最后到控制器。网上有些样例把创建 token 那一步写在控制器中。虽然做法有点简单粗暴，但道理还是一样的。