微信 JS SDK 签名算法的意义

Question

微信 JS SDK 使用前需要签名，大致步骤：

1. 使用 appid 和 appsecrect 获取 access_token
2. 使用 access_token 换取 js_ticket
3. 使用 js_ticket, url 和一些变量来生成 signature

这三步按照官方文档都要求在服务器端进行，并且每次页面 url 变化都需要重新签名。

对于签名过程这么设计的原因，我有几个不解的地方，想请教一下大家的看法：

1. 三步都需要在服务端进行，那么 js_ticket 的作用是什么？我能想到的可能用处是今后有效期可以和 access_token 不一样长；
2. 微信文档说：“对于变化url的SPA的web app可在每次url变化时进行签名”，是否说明这种情况下，签名的步骤其实是需要将js_ticket暴露在前端完成的（和服务端进行的要求不符）？
3. 微信让每个应用配置3个js安全域名，是希望根据域名进行授权，这个很好理解，即使我拿到了其他应用的签名，我也不能在自己的页面使用。但相同域名下的权限应该是相同的，那 SPA 还需要根据当前完整 url 来生成签名的意义是什么？

Answer 1

1. js_ticket和access_token应该是权限不同
   在其他业务逻辑刷新access_token时 如果js_ticket没过期 则不影响jssdk的调用 文档也提到获取js_ticket的api次数有限

2. SPA的话 是指#前的url变动 -> http://segmentfault.com/q/1010000002520634/a-1020000002531131

Answer 2

我的做法是：1、2步在服务端完成，因为有取access_token和js_ticket是有限制的，每天2000次，而access_token、js_ticket的有效期是2小时，如果能在服务器端记录下有效期，当过了有效期再去取。其实一天24/2=12次去微信请求就足够了。js_ticket到手后，前端页面就用当前URL+js_ticket生成signature。否则你的2000次很快就用光了。