HuangWei
HuangWei
求更新，虽然现在有所好转，但也不知道什么时候是个头啊。感觉叮咚感觉还是比小区团购靠谱一点
还是希望有一个在维护的版本
对了，想具体了解一下，你这里说的“风控”，具体指什么呢。 * 是指代码层面的，比如有人看到代码后对 repo 下手， * 还是这个 repo 用的人太多导致 dingdong 最后改算法。 * 还是用户用这个 repo 后导致的单个账号被风控封号。 目前最担心的是哪一方面呢
另外，看到更新就放心多了。感谢感谢
> @a180285 我会不断维护这个项目，但其实目前无论怎么改都难逃风控(都是治标不治本的策略)。也有根治的方案，这个和@Runc2333 讨论过，但是对我本人而言，一方面需要消耗我个人精力较多，另一方面对用户的安全隐患较大。 你说的根治的方案，该不会是在服务器端做签名吧。如果是这样，感觉问题就复杂了，这样等于是提供了一个服务，不知道会不会有其他影响，比如细究法律的话。我觉得如果是的话，可以咨询一下相关从业人员。
> 风控的策略有很多，我举几个例子： > > 1. 当模拟请求时，由于参数很多，请求只会把必要的参数带上，但有些是基于规则生成的字符串比如`device_token`等，如果不是 通过逆向工程看到别人的实现，我们是不知道如何生成的，要么忽略要么随意填写，这样叮咚风控就很容易发现这些是非法的，不是从app里请求出去。 > 2. 即使我们可以拿到所有的参数造成和从app里发出的请求一样，但是叮咚会每隔一定时间扫描计算这个人在这段时间请求路径或次数是不是合法，一旦发现这段时间内请求过多，就会被判定是非法遭到风控。 嗯，如果是因为开头的第二点，长时间使用被人工分析导致账号被风控，这个确实很难办，也许从代码的角度，只能做到告知与提醒了。 我个人还是很希望能通过技术的方式，能解决掉开头第一个问题，这样就已经很欣慰了。
不过， Android 和 ios 的请求居然不一样，这个是完全没有想到的。希望有人能帮上忙吧。我个人的话，以前是做服务器的，客户端这一块确实比较欠缺，能帮忙的有限了。顶多也就会抓抓包，不过好像用不上😅
客户端三个团队，也是可以理解的，但服务端也三个团队的话，这个我确实不是很理解。因为如果大家都是走 HTTP 的话，完全分开写三套，这个确实比较浪费啊。
我在想，如果是为了隐藏代码，也可以考虑将算法打包为 dll / lib ，只是工作量相对是会大一些，并且需要兼容各种系统，有条件的话，还可以对 dll 进行混淆，甚至在 dll 加时间戳限制。这样对具体代码的保护性，也可以有所提高。也不需要一定从服务器下载源码。