先后端session同步

会话

传统的web开发采用的通常是会话技术，由于http是一种无状态协议，服务器端要想肯定不一样的请求是不是由同一个用户发出，采用了会话技术，传统的web开发当中，同一个会话内的全部请求对应着同一个session(session是服务器端为用户储存的文件)，每一个session对应一个id，当用户第一次访问时，服务器将这个session_id写入浏览器的cookie中(注意这个cookie比较特殊，通常由浏览器贮存在内存里),因而在会话结束前，以后发送的每次请求中，该cookie中所存的session_id都会被发送到服务器端，基于这样的机制，服务器就能够维持会话中的一些基本信息了。

先后端分离后的会话

在先后端分离以后，数据交互通常采用了json，这种状况下并不存在cookie和session的交互，为了维持会话通常会采用token的形式，对于一次会话后端会生成一个独一无二的token来标识它，每次前端发送数据时带上这个token，后端就可以识别和维持会话了。可是若是对于全部的会话，尤为是临时对话，若是都要生成token来标识，比较难维护。

先后端session同步

综上，对于临时对话，后端仍旧能够采用session的方式来维持（好比验证图片验证码的场景），可是此时前端发送的请求必须模拟传统http请求（xxx-form-urlencoded），请求必须带上cookie来维持session.

实战

场景：图片验证码的获取和验证（两个接口，两次请求） 前端：react + fetch 后端：laravel框架

首先前端正常fetch访问获取接口，访问后后端将在cookie中写入一个session_id(laravel_session)，注意laravel每次的session_id都会变更，所以下一次请求带的是上一次请求结束时被写入的cookie

后端此时在对应的session中存储了验证码的字面内容，前端下一次发送请求时，必须保证是和获取的请求在同一会话中，后端才能同步调用这个session来验证内容是否正确。所以调用验证接口时，前端必须模拟传统请求方式来带上token

fetch中，将header的Content-Type设置为xxx-form-urlencoded，body采用get字符串形式(key=val1&key2=val2)，设置成请求带上cookie的方式来发送，就能成功进入同一个会话。

若是不模拟传统方式来发送，仅仅带上cookie，将会产生跨域问题