由于公司网络的关系，在线听音乐经常会被断断续续，于是考虑批量将音乐（高清）下载到本地。同时，由于熊孩子的缘故，在自己的音乐榜单上「小苹果」等歌曲一直在前排，显得很没有「格调」，于是就萌生了折腾云音乐接口的想法。

网易云音乐的接口相对而言还是比较简单，尤其是大部分前端与服务器端通信的逻辑都已经在 core.js 里面，虽然加了压缩但是没有混淆因此还是很好去处理和理解。

访问云音乐接口每次都需要带个名为 csrf_token 的 GET 参数，这个参数很好找就在 Cookie 里面，而且还是持久化的。

剩下的两个参数大部分都是 POST 过去，分别名为 params 和 encSecKey，里面的字符串经过 encodeURIComponent 处理过。

加密和解密的方法还是在 core.js 这个文件里面能够找到，AES CBC 加密，客户端自己生成 Pair 。两个加密解密的方法都暴露在全局作用域下，分别名为 window.asrsea 以及 window.ecnonasr 。

部分的接口，例如 feedback/weblog 是没有做任何重复请求处理的，换句话说可以刷。上面说到 csrf_token 其实是持久化的，也没有来源判断等，因此拿到 Cookie 以后就可以自己构造请求。

不过话说回来网易的平台设置做得的确财大气粗，乃至多点并发去做请求都能撑得下来（估计是我的小水管还不够人家的零头）。

顺便提一句，再深入研究下其实可以发现非会员也可以下载收费资源，这里不铺开讲了。

总结下一些看起来是「大道理」的心得：

1. csrf_token 这些参数应该和时间和请求次数挂钩，更不应该加入到 Cookie 里；
2. 客户端和服务器端的加密一直是安全方面讨论的主要课题，我的倾向是轻客户端重服务器端，不要把所有的逻辑都写在客户端中；
3. 前端脚本代码的打包方面尽可能的不要污染全局空间，尤其是框架方面的代码；
4. 服务器端应该对用户异常行为作出判断，例如业务方面用户频繁下载以及标记打星是否合理；
5. PS，网易云音乐考虑下 WebSocket？
6. 查找和 Hook 网络接口这块可以从请求方法入手，通常现在端架方面请求都会放在一个方法中处理；
7. 有点废话，抓取的时候使用 HTTP Keep-Alive 头能够明显的加快请求速度；
8. 可以考虑多个 IP （代理）去抓取数据，以免实际地址被服务器 Block；
9. 实际情况中需要考虑的外部因素有很多，例如尽可能的在预算范围内购买足量的存储空间…；
10. Charles 很好用，这钱花得值…

最后，顺便刷个榜开个玩笑捣蛋下。

-- EOF --