本文共 2341 字，大约阅读时间需要 7 分钟。

这家接口的防爬策略太可怕了。

1.签名尝试出错两次，直接封杀ip。甚至我4G的ip都给封了。 2. 访问次数，达到100次也会被封杀ip.

看来是我没有重视这个对手，give you some color see see，看来我要赤膊上阵了。

/n0/home/posts/recommend

url params start=10&timestamp=1587096670288&sign=a514ae100ac2952c23e65f76aef71df690977d28 start 数字,代表当前第几页 timestamp = Date.now() 关键就看sign怎么生产，也就是要通过js反向推算出生成sign的方法

打断点

t和e的值

功夫不负苦心人，通过sign这个关键字，我还是找到了突破口

timestamp = Date.now() sign = Vo(t.params)

Mo在这里

function Mo(t) {               for (var e = 1; e < arguments.length; e++) {                   var n = null != arguments[e] ? arguments[e] : {   };                e % 2 ? No(n, !0).forEach(function(e) {                       Object(s.a)(t, e, n[e])                }) : Object.getOwnPropertyDescriptors ? Object.defineProperties(t, Object.getOwnPropertyDescriptors(n)) : No(n).forEach(function(e) {                       Object.defineProperty(t, e, Object.getOwnPropertyDescriptor(n, e))                })            }            return t        }

接下来就看Vo是什么

{"start":80, "timestamp":1587101418832}["start=80", "timestamp=1587101418832"]

然后做一个hash

对应的解析成python代码，太完美了，太爽了。

---

接口响应里面也使用了，这个是和ip关联的

x-ratelimit-limit: 10000 x-ratelimit-remaining: 9681

根据我探测到的信息句子控内部使用了kong作为网关

{   "Content-Type": "application/json", "Transfer-Encoding": "chunked", "Connection": "keep-alive", "Server": "nginx/1.10.3 (Ubuntu)", "Cache-Control": "no-cache, private", "Date": "Fri, 17 Apr 2020 07:15:36 GMT", "X-RateLimit-Limit": "10000", "X-RateLimit-Remaining": "9702", "Access-Control-Allow-Origin": "https://www.juzikong.com", "Vary": "Origin", "Access-Control-Allow-Credentials": "true", "X-Kong-Upstream-Latency": "559", "X-Kong-Proxy-Latency": "0", "Via": "kong/1.4.0"}

{   "Content-Type": "application/json", "Transfer-Encoding": "chunked", "Connection": "keep-alive", "Server": "nginx/1.10.3 (Ubuntu)", "Cache-Control": "no-cache, private", "Date": "Fri, 17 Apr 2020 07:15:37 GMT", "Access-Control-Allow-Origin": "https://www.juzikong.com", "Vary": "Origin", "Access-Control-Allow-Credentials": "true", "X-Kong-Upstream-Latency": "147", "X-Kong-Proxy-Latency": "0", "Via": "kong/1.4.0"}

为什么使用kong作为网关？

传统型的先访问api,然后在api里面进行限流，速率控制，这样存在问题就是大量重复工作，例如daijingi款产品防止刷单的做法就是这对下单接口做了处理。可后来登陆接口也被人刷了，然后又针对登陆接口进行了频率的限制。 kong可以把网关做到api的前面，这样的话可以让业务开发者不需要关心网关层次的东东，只需要去写业务就好了。

kong

jwt dubbo mq k8s 是不是意味着很容易就可以作出能够承担大量用户系统来呢？ 但有一个问题就是用户为什么要用你？能够做im的太多了，但用户只用腾讯家的啊。