springboot,springmvc 中通过 熟悉Swagger测试api接口
Swagger是当前最好用的Restful API文档生成的开源项目
//里面有中文文档和英文文档
调用和可视化 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
里面记录了哪些数据
