cookie的诞生

HTTP无状态：服务器无法知道两个请求是否来自同一个浏览器，即服务器不知道用户上一次做了什么，每次请求都是完全相互独立

交互式Web：客户端与服务器可以互动，如用户登录，购买商品，各种论坛等等

Cookie的诞生是为了解决HTTP无状态的特性无法满足交互式web

cookie交互原理

1、用户在输入用户名和密码之后，浏览器将用户名和密码发送给服务器，服务器进行验证，验证通过之后将用户信息加密后封装成Cookie放在请求头中返回给浏览器。

2、浏览器收到服务器返回数据，发现请求头中有一个：Set-Cookie，然后它就把这个Cookie保存起来，下次浏览器再请求服务器的时候，会把Cookie也放在请求头中传给服务器

3、服务器收到请求后从请求头中拿到cookie，然后解析并到用户信息，说明此用户已登录，Cookie是将数据保存在客户端的

cookie属性

重定向原理

客户端向服务器发送请求的时候,服务器如果重定向的话,返回状态码301或者302给客户端,在响应头中存放location,location对应的值就是重定向地址,客户端收到状态码为重定向,直接浏览器本地进行访问

一次线上问题排查过程

问题现象：

企业微信A企业，集成两个移动审批，分别使用wx_third和multi_wx3，在企业微信中交替访问两个移动审批，发现其中一个没有走对应集成方案的单点登录，比如打开multi_wx3的移动审批，实际url地址中的为wx_third，并且实际换取到用户身份也不是实际的值

移动计划在同场景下的数据交互实例

摘要

1、URL:https://qy-ci.fdccloud.com/appcenter/dispatch/open?__tenant_id=my59844a86a6053&__wx_menu_id=54&__from=wx_third2、URL:https://qy-ci.fdccloud.com/plan-  micro/my59844a86a6053/task/home/index?__from=wx_third3、URL:https://qy-ci.fdccloud.com/plan-micro/my59844a86a6053/task/home/index?__from=wx_third4、URL:https://qy-ci.fdccloud.com/plan-micro/my59844a86a6053/schedule/calendar/index?__from=wx_third#/message/index

批注：

1、请求分发地址dispatch/open，服务端告诉浏览器需要要重定向到真实的计划地址

2、浏览器开始请求真实的计划地址，服务端发现_from参数与cookie不一致，强制退出登录，并告诉浏览器再次重定向到当前页面，服务端同时设置了最新的cookie值与_from参数一致

3、浏览器再次请求计划的真实地址，同时携带了最新的cookie，重新进行了免登，移动计划再次告诉浏览器需要再次做重定向到计划的消息页面

4、浏览器开始请求计划的消息页面

移动审批在同场景下的数据交互实例

摘要

1、URL: https://qy-ci.fdccloud.com/appcenter/dispatch/open?__tenant_id=my59844a86a6053&__wx_menu_id=130&__from=multi_wx3

2、URL: http://qy-ci.fdccloud.com/workflow-micro/my59844a86a6053/workflow/process-list/index?kindType=1&status=0&__from=multi_wx3

3、URL: http://qy-ci.fdccloud.com/workflow-micro/my59844a86a6053/lists/process-list/index?kindType=1&status=0&__from=multi_wx3

4、URL: https://qy-ci.fdccloud.com/workflow-micro/my59844a86a6053/lists/process-list/index?kindType=1&status=0&__from=multi_wx3

批注：

1、请求分发地址dispatch/open，服务端告诉浏览器需要要重定向到真实的审批地址

2、浏览器开始请求真实的审批地址，移动审批在actions()方法中拦截到了当前是新服务，然后告诉浏览器要重定向到

新服务地址

3、浏览器开始请求移动审批的新服务地址，此时vendor beforeAction()检测到当前请求的地址是http协议，告诉浏览器需要重定向到https，并且把最新的cookie返回给了浏览器

4、浏览器开始请求https的审批地址，直接进入了应用，前面没有做任何退出登录，也不满足_from参数和cookie的值不一致，此时的用户实际身份还是上一个集成方案对应的用户

总结：

为何审批的执行流程和计划相差这么大，正是这个差别导致计划表现正常而审批发生串号的问题所在。

问题根源在于我们期望是在beforeAction()中实现检测__from的变更，从而实现退出登录，通过重定向再次登录的逻辑。但是审批比较特殊，他们在几个重要的控制器中重写了actions()方法，他们也会做重定向，而且actions()是在beforeAtion()之前执行的，最新的cookie已经被审批返回给浏览器了，下次再进入最终的审批页面时，beforeAction()是检测不到变更的，自然也实现不了退出登录再重新登录