共计 799 个字符，预计需要花费 2 分钟才能阅读完成。
在后盾在开发、调试接口时，经常会遇到须要登陆能力申请的接口。
比方：获取登陆用户的珍藏列表，此时，咱们就须要模仿登陆状态进行接口调试了。如图：
明天，咱们解说利用 ApiPost 的环境变量，解决这种须要先登录再申请的接口依赖状况。
ApiPost 提供了 2 种计划：
计划 I、开启全局 cookie
apipost 提供了开启全局 cookie 的性能。开启门路如下：
右下角 Cookie 管理器 - 关上全局 Cookie 按钮
开启后，咱们申请登陆接口后，后续接口都会共享“已登陆”的状态，即共享了登陆接口返回的 cookie。
如下所示：
第一步：申请登陆接口
第二步：拜访其余接口，则都处于了登陆状态
计划 II、利用环境变量，先申请登陆接口，再申请后续接口
这种计划是针对 敞开了 全局 cookie 性能的状况。
1、申请登陆接口，将响应 COOKIE 赋值给变量：
为了处于登陆态，须要先申请登陆接口，此举目标是为了模仿用户的登陆行为，获取须要的登陆参数（这里是 Cookie）。
将登陆接口返回的 PHPSESSID（这个是 SessionID，PHPSESSID 是针对 PHP 作为后端接口的 SessionID 变量名，其余语言的变量名可能不同）设为环境变量。
apt.variables.set("login_var", response.cookies["PHPSESSID"]);
注：更多响应后果绑定变量能够参考“响应以及断言”一节和“后执行脚本”一节。
2、调用变量，手动给 header 增加 Cookie 参数
接着返回珍藏接口，进到 header 选项，参数值抉择 cookie，参数值输出：PHPSESSID={{login_var}}。
此举是为了利用登陆接口返回的 Cookie 伪造申请的 PHPSESSID。
如图：
或者你也能够定义个全局 header，这样就不必每个接口都设置一遍了：
登录实现原理
利用 ApiPost 发送 Cookie，使服务器辨认已登录用户的 Cookie。
正文完
