如果想跟踪最新资讯可以关注我的推特：@airdorp_cmd

我会保持，日—周—月三个级别的不同题材更新。

喜欢的可以点赞转发，也欢迎大家一起交流学习：TG社区

从脚本的角度看，我们知道，常见的女巫方式有以下几种：

• 重放：重复发送或者是复制发送，相同的内容

• 输入错误：输入的信息错误

• 交互逻辑：正常的用户交互逻辑顺序问题

• 权限过度使用：非正常接口调用权限过度使用

按照以上的逻辑我们归结一下几点来充分说明：

一、交互顺序问题

交互顺序逻辑，我们举一个简单的例子来说明。

对于有DID认证权限的项目来说，我们要做的顺序是先去请求对应的DID权限，然后再去请求对应的交互逻辑接口。

这里有一个问题，正常情况下，我们一般是先知道接口再去写交互脚本的，这时候我们一般是知道有了DID权限之后，我们需要请求哪些接口来完成任务。正常的顺序是：

a、请求DID身份认证信息。

b、完成交互任务

但是，很多时候，很多脚本的请求顺序是，直接去交互任务，这时候就会越权请求对应的任务接口，返回错误信息之后通过判断没有权限然后再去请求对应的DID身份认证信息，再去进行任务交互。

这种逻辑正确吗？

好像没什么问题，但是如果前端接口进行了埋点记录，这就是一种女巫行为，因为正常的前端操作是不可能先去做任务再去请求DID的，没有认证信息之前，任务按钮一般都是灰色的或者是不显示的。只有通过脚本才能进行调用。

二、越权调用或接口过度使用

越权其实通过上述案例启示可以很容易理解，就是非认证权限下调用下层接口。

这就会让前端埋点被动记录。

接口过度使用其实也很容易理解。

举一个简单的例子。

对于常规任务的先后顺序不论是后端接口还是前端交互界面，一般都是有一个全局变量来控制的。

对于一系列连续的交互任务来说，我们的逻辑顺序是，一件一件按次序的完成，然后再和全局接口进行比对校验，其实每一次的交互都会有对应的返回值，这也是可以作为全局判断的依据。

不可行也是不可取的是，每次交互都是请求全局状态认证进行校验。

比如：用户任务状态接口是

https://xxx.com/user/config

请求任务接口为：

https://xxx.com/user/task1
https://xxx.com/user/task2
https://xxx.com/user/task3

常规的开发逻辑应该是：全局config是一个用户状态维护，不同任务接口是局部接口的任务状态维护，完成对应的任务都会有对应的返回值返回回来。

如果按照，每完成一个任务就去请求一下config接口来进行校验任务状态，这其实就属于过度请求。常规的产品中，除非了用户刷新和用户主动更新，是不会频繁请求config接口的，这气势就是一个隐患，一定会有吗？不一定，但是一旦有就100%女巫。

以上均是站在严格女巫的角度来做的接口调用方面的逻辑顺序树立，并不一定适合所有项目，但是如果能避免就尽量避免这些不必要的麻烦。

毕竟当下的交互成本并不低，所以尽可能的规避不必要的风险。

因为web3当前处于一个很早起的阶段，项目周期也很短，开发周期更短，以上说的内容并不能代表所有的项目配置，但这一定是趋势。随着更多的web2开发着参与进来，我想web2的防范水平也很快会普及到web3中，这只是时间问题。

如果你想获得更多web3脚本交互信息可以关注我的推特，或者订阅

我们会持续保持更新，让健康的交互成为更多人可以做的事情。