苹果cookie是打开还是关闭_cookie那些事

cookie的诞生

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

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

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

cookie交互原理

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

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

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

cookie属性

属性	描述
HttpOnly	标记为 Secure 的 Cookie 只应通过被HTTPS协议加密过的请求发送给服务端。使用 HTTPS 安全协议，可以保护 Cookie 在浏览器和 Web 服务器间的传输过程中不被窃取和篡改
Secure	如果一个cookie被设置了Secure=true，那么这个cookie只能用https协议发送给服务器，用http协议是不发送的
Domain	Domain 指定了 Cookie 可以送达的主机名。假如没有指定，那么默认值为当前文档访问地址中的主机部分(但是不包含子域名)。 像淘宝首页设置的 Domain 就是 .taobao.com，这样无论是 a.taobao.com 还是 b.taobao.com 都可以使用 Cookie。 在这里注意的是，不能跨域设置 Cookie，比如阿里域名下的页面把 Domain 设置成百度是无效的
Path	Path 指定了一个 URL 路径，这个路径必须出现在要请求的资源的路径中才可以发送 Cookie 。比如设置 Path=/docs，/docs/Web/ 下的资源会带 Cookie 首部，/test 则不会携带 Cookie 首部。 Domain 和 Path 标识共同定义了 Cookie 的作用域：即 Cookie 应该发送给哪些 URL
Expires	当 Expires 属性缺省时，表示是会话性 Cookie，像上图 Expires 的值为 Session，表示的就是会话性 Cookie。当为会话性 Cookie 的时候，值保存在客户端内存中，并在用户关闭浏览器时失效。需要注意的是，有些浏览器提供了会话恢复功能，这种情况下即使关闭了浏览器，会话性 Cookie 也会被保留下来，就好像浏览器从来没有关闭一样。 与会话性 Cookie 相对的是持久性 Cookie，持久性 Cookies 会保存在用户的硬盘中，直至过期或者清除 Cookie。这里值得注意的是，设定的日期和时间只与客户端相关，而不是服务端
SameSite	SameSite 属性可以让 Cookie 在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击(CSRF)

重定向原理

客户端向服务器发送请求的时候,服务器如果重定向的话,返回状态码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_third 2、URL:https://qy-ci.fdccloud.com/plan-  micro/my59844a86a6053/task/home/index?__from=wx_third 3、URL:https://qy-ci.fdccloud.com/plan-micro/my59844a86a6053/task/home/index?__from=wx_third 4、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()是检测不到变更的，自然也实现不了退出登录再重新登录