本节开始讲认证相关的东西、注意事项，出现问题的对应的解决方案。
先写用户注册的服务，注册一些用户信息进去。注册也是咱们安全体系的一部分mysql
注册
UserController里面的create方法
先修改实体类，加上username和password
由于咱们已经在配置文件内配置了generate-ddl为true，启动的时候jpa会自动把这两个属性加到数据库里，这样就不用咱们本身手动去数据库里加属性。
设置主键的策略，这里设置的是根据当前数据库的类型策略，例如当前是mysql数据库，那么就会按照mysql数据库的策略。自增的字段策略。
sql
@GeneratedValue(strategy = GenerationType.IDENTITY)数据库
strategy
美 ['strætədʒi]
英 ['strætədʒi]编程
- n.策略；战略；策划；战略部署
- 网络策略模式；谋略；计谋
建立userInfo对象
复制user这个类，改个名字叫作userInfo。
这里把@Entity去掉。由于它不是实体，也就是不和数据库内的表对应。UserInfo用来封装咱们服务的请求和响应。
保留@Data注解，这回帮咱们生成get和set方法。
UserController里面凡事用到user的地方都改为UserInfo
那么为何要这么改呢？这两个对象从如今来看，属性是如出一辙的，为何要分红两个呢？这就是编程里面比较常见的一个概念，关注点分离。
也叫作单一职责原则。任何一个类或者方法它应该只关注一个事，或者说只对一个事负责，只有当这个事变化的时候，我才须要改这个类或者这个方法，若是咱们用User类来做为Controller的输入或者输出，那么User这个实际上就负责了两件事。第一件事是跟我么的数据库表作映射，这个对象反映出来咱们数据库有哪些字段，那个字段是主键等等这些信息，它是负责跟数据库里的表作映射的。
而咱们Controoler里面的方法 他的用参和出参其实是服务的输入和输出。这个其实是两个概念。 若是咱们在这两个关注点上用同一个类。都用User的话，那么User负责的事情就会变多。这个类负责的事情变多就会致使，每个事变化的时候我都要去改User,就会发生一些问题。
好比数据库结构发生变化的时候，我要去改User，当建立用户或者修改用户的服务发生它的输入和输出发生变化的时候，我也须要去改User
。这个时候User这个类 它的职责就不清晰了。这不是一个好的编程概念。
举个例子，例如用户表里面加一个积分字段。 这个是一个很常见的需求。
若是我加了积分字段，在Controller里面还用User对象做为输入或者输出，就意味着个人注册方法组要的字段里面也多了个积分字段。可是注册的时候，基本没有要求你填写积分信息的吧？？？因此这就是咱们为何要建这个UserInfo对象的缘由。这就是关注点分离。
你们在编程的时候也要注意这一点。它会让你设计出良好的程序。安全
服务层Service
也就是咱们常说的Service层。
在建立Service的实现类
controller层暴露app服务，app服务进来后交给service层，service层再去调用DAO也就是Repository作数据库操做。这样职责就彻底区分开了
service层负责实现业务逻辑，Repository专门负责数据库的操做，通常状况下Repository也不会有什么业务逻辑
声明service内的方法。和controller内是对应的
在Service的Impl类里面都 实现这些方法。
把实现类声明称Spring的Service对象，也就是Spring的一个Bean
Controller内调用Service层的方法
写Create方法。使用BeanUtils里面的方法，把传进来的UserInfo对象的值都复制到User这个对象里面。
把user对象保存后的id，复制给info对象，再返回回去。这样前天就能拿到你最终建立的这个用户的id是多少。
这样一个简单的注册就写完了网络
运行测试
返回的状态码是200。返回的信息就是注册的时候填写的信息，同时还有数据库最终生成的主键自增的id
日志里面打印出了insert语句
数据库内的记录
app
下面继续写认证的逻辑
先明确几个概念，咱们如今讲的是认证，还不是登录。
认证是验证用户的身份是否合法的这样一个过程。认证这个事 无论 成没成功，它都要往下走。它和登录不同。登录一旦有问题就断掉了。好比说你登录的时候用户名和填错了。那么我就直接抛异常了，不会再往下走了。认证的时候，若是你传进来的用户身份有问题，仍然要往下走，给下面的审核去记录，记录你此次的身份认证的结果是什么样子的。最终这个请求是否是能够被经过，要由受权来决定。不是由认证来决定的。
明确好了这些概念。就能够写代码。
测试