环境搭建好后，之后的练习进入了一个十分痛苦的阶段！！ 但是与此同时，收获也是比较可观的。 老师通过详细的视频讲解，完成了表单登陆，包括账号密码和验证码登陆，手机验证码登陆，第三方登陆。 每一个部分都进行了开发步骤说明，思路引领，以及代码重构！！！
通过以往的学习经验，我知道唯有将学习的内容以笔记的形式固定下来，才有可能学习到所学习内容的50%左右。 否则无论学习当时是如何的自信，认为自己掌握的如何如何尔尔，当经过时间的淘洗，剩下的唯有一句话：“我曾经学过！”。 这对正在学习阶段的那个自己是极为不负责的！！ 所以无论怎样我要写笔记！！
但是这么多的内容，企图用一篇文章写下来是不现实的。 中间还有那么多的步骤，以及那些可贵的思想！！ 但是鱼和熊掌不可兼得。 废话就这么多。
重要的依赖文件：
<dependency><groupId>org.springframework.social</groupId><artifactId>spring-social-security</artifactId></dependency><dependency><groupId>org.springframework.social</groupId><artifactId>spring-social-config</artifactId></dependency> <dependency><groupId>commons-lang</groupId><artifactId>commons-lang</artifactId></dependency>
代码结构：
理解：springsecurity的核心是：过滤器。 所有的操作均以过滤链为核心展开！！
表单登陆要素：
1.过滤链上进行注册：
如何注册？？？：
如何开放注册页面？？？：
2.自定义凭证逻辑。
表单+图形验证码登陆要素：
1.定义图形验证码的处理逻辑。 它的原理是，前端请求进来，生成一个验证码并写入session（该session针对用户的），将验证码写入到图片流中，进行混淆。 之后写入到请求的输出流中。 封装过后的代码如下：
对整个逻辑进行了分层抽象的实现。：
第一层：
第二层：
第三层：
到此为止，关于图形验证码的生成过程及相关的逻辑就完成了！！ 但是这不是核心。。 我们知道所有的东西都要围绕过滤链来进行。 所以重心应该是过滤器逻辑！！
2.进行过滤器的核心配置：
它包含两个内容： 拦截的路径，以及过滤处理。
3.将过滤器放到过滤链进行注册：
这样便完成了图片验证码与账号密码的登陆逻辑。
手机验证码登陆要素：
手机验证码实际上的处理逻辑与图片验证码的处理逻辑类似，只是图片验证码是通过写入响应，以流的形式直接作用于前端。 手机验证码是通过短信服务商发送给用户的手机。 但是它们的验证原理仍然是一样的。 第一步生成验证码并写入session， 第二步，发送给终端（浏览器，或者手机）。 第三部，验证！。
老师已经进行了极为完美的抽象与封装，所以我们可以很方便的实现调用。 它的发送实现已经在上文中粘贴。
然而它的本质不同在于： 它的信用凭证！！！
因为它不是与表单登陆使用同一个信用凭证，所以我们要单独处理 过滤器的逻辑，以及信用提供商的逻辑。 但是，整个过程任然是以过滤器为核心，并由此衍生的代码逻辑而已！！
1.定义凭证：
2.定义凭证提供商：
2.短信验证码的过滤器：
过滤的核心流程通过抽象类进行封装。 我们只需覆写：
4.将短信验证码的验证逻辑注册到过滤链中：
注意，这个过滤器与注册登陆过滤器二者无限后顺序。 但是二者是逻辑上互斥的。 也就是说某次认证，只需要通过二者其一即可。
以上是短信验证码的相关逻辑环境。 经测试一切正常。
第三方登陆的要素：
第三方登陆主要是基于OAUTH协议。 所以与其说学习第三方登陆的实践。 倒不如说学习OAUTH协议。 但是毕竟现在自己还是能力有限，所以还是慢慢来，记录一下qq的第三方登陆的开发的过程。 当然它的核心任然是围绕过滤器展开。
1.过滤器的来源：
2.过滤器在过滤器链条的注册：
3.配置OAUTH的相关构件：
api:
serviceProvider:
需要注意，在这个途中有一个特别重要的实体：授权码。。
connectionFactory:
connecAdapter:
针对qq所定制的oauth2模板：
4.配置逻辑上的“令牌”提供者：
到此，整个第三方登陆的流程就完成了。测试一切正常！
过程还是比较多，比较的杂乱！
看了老师的视频以及自己亲自实践后，来讨论它如何以过滤器为核心展开的？？？
第一，由特定的过滤器拦截相关的地址。 对拦截到的地址进行参数判定！ 若有授权码“code"属性，认为是从第三方发来的。 用以完成接下来的获取令牌的逻辑！ 若没有，则认为是用户访问的，将之导入到相应的第三方进行认证，其目的是为了获得授权码！！ 这个转换的关键在于回调地址。
第二，api充当逻辑上的凭证，connectionFacotry充当逻辑上的凭证提供者。 唯有凭证提供者在容器中存在，整个拦截过程才会生效。 否则本次拦截无效，由其它拦截器处理。
第三，上面两步核心的配置均不是由我们直接操作完成的。 至少在spring-boot中是这样。
第四，要完成自定义的拦截地址，以及自定义的providerId配置实现：
第三方认证登陆并注册逻辑实现：
spring-social会为第三方登陆维护一张数据表。 它的相关实现：
表结构位于UsersConnectionRepository同级包下。
这就产生了认证后登陆，与直接自动登陆的逻辑需求。
1.认证后注册登陆的实现：（触发条件： 在表中没有查到信息，并且上下文中没有（connectionSignup的实现，由spring-social提供）
默认为/signup。 自定义的实现：
注意，该地址默认为一个资源视图地址。 。换言之，它必须开放！！即不能用拦截器进行拦截的地址。
为了在注册的时候完成与第三方相关信息相连接。 需要提供一个工具类：
它的使用示例：
2.认证后自动登陆的实现：（只需破环满足上一个条件的条件即可）。如：
最重要的一点完了说：
因为这个与短信验证码一样，也是独立的。 为他提供凭证支撑的userServiceDetail必须实现接口：SocialUserDetailsService
第三方绑定与解绑的实现：
由spring-social自动附带的功能。
直接看代码说话：
微信第三方登陆的实现：
qq同理可得。
与qq的一些区别：
那么微信的关键就是，这个openId如何获得呢？？且看下文：
就这样吧。 回顾的时候，发现还有记住我功能，以及 session管理的相关内容没有记录。 吃了饭再找个实践记录一下吧！
