Java Web疑难知识点

session,cookie和token
cookie session
cookie只是实现session的其中一种方案。虽然是最常用的，但并不是唯一的方法。禁用cookie后还有其他方法存储，比如放在url中
现在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理论上都可以保持会话状态。可是实际中因为多种原因，一般不会单独使用
用session只需要在客户端保存一个id，实际上大量数据都是保存在服务端。如果全部用cookie，数据量大的时候客户端是没有那么多空间的，一般cookie空间限制只有4KB。
如果只用cookie不用session，那么账户信息全部保存在客户端，一旦被劫持，全部信息都会泄露。并且客户端数据量变大，网络传输的数据量也会变大。
token 认证流程
用户登录，成功后服务器返回Token给客户端。
客户端收到数据后保存在客户端
客户端再次访问服务器，将token放入headers中
服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

如何防止表单重复提交
在服务器端生成一个唯一的随机标识号，专业术语称为Token(令牌)，同时在当前用户的Session域中保存这个Token。然后将Token发送到客户端的Form表单中，在Form表单中使用隐藏域来存储这个Token，表单提交的时候连同这个Token一起提交到服务器端，然后在服务器端判断客户端提交上来的Token与服务器端生成的Token是否一致，如果不一致，那就是重复提交了，此时服务器端就可以不处理重复提交的表单。如果相同则处理表单提交，处理完后清除当前用户的Session域中存储的标识号。

session同步
进程间通信传递session数据
在不同的server服务里开一个socket，然后用socket来将相互拥有的session数据进行传递。
这种方法容易造成同步延迟，而且服务器不断向外界广播session信息的时候系统负担很大。
cookie存储方式
把session数据做加密，然后存储到cookie中。用户请求到了，就直接从cookie读取，然后做解密。
cache集群或者数据库做session管理
引入统一session接入点，我们session放入到cache集群或者数据库中，每次请求的时候，都从他们中来获取。

CAS和OATH2.0实现SSO
CAS单点登陆原理
1、登录信息传递
1)、用户浏览器访问系统A需登录受限资源，此时进行登录检查，发现未登录，然后进行获取票据操作，发现没有票据。
2)、系统A发现该请求需要登录，将请求重定向到认证中心，获取全局票据操作，没有，进行登录。
3)、认证中心呈现登录页面，用户登录，登录成功后，认证中心重定向请求到系统A，并附上认证通过令牌，此时认证中心同时生成了全局票据。
4)、此时再次进行登录检查，发现未登录，然后再次获取票据操作，此时可以获得票据(令牌)，系统A与认证中心通信，验证令牌有效,证明用户已登录。
5)、系统A将受限资源返给用户。
已登录用户首次访问应用群中系统B时：
1)、浏览器访问另一应用B需登录受限资源，此时进行登录检查，发现未登录，然后进行获取票据操作，发现没有票据。
2)、系统B发现该请求需要登录，将请求重定向到认证中心，获取全局票据操作，获取全局票据，可以获得，认证中心发现已经登录。
3)、认证中心发放临时票据(令牌)，并携带该令牌重定向到系统B。
4)、此时再次进行登录检查，发现未登录，然后再次获取票据操作，此时可以获得票据(令牌)，系统B与认证中心通信，验证令牌有效,证明用户已登录。
5)、系统B将受限资源返回给客户端。
https://zhuanlan.zhihu.com/p/60178090