Automatic_ticket_purchase
Automatic_ticket_purchase copied to clipboard
MakiNaruto
'RGV587_ERROR::SM::哎哟喂,被挤爆啦,请稍后重试'
问题描述: buy_status = json.loads(response.text) 请求下单接口的时候返回:（非热门票测试） {'ret': ['FAIL_SYS_USER_VALIDATE', 'RGV587_ERROR::SM::哎哟喂,被挤爆啦,请稍后重试'], 'data': {'url': 'https://buy.damai.cn:443//multi/trans/createOrder/tmd/punish?x5secdata=xb56c99d1179f379b61ba303bb8ec2a5d51657274589a-717315356a1926515014aaaac2dj176370006a__bx__buy.damai.cn%3A443%2Fmulti%2Ftrans%2FcreateOrder&x5step=2'}}
简单的尝试: 1.过了一个时间段，删除cookie重试了大概2~3次，返回失败 2.切换一个账号，返回失败 3.尝试提交订单时使用 移动端的ua ,返回失败
复现: 貌似在pc端，提交下单按钮的时候会出现一个滑动验证框（chromedriver 必现，chrome滑动验证过后下次不再出现）
想请教大佬这样的情况该怎么避免呢，因为感觉是直接请求购票接口，貌似没有使用类似selenuim的点击不会提示操作频繁。亦或是我这个ip被关进小黑屋（之前有selenium抢告五人的经历）
最近比较忙，抽空看了下，在step3提交时的参数和页面提交时有区别，多了两个参数，[bx-ua，bx-umidtoken]。这个是之前没有的，获取方式暂时未能搜寻到。有可能是由于该参数导致的，待验证。 { "hierarchy": ..., "data": ..., "linkage": ..., "feature": ..., "endpoint": ..., "bx-ua": ..., "bx-umidtoken": ... }
最近比较忙，抽空看了下，在step3提交时的参数和页面提交时有区别，多了两个参数，[bx-ua，bx-umidtoken]。这个是之前没有的，获取方式暂时未能搜寻到。有可能是由于该参数导致的，待验证。 { "hierarchy": ..., "data": ..., "linkage": ..., "feature": ..., "endpoint": ..., "bx-ua": ..., "bx-umidtoken": ... }
和这两个应该没啥太大关系，bx-ua是通过一个链接拿到的，第一次访问会存进cookie和session，有效期内后面就是同一个
bx-umidtoken也是类似，就调js里面的一个函数拿到
但是实际上，调试过程中超时了 拿不到具体的值也不影响订单的生成，下面是获取这两个失败的情况 订单还是提交成功了
优酷也有这个请求头，这个是阿里系的加密参数，有说那两个加密参数是明文的时候也请求成功了那是因为你手动过了滑块或者其他的导致你的cookie过了风控了，你看下你的cookie应该是有一个加密的cookie是滑块那个的，跟一般的不一样，有思路的私信我下一起沟通下
哎呦诶，被挤爆啦，请稍后重试 缺少bx-ua的header头信息 在登陆和解密页面需要加载js sdk
确认sec-min.js放到header最前面，提前加载，预计需要300ms-500ms内初始化完成。确保在sec-min.js加载完成后再发起调用
如果上述步骤都确认过header投还是没有出现bx-ua的信息，可能存在的情况: 1.排查公司内部是否有通用组件对header头进行过滤
哎呦诶，被挤爆啦，请稍后重试 缺少bx-ua的header头信息 在登陆和解密页面需要加载js sdk
确认sec-min.js放到header最前面，提前加载，预计需要300ms-500ms内初始化完成。确保在sec-min.js加载完成后再发起调用
如果上述步骤都确认过header投还是没有出现bx-ua的信息，可能存在的情况: 1.排查公司内部是否有通用组件对header头进行过滤
现在应该是又改了，根据你的提示，我找到了 ua 和 token 的生成方式，有兴趣聊下吗
