几个关于登陆验证的疑问
来源：8-11 ThreadLocal,LoginFilter实现登录请求的拦截
Echo鑫
2017-12-10
老师，回头来看视频，关于实现拦截功能和登陆这块有几个疑问：
一个请求过来后，先通过拦截器prehandler方法，再通过过滤器，在过滤器中先获取Session中的用户信息，然后开启一个线程，把信息存放到ThreadLocal里，再进入业务代码，如果业务代码需要用到该用户信息，直接去ThreadLoacl里取，请求完成后，再在拦截器posthandler和after两个方法中，把ThreadLocal进行清空。这样的话，是不是就相当于每次请求用户信息还是得从session中取，只不过是加入了threadlocal进行一层中间件缓存，增强了隔离性，我这么理解对吗？
为什么不把登陆这块的过滤功能，直接放到Http拦截器的Predhandler方法里实现，换句话说，在权限验证和登陆验证这块，为什么不采用拦截器而是过滤器？这两者之间的使用择取有什么规则吗？
为什么不使用Cookie，一般Cookie的使用场景有哪些，单台Tomcat做后台管理有必要使用cookie吗？
1回答
-
你好，
第一个问题，这里的threadlocal主要是为了业务中取用户信息方便，同时摆脱掉request变成一个普通的变量，也保证了可以线程安全的访问
第二个问题，单独从实现上看，写在inteceptor上过滤是可以的。但是呢，inteceptor通常都用来做一些监听操作，filter用来写一些业务逻辑处理，实际项目中也习惯把不同的业务逻辑也在不同的filter里，挨个执行判断是否可以继续，如果要写的业务逻辑多了，inteceptor就慢慢会变得特别复杂，就会出现inteceptor和filter都有过滤请求的可能。而统一在filter里写，每次有新的过滤逻辑，新加入一个filter就可以了，不需要一直去inteceptor里改。
同时，filter在定义时就可以根据规则拦截指定的url，不需要拦截所有，比如做登录校验时只针对需要登录的ur进行校验就可以了
第三个问题，cookie也可以的，但是要封装一些操作类、设计一套安全校验逻辑，保证cookie在客户端的安全性，不会被恶意修改来以某个人的身份进行操作。课程里重点是放在权限分配和校验上，主要是基于已登录的用户进行处理的，在用户认证上课程采用session会容易很多。
012017-12-10
