Session认证

因为根据HTTP协议，我们并不能知道是哪个用户发出的请求，所以为了我们的应用可以识别是哪个用户发起请求，我们只能在服务器中存储一份用户的登录信息，这份登录信息会在响应时传递给浏览器，并告诉浏览器保存为Cookie，下次请求时带上这份登录信息，这样我们的应用就可以识别是哪个用户发起的请求了，这就是传统的基于Session认证。

session 登陆验证_前端

session工作原理：
1、客户端提交登陆请求，把账号密码提交到服务器验证；
2、服务器验证通过，在服务器开辟内存记录人的信息，生成cookie字符串，通过响应的形式发送给客户端；
3、客户端收到cookie，浏览器保存起来；
4、客户端再次发起请求，浏览器会自动把所有可用的cookie发送给服务器端；
5、服务器端收到cookie后从内存中查找对应信息，找到则证明用户验证成功，针对用户生成特定页面响应给客户端；

整个过程是浏览器和服务器之间的交互，自动进行的。不需要客户端主动编程参与。

session 登陆验证_前端_02

理解:

1、完整的流程：

对于web应用来说，涉及到的其实是分层次的，首先的一个层次是，浏览器 与 web服务器的通信，所以session功能时web服务器提供的功能。

在WEB开发中，服务器可以为每个用户浏览器创建一个会话对象(session对象)，注意：一个浏览器独占一个session对象(默认情况下)。因此，在需要保存用户数据时，服务器程序可以把用户数据写到用户浏览器独占的session中，当用户使用浏览器访问其它程序时，其它程序可以从用户的session中取出该用户的数据，为用户服务。

用户A，开启一个浏览器，访问到web服务器，这个时候，在web服务器的内存空间，就会创建一个session对象，这是一个内存对象。然后这个对象有一个sessionID。在返回给客户端浏览器的时候，会写入到客户端浏览器的cookies当中。浏览器在没有关闭的时候，再次访问web服务器的时候，就会自动的带着cookies访问服务端，然后cookies当中的sesssionID，会让web服务器找到那个session对象。当客户端浏览器关闭的时候，web服务端的session对象也就销毁了。

用户B，再开一个浏览器的时候，访问到web服务器，此时，web服务器也会创建一个session，这个session对象与用户A的是不同的对象。

服务器创建session出来后，会把session的id号，以cookie的形式回写给客户机，这样，只要客户机的浏览器不关，再去访问服务器时，都会带着session的id号去，服务器发现客户机浏览器带session id过来了，就会使用内存中与之对应的session为之服务

2、客户端禁用cookies的情况：

需要说明一下，客户端禁用cookie并不是说服务端不发送，而是客户端丢掉。这个时候常用的修改方法，其实是URL当中带参数，这样才可以。

3、具体开发层面需要做的事情：

java web为例子：

httpsession，然后通过这个对象，getSession（）方法，获得的session 这里边有个前提条件，就是说，在可以这么做的过程，是因为服务器和浏览器提前的完成了相关的匹配动作。从而在编程的层面，或者说在开发的成眠是直接通过session对象，获取到具体对象，然后实现的已经登录的判断的。

对于spring MVC，javaweb（servlet),上述过程，完全一致，无任何差别。因为这个是浏览器和服务器之间的传递过程。

Session认证存在问题

  1. 每个用户经过认证之后，我们的应用都要在服务端做一次记录，以便识别该用户的请求，而通常来说，session都是保存在内存中，随着用户增多，服务端的开销会明显增大。
  2. 用户认证之后，服务端做认证记录，如果认证的记录保存在内存中的话，这就意味着该用户的下次请求必须在这台服务器上，这样子才能拿到授权的资源。(这是限制了，分布式扩展)
  3. 因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
  4. 前后端分离的系统中，如果使用session每次都携带sessionId到服务器，服务器还要查询用户信息，若用户很多，这个信息都存储在服务器内存中，给服务器增加负担。