java笔记之cookie和session的认证

前言：

在互联网发展的初期，Web基本上只是内容的浏览而已，服务器不需要记住每个请求的状态，也就是说每一次客户请求都是一次新的请求，这也就是http无状态的一个表现。随着互联网时代的到来，尤其是购物网站的兴起，系统需要辨识出用户信息。解决办法就是在客户端请求的时候携带一种标识，这中标识就代表不同的用户，这样服务器就能区别出不同的用户了。这就诞生了用户认证的这个概念。

用户认证：简而言之就是验证一个用户是不是合法用户的处理过程

有一点需要记住，认证和授权不是一回事。是两个不同的阶段。大部分系统都是先对用户进行验证在进行授权。举例，

普通用户和管理员同时登录一个网站，出现的界面是不同的，那么登录的过程就是验证，出现不同的页面就是授权的具体表现。

1 session认证

session：在网络应用中被称为"会话控制"。session对象储存特定用户会话所需要的属性和配置信息。这样用户在页面跳转的时候 储存 session对象中的变量就不会丢失，而是在整个用户会话中一直存储下去。如果用户还没有会话 web服务器会自动创建一个session对话，当对话过期或或者被放弃后，服务器就会终止该对话。

基于session认证方式的最主要的一个特点就是 服务器端存储这用户信息，客户端是通过携带一个sessionid的cookie来做session表示的。很多项目都喜欢用session认证的方式，这种方式对于快速开发上线项目极为有利。每个客户端需要保存一个cookie，但是服务器端却需要保存成千上万的session信息，这无疑是对服务器端造成了很大的压力，尤其是当做了负载均衡之后。session的命中问题更为可怕。举一个例子；用户A登录系统成功，服务器A下发sessionid，session信息存储在服务器A上，如果当下次请求到服务器B上的时候，由于服务器B上没有session信息，所以就造成了未命中的现象，这也就是session认证解决方赞实施过程面临的一个问题，解决办法就是 其中一个便是 session复制 ，服务端的每一个服务器都存储一个session的副本，这样请求不论到那个服务器都可以访问到session信息了。但是这样就增加了服务器的存储压力，还会出现复制延迟，session更新同步 过期同步等问题。

解决问题就是利用第三方进行集中存储 redis，memcached把sessio信息都存储在同一个地方，所有的服务器都访问这个地方，

引入第三方就存在第三方挂到的可能性，所以现在都基本采用第三方集群的方案来减小这种可能性。大多数session机制是基于cookie的。在一定程度上session的 io操作话费的时间有的时候也是很大的，

cookie 验证

把用户信息都放在客户端，么了服务器存储的压力。

服务器处于无状态的形式，所以可以很方便的横向扩展。

基于cookie的认证方式也有很多缺点。

1 cookie 是存储在客户端的，所以在一定程度上增加可以伪造的几率，安全性稍微弱一点。

2 由于cookie在浏览器有跨域的阻拦，所以在有跨域需要的时候，需要服务器做相应的配置，

3 cookie 是有长度的限制的，所以不宜存储过长的信息。

4 用户的客户端可能会禁用cookie，这个时候可以依靠url传值来解决问题。

5 服务器端想要操作cookie认证信息的失效比较困难，不像session认证那样方便。

 

最后；

无论是session 还是cookie认证，都是需要客户端上传标识，都需要服务器下发标识，并且对这个标识进行加密，标识里最好加上来源ip过期时间这个属性。在配上https 可以更加有效的保护整个认证流程和数据。也许还有很多更好的认证方式。