各分站请求接口的变更
由于单站模式下全部分站在同一域名下，故所有接口变更至请求总后台。
变更要点：
1. 所有 POST 请求改为 GET 请求。
2. 请求地址统一读取 window.JPAction, 由认证站获取开关时提供。
3. 所有请求追加附加参数：source_site，读取CONF.xy_source_id，由各分站配置文件提供。
4. 各分站文件加载与跳转地址均改为相对路径。
王昭帆：接口通讯安全设计
跨域请求的设计要点：
1、通信使用https。
2、请求签名，防止参数被篡改。
3、身份确认机制，每次请求都要验证是否合法。
4、对所有请求和响应都进行加解密操作。
5、其他安全设计方案。
如果对数据的安全性要求高，需要以下实现：
1、当有POST请求的数据发出时，前端统一加密。
2、后台将返回的数据加密处理。
3、前段统一处理数据的响应，在渲染到页面之前进行解密操作。
前端加密可以一定层度提高接口的安全性，但是前端服务本质上是不够安全的，不可靠的。如果采用AES对称加密。那么前端必然会导致加密的key泄露。针对这种情况，只能借助后端提供一种动态的加密key的方式。利用RSA非对称加密和AES对称加密结合。AES加密效率高，RSA安全性高但运行速度慢，用RSA来加密传输AES的秘钥，用AES来加密数据，两者相互结合，优势互补。如下：
1、客户端启动，发送请求到服务端，服务端用RSA算法生成一对公钥和私钥，我们简称为pubkey1,prikey1，将公钥pubkey1返回给客户端。
2、客户端拿到服务端返回的公钥pubkey1后，自己用RSA算法生成一对公钥和私钥，我们简称为pubkey2,prikey2，并将公钥pubkey2通过公钥pubkey1加密，加密之后传输给服务端。
3、此时服务端收到客户端传输的密文，用私钥prikey1进行解密，因为数据是用公钥pubkey1加密的，通过解密就可以得到客户端生成的公钥pubkey2。
4、然后后端生成对称加密，也就是我们的AES,相对于我们配置中的那个16位长度的加密key,生成了这个key之后就用公钥pubkey2进行加密，返回给客户端，因为只有客户端有pubkey2对应的私钥prikey2，只有客户端才能解密，客户端得到数据之后，用prikey2进行解密操作，得到AES的加密key,最后就用加密key进行数据传输的加密，至此整个流程结束。