技术宅预约Kou罩那些事儿

俗话说需求推动技术的发展，当下Kou罩也成了炙手可热的硬通货，颇有一般等价物的意思。

今天偶然看到了公众号推送的文章，emmmmKou罩也要线上预约了，本着技术服务生活的态度扫码进去看了一下，界面简单清爽，嗯！做的蛮不错！好评！

凭借职业敏感性，咦，没有看到有传参数呀，他怎么知道我预约的是哪家药店，反正周末有生无聊，好奇心害死猫，随即从二维码下手。二维码解码结果：

从解码结果可知有两个参数，一个是id，猜测为区别不同药店的参数（经测试之后id参数确为区别不同药店的代码），isright参数暂时不知道是用来做什么用的，没有isright参数或者将此参数修改为其他值仍然可以成功请求，后台也没有对此参数正确性的校验，所以目测isright参数应该用处不大。

课代表敲黑板！！重点来了！

进入信息填写界面，界面大致是这样

右键查看网页源码，一个很简单form来填写相关信息，重点在522行在WdatePicker日历控件绑定一个onClick事件，当选择之后触发onpicked绑定的getConfig() 的function

在网页源码中找到getConfig()方法，此处会带上日期控件选择的日期向后台发送一个post请求后回调该js方法（第一个方框），抓包大法好，

抓取请求之后，一个药店上午投放80个名额，下午投放70个名额，150*5*10=7500个口罩，投放三天投放两万多个没毛病。解释下上图中这段代码的含义，如果服务端响应参数中xzrs-rs小于等于0则显示已满，否则显示为可预约，可预约数量即为xzrs-rs的差值。

此时疑问来了，这个请求只携带了日期参数，并没有携带相关的药店信息的参数代码，服务端是怎么知道我是预约的哪个药店，刚开始一度以为难道所有药店都使用的这一个请求，这个情况就比较恐怖了.....但经过测试之后每家药店的不同时间段所返回的id是不一样的（如上图），说明后台在接收到这个请求的时候对不同的药店是有区分的，也就推翻了我最初的猜测，最后发现是在点击首页中的XXXX预约按钮之后，后台会悄悄给浏览器一个带有药店ID的cookie，请求的时候会带上cookie对服务端进行请求，问题不大，没毛病。

（因为前段对于表单中的字段是否为null有进行判断，所以修改了后台响应回来的参数，来继续我们的实验）

经历万恶的正则表达式校验，点击预约..emmm果不其然失败了！解析下请求参数吧

请求参数分别是name姓名，card身份证号，phone手机号，fxwz未知参数，yyrq预约日期，yysjd预约时间段，如果预约成功，后台会生成一个预约号，并且返回相应的预约信息，类似于这样，但这张图是不能够用的，因为后台是没有给我返回任何预约号的......

本次实验基本就是这样，系统做的没毛病，预约完的确就不能再预约到口罩了，感兴趣的同学可以使用一些请求模拟工具来提高抢口罩的效率~~

声明：本篇文章仅做学习参考使用，基于系统公开信息仅对系统运行逻辑进行解读，技术层面并未对系统有任何入侵。