前后端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，将会产生跨域问题