编 写：袁 亮 时 间：2015-11-27 说 明：多应用系统用户信息统一安全升级策略 一、问题 1、post请求之后，后退按钮导致加载失败，提示需要重新提交数据问题的解决 2、用户信息被抓包，会导致账号泄漏问题 二、原因 1、根据http协议，post请求非幂等，不能缓存，因此有响应头Pragma:no-cache 2、后退的时候，浏览器会强制提醒用户，确认是否重新输入数据 3、因此后退会出现白页 三、可能解决思路 1、post请求换成get请求，绕过限制 1.1 私密数据不安全，如果链接发给其他人，会导致账号被盗 1.2 统计代码中，会把这些链接都给存储下来，太危险 2、对get的数据进行可逆加密并加过期时间 还是解决不了上面的两个问题 3、先post发送私密数据过去，然后get跳转 四、完整思路 1、私密数据，必须要走post，不能get 2、先通过服务器间请求，将私密数据post过去 2.1 在客户端对数据进行签名及有效期 2.2 通过post将数据通过服务器与服务器传输 2.3 服务端返回该数据存储的token(类似session存储) 为防止服务器返回较慢，导致token丢失，token以客户端传过去的签名为准 2.4 该数据，只存储一个小时，超过则失效 3、get形式带上token去请求数据 3.1 根据token，取到对应的数据 3.2 用户之后的token要删除，不允许重复使用 3.3 取出的数据需要验证是否有效期内，并验证签名是否正确 4、解决了哪些问题 4.1 没有通过get传输私密数据 4.2 浏览器没有发起post请求，因此不存在后退刷新的问题 4.3 私密数据通过服务器间的post请求，因此对用户抓包，并不能获取到这份私密数据 抓更原始的包那就没办法，虽然不知道原始数据，但还是能登陆到用户账户上 5、导致的问题及解决办法 5.1 比之前多了一次http请求，会变的更慢 在相应的服务器端加host，降低解析时间（同一机房，走内网） 服务端只做数据存储到内存，不做额外操作降低运行时间 客户端设置超时，防止卡住 5.2 memcache存储的数据，存在一定几率丢失 可以暂时不考虑，概率太低，而且最坏的影响也就是用户某一次可能登陆不上（只有新用户） 5.3 token丢失或被抓包 32位的加盐散列，基本可以不考虑被暴力强刷 token即使丢失，问题也不大，因为token生成之后，用户基本上马上就使用，之后token就失效了
使用范例见附件：build_query