乐趣区

关于前端:如何请求一个需要登陆才能访问的接口基于cookieapipost

在后盾在开发、调试接口时,经常会遇到须要登陆能力申请的接口。

比方:获取登陆用户的珍藏列表,此时,咱们就须要模仿登陆状态进行接口调试了。如图:

明天,咱们解说利用 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。

退出移动版