[Share] What should I do if I need to log in first when using ApiPost to test the interface (based on cookies)?

Posted May 25, 20203 min read

When developing and debugging interfaces in the background, you often encounter interfaces that require login to request.

For example:to obtain the favorite list of the logged-in user, at this time, we need to simulate the login status to debug the interface. As shown:

What about the interface that needs to be logged in when using ApiPost to test the interface(based on cookies)?

Today, we explain the use of ApiPost's environment variables to solve this interface dependency that requires logging in and requesting.

About ApiPost:

ApiPost is an API debugging and management tool that supports team collaboration and can directly generate documents. It supports simulating common requests such as POST, GET, PUT, etc. It is a rare tool for background interface developers or front-end and interface testers.

Download address: https://www.apipost.cn/download.html

ApiPost provides 2 solutions:

Option I, enable global cookies

apipost provides the function to enable global cookies. The opening path is as follows:

What about the interface that needs to be logged in when using ApiPost to test the interface(based on cookies)?

After opening, after we request to log in to the interface, the subsequent interfaces will share the "logged in" state, that is, the cookie returned by the login interface is shared.

As follows:

Step 1:Request login interface

What about the interface that needs to be logged in when using ApiPost to test the interface(based on cookies)?

The second step:access to other interfaces, you are in the login state

What about the interface that needs to be logged in when using ApiPost to test the interface(based on cookies)?

\ []( https://www.apipost.cn/#downl ... )

Scheme II, using environment variables, first request the login interface, and then request the subsequent interface

This solution is for the situation where the global cookie function is turned off.

  1. First request the login interface:

In order to be in the login state, you need to request the login interface first. The purpose of this move is to simulate the user's login behavior and obtain the required login parameters(in this case, cookies).

Set the PHPSESSID returned by the login interface(this is SessionID, PHPSESSID is the SessionID variable name for PHP as the backend interface, and the variable name in other languages may be different) as an environment variable.

What about the interface that needs to be logged in when using ApiPost to test the interface(based on cookies)?

  1. Then return to the collection interface, go to the header option, select cookie for the parameter value, and input the parameter value:PHPSESSID = {{login \ _var}}.

This is to forge the PHPSESSID of the request using the cookie returned by the login interface.

As shown:

What about the interface that needs to be logged in when using ApiPost to test the interface(based on cookies)?

Or you can also define a global header so that you do n t have to set each interface again:

What about the interface that needs to be logged in when using ApiPost to test the interface(based on cookies)?

What about the interface that needs to be logged in when using ApiPost to test the interface(based on cookies)?

  1. Next send, you can see my favorite list.

principle:

Use ApiPost to send cookies to enable the server to recognize the cookies of the logged-in user.

Related recommendation: Definition and use of variables of ApiPost