更灵敏的超时机制与UserScript支持 about jlpt-bookseat HOT 11 CLOSED

去年报名第一天是手动去抢的，给这个系统整破防了。然后花了1天时间写了脚本，在后续日期成功捡漏，最终报上了隔壁省的座位。

但其实第一天的会话过期问题是最严重的，后续日期可能还好，所以我的脚本没考虑做登录功能。以至于今年的报名第一天，我被挤出去之后，在登录界面搞了5分钟以上才成功进去，好不容易看到有座，又给挤出来了。

最终报上了江苏扬州的（本人在江苏南京），但这个报名系统也着实恶心到我了。但看到网友用我的脚本抢到了南京的考位，怎么说呢。。。

兄弟，做啥行业的？愿意交个朋友吗？

from jlpt-bookseat.

感谢你对于本项目的关注以及反馈，以下是我的看法：

1. 关于jQuery
   1. 其实原网页已经有jQuery了，因为$被占用，在noConfict函数内被放到了全局的jQuery对象中。
   2. 虽然版本只有1.4.3，但ajax以及超时功能还是有的。
2. 关于油猴脚本
   1. 这个确实会比在控制台贴代码方便。
   2. 但我对于这个脚本的定位，是一个临时使用的辅助工具，用完一次可能不会有下次，应当尽量减少不必要的依赖。对于没有用过油猴的人，为了这个脚本去搞油猴插件，似乎有些麻烦。
   3. 可以同时提供控制台版本和油猴版本，以便有需要的人自取。
3. 关于ajax
   1. 原网页开发技术较烂，看其代码着实想笑。
   2. 诚然jquery的ajax提供了超时，原网页封装的Ajax并没有超时的功能。但是自己用ajax，需要分析原网页对请求头和请求参数做了些什么操作，即便这个不复杂，但是直接使用原本的功能，更加安全，更好的应对可能的风控和未来的更新，且请求相关的代码都直接从原网页抠出来稍加修改即可。
   3. 至于原网页Ajax缺失的超时功能，可以自己简单做一个，并没有几行代码。
4. 关于超时时间
   1. 我觉得ajax请求超时时间以及轮询时间，并不是需要经常变化的参数，不过有需要的话，做了也不复杂。但是界面上的参数越来越多，会让人感觉这个东西越来越复杂。
   2. 超时时间的取名（AJAX超时，关键AJAX超时），似乎不那么容易理解……

多说一点：

这个项目原本是我对于JLPT报考系统的苦恼、失望、绝望之后，产生的想法。花了点时间做出来，目的也只是服务于我自己而已。然后身边有些朋友也苦恼于报名，所以放在了github公开了。

去年的考试因为疫情取消，今年又得报名。早期版本只是一个纯脚本，由于没有界面，需要在控制台显示验证码，但高版本chrome内核不支持这个功能，还得找国产浏览器。所以本次报名之前，产生了做界面的想法，又花了一段时间做了界面，易用性得到了很大的提升。

不过于此同时，带来了另一个问题：公开的抢座脚本，热度越来越高，用的人也渐多，对于普通考生来说，非常不公平。另外，也不排除被黄牛拿去用于盈利的可能性。基于这些考虑，我可能不太希望这个脚本被做的特别专业化，对于脚本的维护可能也需要慎重考虑。

from jlpt-bookseat.

1. 不知道为什么，在 1.4.3的 jQuery 上我无论是用 method 还是 type，都不能很好地指定 HTTP Method，一怒而换新版 jQ，也用 noConflict 扔进了 jQuery 对象。
2. 我昨天和朋友交谈也确实涉及到了这一点，确实如此，因此两种都提供的方案是最合理的（我现在想来反而不应该提供油猴，更方便黄牛了长期使用了（（）。但要注意的是原网页有瑞数，在有瑞数的页面上打开 DevTools 会在服务器有记录。
3. 确实如此。我目前用 Fiddler 对比了两个 API 的请求，发现请求除了瑞数掺进去参数（这个每次都会变），其它参数和头部都是相同的。但即使换回 Prototype.js，个人感觉仍然需要把原先的超时机制的时间值做成可修改的。
4. 个人感觉实际上在目前服务器性能不稳定的情况下提供一个方便修改的参数还是有必要的，但取名确实太意识流了（草）。AJAX超时是普通的查询接口的调用超时，关键超时是 login.do 和 book.do的超时，因为这两个接口消耗验证码，且重发副作用比较大，因此设置一个大的值。我没想出来怎么把这层含义用一个相对短的名字表达出来。

实际上对于最后一点，我前面写过这样的文本。

换句话说，我认为在黄牛使用性能更高（他们大概率通过做灰黑产的人，已经完全拆开瑞数了）的Bot抢座，且收费代抢的情况下，向其它人提供免费的抢座脚本是有意义的。当然，这只是价值观上的问题，不同的人有不同的理解罢。我本来想自己用 JSRPC 之类的东西自己车一个，结果发现了您这套系统，十分惊喜。

from jlpt-bookseat.

我也认为应该删除油猴版本的代码。

from jlpt-bookseat.

@cqjjjzr 「timeout」と言う機能は一応実現されました

1903639

from jlpt-bookseat.

是的 会话也显然是个很小的LRU，这是造成bot和真人抢考位的不公平的最关键因素（我在图里也讲了）。

@jinyu2022 再三想了下，确实如此，我已经在我的分支force-push去掉这一部分的代码了。但DevTools触发瑞数的问题是真实存在的，可能还是需要考虑解决方案。考虑您已经写了新的Timeout机制，前面我实现的 jQ 也用不着了。

我的情况和您相似，不方便在 GitHub 交流个人信息，通过Mail PM您了。

from jlpt-bookseat.

DevTool会触发debugger，但抓包看并未产生相应的网络报文，我感觉JLPT网站接这个玩意儿没接全，安全措施仅体现于url后面跟的那个参数。事实上我搞脚本频繁触发DevTool的debug，并未对账号产生任何问题。

先这么用吧，除非哪天DevTool已打开导致掉线，或者封号一段时间，再说…………

from jlpt-bookseat.

但抓包看并未产生相应的网络报文

不，首先它记录了debugger调用前后的时间，因此肯定能在第一次时发现debugger被打开了。如果跟进去那个高度混淆过的代码的逻辑，会发现它会把很多检测到的这些信息放进 Cookie 和请求参数里。

相关的内容您可以看 https://blog.csdn.net/weixin_44862184/article/details/125302589 ，实际上它用的这套框架已经相当于一个 WAF 的安全等级了，所以这类脚本潜在的吃 gank 的风险实际上是相当巨大的。只能说是 NEEA 的人没有接全，甚至业务代码还是明文的。

from jlpt-bookseat.

现在会一直报 获取状态失败。查看返回值，是服务器忙或者发送的请求导致了系统异常，请求无法处理。请点击 这里 返回上一个页面。，不知道会不会有影响

from jlpt-bookseat.

现在会一直报 获取状态失败。查看返回值，是服务器忙或者发送的请求导致了系统异常，请求无法处理。请点击 这里 返回上一个页面。，不知道会不会有影响

也许你试下清理掉所有cookie、缓存，再试下。问题反复出现的话，新开个issure

from jlpt-bookseat.

已经抢到了，感谢大佬，感觉是后端对登录前的status.do处理和登录后的不一样，所以我等到59分55秒的时候，再点的启动

from jlpt-bookseat.