http探测中用户验证与post表单用户验证的区别和拨测模拟方式

HTTP Basic Auth（基本认证）

• 是 HTTP 协议内置的标准认证机制。

• 客户端在每一次请求中，都必须在 HTTP 请求头（Header）中携带 Authorization: Basic <base64编码的用户名:密码>。

• 服务器每次独立验证该凭据，无状态，不依赖会话。

• 没有“登录”动作——只要有有效凭据，就能访问资源。

通过 POST 表单提交用户名密码

• 是应用层自定义的认证流程。

• 用户先向登录接口（如 /login）发送一个 POST 请求，凭据放在请求体中（如 username=admin&password=123）。

• 服务器验证成功后，通常通过 Set-Cookie 返回一个会话 ID（如 sessionid=abc123）。

• 后续请求靠这个会话 ID（通常在 Cookie 中）证明身份，不再传输原始密码。

• 整个过程是有状态的，依赖服务器端的会话管理。

模拟 HTTP Basic Auth

只需一条命令，直接访问受保护资源，并在 Header 中提供凭据。

# 方法一：使用 -u 参数（curl 自动做 Base64 编码）
curl -u username:password https://example.com/protected
# 方法二：手动构造 Authorization 头
curl -H "Authorization: Basic $(echo -n 'username:password' | base64)" \
     https://example.com/protected

注意：每访问一个受保护接口，都需要重复带上 -u 或 Authorization 头。不需要额外的“登录”请求。

模拟 POST 表单登录

1. 先登录获取会话，提交登录表单（POST 请求）。

   curl -X POST https://example.com/login \
        -d "username=admin&password=secret" \
        -c cookies.txt

   • -d 指定表单数据（默认 Content-Type 为 application/x-www-form-urlencoded）。

   • -c cookies.txt 将服务器返回的 Cookie（如 sessionid）保存到文件。

2. 使用会话 Cookie 访问受保护页面。

   curl https://example.com/dashboard \
        -b cookies.txt

   • -b cookies.txt 表示从文件中读取 Cookie 并随请求发送。

   • 此时请求中不再包含用户名和密码，仅靠会话 ID 验证身份。

   如果跳过第一步直接访问 /dashboard，通常会失败（重定向到登录页或返回 403）。
   登录是一次性的，后续所有请求复用同一个会话（直到过期或登出）。

通过 HTTP 请求（云监控拨测）模拟的区别

模拟 HTTP Basic Auth

参考下图创建任务。

模拟 POST 表单登录

模拟单步登录请求

如果只是模拟单步登录请求，可以创建单步拨测任务，选择POST类型的请求，并输入对应的表单类型和对应的请求内容，如下：

多步探测

如果是要模拟登录和登录后的会话API请求操作，可以使用多步探测。

1. 创建多步探测。

2. 创建第一步的请求，通过表单提交用户名密码登录，并设置Cookie提取。

3. 创建第二步的请求，登录后的会话操作，如查询登录后对应的id的资源列表。需勾选自动设置cookie，以使用上一步登录返回的cookie，进行后续免登录的持续操作。