E站账号cookie分享_58云账号跨域实践总结

背景

账号体系是每款互联网产品的“标配”，58集团拥有多条产品线多种账号体系，有先期孵化(一直都是58账号体系)也有后期收购(非58账号体系)，情况多种多样较为复杂。而不同账号体系不同产品线都需有相应的团队分别进行开发维护，造成资源配置浪费，同时账号功能系统及安全体系风控能力参差不齐。

云账号整合账号相关的基础能力和安全能力并扩展为中台通用能力，对外提供统一的接入SDK，便于各账号体系快速复用，同时数据可托管至云账号平台，保证各账号体系数据的独立性，解决多套账号系统重复建设的问题，提供了统一的安全保障，进而达到提效的目的。

下图为云账号平台的整体架构图

云账号平台对外提供的接入能力统一为SDK的形式，即在业务方的各端直接调用登录SDK，即可完成登录相关的操作。

而对于账号系统比较特殊的是登录令牌，令牌在各端的实现方案也不尽相同。

这些接入方式中APP端和小程序端基本保持一致，令牌由客户端托管；PC端和M端的令牌基于Cookie的方案。

由于PC/M端的使用形式是在浏览器中，接入方和SDK 的主域名不一定相同，那么接入的过程中就会存在跨域的问题，下面是云账号平台在跨域问题中提出的一些解决方案。

什么是跨域？

首先我们先说下什么是跨域，说跨域一定会先说到URL的组成

协议 + 域名 +　端口号 +　资源地址

以５８的passport为例：

https://passport.58.com:8080/ticket

通俗的讲：只要协议，域名(子域名/主域名)，端口号这三项组成部分中有一项不同，就可以认为是不同的域，不同的域之间互相访问资源，就被称之为跨域。即跨域是指一个域下的文档或脚本试图去请求另一个域下的资源。

什么是同源策略？

同源策略/SOP(Same origin policy)是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。同源策略是浏览器的行为，是为了保护本地数据不被JavaScript代码获取回来的数据污染。

云账号平台跨域实践

云平台提供的SDK在业务方使用时需要满足以下几个需求：

① 云平台下的主票据需要写入到passport.58.com的cookie里

② 接入方的业务票据需要写入到业务方主域名的cookie里

③ 完成登录操作后，JS需要回调通知接入方。

大致过程如下图：

•Jsonp跨域+接入方式代理地址

基于JSONP的跨域，要求云账号平台提供的数据接口基于get请求，返回的数据为Jsonp的格式，大致流程如下：

① SDK在接收到操作成功的数据时，直接访问接入方的代理地址

② 接入方的代理地址将cookie种到接入方的主域名中

③ 前端回调接入方完成此次跨域操作。

•Iframe跨域 + script脚本 + 接入方代理地址

此方案建立在数据接口为post请求的基础上，主要利用iframe加载其他域下的请求，设置document.domain达到相互通信，并利用代理地址生成script脚本方式种cookie及回调。

大致流程如下：

① 通过iframe发起post请求到服务端

② 服务端生成代理数据(script脚本、Cookie信息)，302到接入方的代理地址

③ 代理地址执行种cookie及返回script脚本给客户端

④ 客户端执行script脚本完成回调

返回的script脚本回调信息大致如下：