ahutsunshine

@zhiTa-Y 最新版我简单看是没有这个接口了，还没研究最新版的运行逻辑，不过我觉得不用在乎这个吧，作为一个使用者，只需要提供cookie就行了

@LovelyWhite 关爱通是什么？可以说说这玩意，也许有机会抢一波😂 小程序肯定启用了的，这个很好验证的，你抓到获取购物车或者预约时间的api，然后不带nars，sesi或者改它们的值立刻就返回3000错误

@zhiTa-Y 只有老版本可以还可以使用预约的接口，新版本没了

叮咚对老版本增加了严格风控了，抢菜很容易被判定为异常的，现在还没什么好的方式避免这个，得研究新版本的逻辑和协议更新程序了。

看看今天行不行，code已经写好了，在写文档，不过暂时只能支持ios，如果android想要运行也可以，不过还是有风险。

@MataSong 别着急，我也是挺累的，五一5天，我更了4天，自己都还没有玩呢，在家写了4天code，比上班都累，你看5月2号那天和另外一个哥们搞到凌晨四五点。

@MataSong 之前用的是从@Runc2333 获取的签名算法(我们一起商量好的，为了可以统一控制分发和某些风险)，现在由于某些原因，@Runc2333 将服务器关了，我明天暂时更新下签名吧。

@a180285 我会不断维护这个项目，但其实目前无论怎么改都难逃风控(都是治标不治本的策略)。也有根治的方案，这个和@Runc2333 讨论过，但是对我本人而言，一方面需要消耗我个人精力较多，另一方面对用户的安全隐患较大。

风控的策略有很多，我举几个例子： 1. 当模拟请求时，由于参数很多，请求只会把必要的参数带上，但有些是基于规则生成的字符串比如`device_token`等，如果不是 通过逆向工程看到别人的实现，我们是不知道如何生成的，要么忽略要么随意填写，这样叮咚风控就很容易发现这些是非法的，不是从app里请求出去。 2. 即使我们可以拿到所有的参数造成和从app里发出的请求一样，但是叮咚会每隔一定时间扫描计算这个人在这段时间请求路径或次数是不是合法，一旦发现这段时间内请求过多，就会被判定是非法遭到风控。 遭到风控的账号轻则出现`405`或者`同一时间下单人数过多`，重则账号异常，被封。造成的影响就是: 1. 轻则12-24小时无法下单操作 2. 重则被封，可能需要注销重新注册(但当天仍不可) 因此: 1. 无论何种抢菜项目都不可长时间运行，也不可短时间多次运行 2. 少用，一用就中最好了

> > @a180285 我会不断维护这个项目，但其实目前无论怎么改都难逃风控(都是治标不治本的策略)。也有根治的方案，这个和@Runc2333 讨论过，但是对我本人而言，一方面需要消耗我个人精力较多，另一方面对用户的安全隐患较大。 > > 你说的根治的方案，该不会是在服务器端做签名吧。如果是这样，感觉问题就复杂了，这样等于是提供了一个服务，不知道会不会有其他影响，比如细究法律的话。我觉得如果是的话，可以咨询一下相关从业人员。 不讨论这些细节，一个开源抢菜如果做到了那样，已经失去了开源的实际意义了，而且带来的风险巨大。