更新风控策略多久可以上线呢？ about dingdong-grabber

[ahutsunshine]

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

[ahutsunshine]

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

[w65467991]

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

辛苦了·加油！！

[MataSong]

辛苦了 大神，你的签名服务器是不是宕机了？

[ahutsunshine]

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

[MataSong]

@ahutsunshine 好的，辛苦大神了。

[a180285]

求更新，虽然现在有所好转，但也不知道什么时候是个头啊。感觉叮咚感觉还是比小区团购靠谱一点

[a180285]

还是希望有一个在维护的版本

[ahutsunshine]

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

[a180285]

对了，想具体了解一下，你这里说的“风控”，具体指什么呢。

• 是指代码层面的，比如有人看到代码后对 repo 下手，
• 还是这个 repo 用的人太多导致 dingdong 最后改算法。
• 还是用户用这个 repo 后导致的单个账号被风控封号。

目前最担心的是哪一方面呢

[a180285]

另外，看到更新就放心多了。感谢感谢

[ahutsunshine]

风控的策略有很多，我举几个例子：

1. 当模拟请求时，由于参数很多，请求只会把必要的参数带上，但有些是基于规则生成的字符串比如device_token等，如果不是 通过逆向工程看到别人的实现，我们是不知道如何生成的，要么忽略要么随意填写，这样叮咚风控就很容易发现这些是非法的，不是从app里请求出去。
2. 即使我们可以拿到所有的参数造成和从app里发出的请求一样，但是叮咚会每隔一定时间扫描计算这个人在这段时间请求路径或次数是不是合法，一旦发现这段时间内请求过多，就会被判定是非法遭到风控。

遭到风控的账号轻则出现405或者同一时间下单人数过多，重则账号异常，被封。造成的影响就是:

1. 轻则12-24小时无法下单操作
2. 重则被封，可能需要注销重新注册(但当天仍不可)

因此:

1. 无论何种抢菜项目都不可长时间运行，也不可短时间多次运行
2. 少用，一用就中最好了

[a180285]

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

你说的根治的方案，该不会是在服务器端做签名吧。如果是这样，感觉问题就复杂了，这样等于是提供了一个服务，不知道会不会有其他影响，比如细究法律的话。我觉得如果是的话，可以咨询一下相关从业人员。

[a180285]

风控的策略有很多，我举几个例子：

1. 当模拟请求时，由于参数很多，请求只会把必要的参数带上，但有些是基于规则生成的字符串比如device_token等，如果不是 通过逆向工程看到别人的实现，我们是不知道如何生成的，要么忽略要么随意填写，这样叮咚风控就很容易发现这些是非法的，不是从app里请求出去。
2. 即使我们可以拿到所有的参数造成和从app里发出的请求一样，但是叮咚会每隔一定时间扫描计算这个人在这段时间请求路径或次数是不是合法，一旦发现这段时间内请求过多，就会被判定是非法遭到风控。

嗯，如果是因为开头的第二点，长时间使用被人工分析导致账号被风控，这个确实很难办，也许从代码的角度，只能做到告知与提醒了。

我个人还是很希望能通过技术的方式，能解决掉开头第一个问题，这样就已经很欣慰了。

[ahutsunshine]

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

你说的根治的方案，该不会是在服务器端做签名吧。如果是这样，感觉问题就复杂了，这样等于是提供了一个服务，不知道会不会有其他影响，比如细究法律的话。我觉得如果是的话，可以咨询一下相关从业人员。

不讨论这些细节，一个开源抢菜如果做到了那样，已经失去了开源的实际意义了，而且带来的风险巨大。

[ahutsunshine]

风控的策略有很多，我举几个例子：

1. 当模拟请求时，由于参数很多，请求只会把必要的参数带上，但有些是基于规则生成的字符串比如device_token等，如果不是 通过逆向工程看到别人的实现，我们是不知道如何生成的，要么忽略要么随意填写，这样叮咚风控就很容易发现这些是非法的，不是从app里请求出去。
2. 即使我们可以拿到所有的参数造成和从app里发出的请求一样，但是叮咚会每隔一定时间扫描计算这个人在这段时间请求路径或次数是不是合法，一旦发现这段时间内请求过多，就会被判定是非法遭到风控。

嗯，如果是因为开头的第二点，长时间使用被人工分析导致账号被风控，这个确实很难办，也许从代码的角度，只能做到告知与提醒了。

我个人还是很希望能通过技术的方式，能解决掉开头第一个问题，这样就已经很欣慰了。

第一点可以做到，ios已经有方案了。android其实要是有人一起合作的人应该也是可以的，需要大家一起啊，光靠我一个 ，我也不是啥都会😅

[a180285]

不过， Android 和 ios 的请求居然不一样，这个是完全没有想到的。希望有人能帮上忙吧。我个人的话，以前是做服务器的，客户端这一块确实比较欠缺，能帮忙的有限了。顶多也就会抓抓包，不过好像用不上😅

[ahutsunshine]

android，ios，小程序，三个不同的团队，使用不同的请求参数或者签名算法也可以理解。

[a180285]

客户端三个团队，也是可以理解的，但服务端也三个团队的话，这个我确实不是很理解。因为如果大家都是走 HTTP 的话，完全分开写三套，这个确实比较浪费啊。

[yyfcss]

客户端三个团队，也是可以理解的，但服务端也三个团队的话，这个我确实不是很理解。因为如果大家都是走 HTTP 的话，完全分开写三套，这个确实比较浪费啊。

就是不同设备调不同签名算法校验函数的事情，又不是整套代码都要不一样，为了风控还是很值得的