Fix api return code -352

[F-park]

提取暴力了一点。
这个参数是个 jwt，必定以 eyJ 开头，末尾碰到 %22（双引号）就说明结束了。
这个 script 在 header 里，而且是第一个加载的 script，不会提取到其他东西的。

---

fix #248

[gaogaotiantian]

这个提取有点太糙了。更重要的是，在过了一阵之后，你就会忘掉这个提取的意义。换任何一个人来，它都不会知道这是在干啥，以及eyJ是啥意思。

另外你现在改的那行上面的comment显然不是在说这个magic的含义，读起来就更费劲了。

还有一个很重要的点，这个东西是一定要cache的，这个fetch可不比一个普通的API call，这玩意返回的是一个html，压力很大。所以要设置一个大概比如一个小时左右的cache，先检查cache里是不是已经有了，过期了再去刷。这样也不用每次拉info都额外等一个html的request。

match那个部分首先是要注释一下在做什么，另外你的match哪怕不从__RENDER_DATA__开始，也得从access_id开始，这样看代码起码知道这大概是match了个什么东西，然后在网页中怎么找。中间那个部分的JWT是不是应该有个vocabulary，比如[a-zA-Z0-9_\-]之类的？inclusive的东西永远是更好的。

[F-park]

用了更严格的正则和正则捕获组来提取 jwt。b 站前端写着有效期为 86395 * 1000，用这个时间来保证有效应该可行。

[F-park]

想了一下，既然一天获取一次，那也不用正则表达式了，直接 parse html 就好了

[gaogaotiantian]

没必要干到storage local，这也是一个extra的东西，不一定在memory里。就上面一个全局变量就足够了。而且不要拉这么极限。不要每次都重新request的另一面不是要把这个valid time拉满。给自己打出足够多的富裕。你拉这么满，前后那一点肯定会出现失效的情况。

思维再工程化一点，对于这种html，一个小时request一次是毫无压力的，86395就是24个小时嘛，你一两个小时request一次足够了，这样万一以后B站把这个数稍微改小一点，也不会出什么状况。

[F-park]

改成一小时了。

[noonisy]

我这边，貌似在data["api"] == "info"中，"data"都没了，直接用d["mid"]，后面几行的也是

biliscope/scripts/ui.js

Line 671 in 1510ff9

this.data["mid"] = d["data"]["mid"];

[F-park]

我这边，貌似在data["api"] == "info"中，"data"都没了，直接用d["mid"]，后面几行的也是

biliscope/scripts/ui.js

Line 671 in 1510ff9

this.data["mid"] = d["data"]["mid"];

无法复现，这结构不会改的。

[noonisy]

OK，我的问题，没改

[F-park]

我把条件里的 this.jwt 改成 this.jwtTimestamp 了。
一开始是想着拿到的 this.jwt 可能网络问题为空，就得重新请求。
现在想想如果为空肯定是被b站改网页结构了，请求一次请求不到就不需要再请求了。

[gaogaotiantian]

用timestamp做判断非常怪，看着很别扭。这里你update timestamp的时候判断一下this.jwt是不是就行了。

[F-park]

没看懂你的意思。
this.jwt 改成 this.jwtTimestamp 后，在正常情况下效果是一样的，也就是以下两种情况主动请求 jwt（不用 cache）

1. 页面第一次显示用户卡片
2. 在此网页待一小时后

但在b站改网页结构后，this.jwt 会恒定为空，因为拿不到 jwt。那上面第一个情况就被变了，每显示一次用户卡片都会请求一次 jwt。而改成 this.jwtTimestamp 不会出现这种情况。

[gaogaotiantian]

我开始是觉得去判断timestamp来决定要不要return jwt有点别扭，但是重新看一下觉得还可以。但是你外面的caller需要判断这个jwt是不是valid的，如果不是就不要加这个param，否则你就是带了一个垃圾param。