使用JWT设计springBoot项目api接口安全服务

 springboot,springmvc 中通过   熟悉Swagger测试api接口
    Swagger是当前最好用的Restful API文档生成的开源项目
    https://blog.csdn.net/fansunion/article/details/51923720  //里面有中文文档和英文文档
    调用和可视化 RESTful 风格的 Web 服务
    A: 加載 maven springfox-swagger2  springfox-swagger-ui
    B:
    @Configuration注解，让springboot来加载该类的配置。在通过@EnableSwagger2注解来
    启用Swagger2。再通过@Bean注入Docket实体类， apiInfo()用来创建该api的基本信息，这些信息将会展现在文档页面中。
    
    https://www.jianshu.com/p/5716c1cdf7f4
    extends WebMvcConfigurerAdapter  重寫的方法
    addResourceHandlers: 此方法是用来添加静态资源映射的
    addInterceptors  此方法是用来注册拦截器的
    
    public Docket defaultApi() //swagger 基本配置比如扫描的包等等
    private ApiInfo apiInfo()  //pi文档的详细信息在文档页面展示
    
    
    
    @Api(description = "购物车接口")：修饰整个类
    @ApiOperation("获取购物车")：描述一个类的一个方法，或者说一个接口
    @ApiParam(required = true, name = "cartId", value = "cartId")：单个参数描述
    @ApiModel：用对象来接收参数 
    @ApiProperty：用对象接收参数时，描述对象的一个字段
    @ApiResponse：HTTP响应其中1个描述
    @ApiResponses：HTTP响应整体描述
    @ApiIgnore：使用该注解忽略这个API
    @ApiError ：发生错误返回的信息
    @ApiImplicitParam：一个请求参数
    @ApiImplicitParams：多个请求参数

    
    @AppLogin
    @GetMapping("/getUserInfo")
    @ApiOperation("获取用户信息")
    public R userInfo(HttpServletRequest request
    ){
        // 前台可以传递一个token 作为参数 也可以通过在请求头中获取
        // 在登录创建token 的时候 传入登录用户的id 设置token 的有效时间
        //  在有效时间内可以获取到登录用户的id 来使用
        String headValue = request.getHeader("APPToken");
        Claims claims = jwtUtils.getClaimByToken(headValue);
        String usersId = claims.getSubject().toString();
        User user = userService.findByPrimaryKey(usersId);
        return R.ok().put("users", user);
    }
A: JWT概念
     
    使用JWT我我们首先设置三个参数  Header 自定义头部， token 的有效时长，以及秘钥
    生成的token 主要是检查是否过期，获取登录用户的信息
    
    是一种用户双方之间传递安全信息的规范，跨域身份验证解决方案
    JWT组成 JSON WEB Token
    头信息（header）：Token类型以及采用加密的算法
    消息体（payload ：它包含了Claim，一般是一些实体（一般都是用户）的状态和额外数据组成
    签名（signature）：使用编码后的header和payload以及一个秘钥
    
    JWT 保护服务器端的资源， 客户端通过http 的header 发送给服务器
    由于前后端的分离 放弃了传统的 cookie-session认证机制， 使用JWT来管理session
    token = header + payload + signature
B: 易于水平扩展
    cookie内仅包含一个session标识符，session 作用服务器端，
    把session中的认证信息都保存在JWT中，在服务端就没有session存在的必要了。当服务端水平扩展的时候，
    就不用处理session复制（session replication）/ session黏连（sticky session）或是引入外部session存储了

基于Token的身份验证以及基于服务器的身份验证
    传统的做法是将已经认证过的用户信息存储在服务器上，比如Session。用户下次请求的时候带着Session ID，
    然后服务器以此检查用户是否认证过。这种基于服务器的身份认证方式存在一些问题：
    Sessions : 每次用户认证通过以后，服务器需要创建一条记录保存用户信息，通常是在内存中，随着认证通过的用户越来越多，服务器的在这里的开销就会越来越大。
    Scalability : 由于Session是在内存中的，这就带来一些扩展性的问题。
    CORS : 当我们想要扩展我们的应用，让我们的数据被多个移动设备使用时，我们必须考虑跨资源共享问题。当使用AJAX调用从另一个域名下获取资源时，我们可能会遇到禁止请求的问题。
    CSRF : 用户很容易受到CSRF攻击。

5.3. 基于Token的身份认证是如何工作的
           基于Token的身份认证是无状态的，服务器或者Session中不会存储任何用户信息。
    没有会话信息意味着应用程序可以根据需要扩展和添加更多的机器，而不必担心用户登录的位置。
    但其主要流程如下：
    用户携带用户名和密码请求访问
    服务器校验用户凭据
    应用提供一个token给客户端
    客户端存储token，并且在随后的每一次请求中都带着它
    服务器校验token并返回数据
    注意：

    每一次请求都需要token
    Token应该放在请求header中
5.4. 用Token的好处
    无状态和可扩展性：Tokens存储在客户端。完全无状态，可扩展。我们的负载均衡器可以将用户传递到任意服务器，因为在任何地方都没有状态或会话信息。
    安全：，token在一段时间以后会过期，这个时候用户需要重新登录    
5.2. JWT与Session的差异
    相同点是，它们都是存储用户信息；然而，Session是在服务器端的，而JWT是在客户端的。
    Session方式存储用户信息的最大问题在于要占用大量服务器内存，增加服务器的开销。
    而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。
    Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端
    
32 cookie和session 的区别
  cookie是服务器传递到浏览器，保存在浏览器中的数据，然后浏览器每次请求都带上cookie，
  这样就可以标识用哪一个用户发起的请求， 比如说把用户登录的用户名和密码保存在cookie中， 
  只要cookie没有过期，以后用户每次登录都可以自动登录了，不需要在此输入用户名和密码，
  因为浏览器在发起请求的时候已经把cookie中的用户名和密码传递给服务器了。

  session是什么呢？session把用户的信息保存在服务器上面，
 浏览器第一次访问的时候服务器把sessionID传递到浏览器，
 然后浏览器把Session_id保存在cookie中， 每次访问把session_id带上，
 服务器就可以标识这个请求来自于那个用户，然后根据session_id查这个这个用户的seesion
 里面记录了哪些数据