本主题解释了使用 HTTP 1.0 和 所选定支持工具和提供操作工具的配置选项。

本章包含：

配置 HTTP 1.0 设置

选择 HTTP 1.0 作为传输协议时，可以指定是否希望客户端请求使用 Keep-Alive 连接（NTLM 和 Digest HTTP 身份验证所需）。它也重复用于 GUI 或命令行中单个测试套件的调用。从合适工具的 Transport 选项卡中，您可以向 SOAP 请求添加、修改和删除自定义 HTTP 数据头。

• General

• URL Parameters （仅针对消息传递客户机）

• Security

• HTTP Headers

• Cookies

General

General 页面选项包括：

• Router Endpoint: 指定服务所需的端点 URL 默认情况下，SOAP 客户端端点设置为 WSDL中定义的端点。除了 WSDL，还有三个端点选项：

• SOAP Action：指定服务器如何处理请求。如果选择了 Constrain to WSDL 多选框，则该选项是禁用的。仅针对 SOAP 客户端。

• Method：指定使用哪个方法来处理请求。如果选择了 Constrain to WSDL 多选框，则该选项是禁用的。 要调用的方法可以指定为一个固定值、参数化值或脚本化值。有关参数化值的更多详情，

  查阅 使用数据源、变量或来自其他测试的值对测试进行参数化 和 使用数据源值、变量和提取的值参数化工具。

  对于固定值，可以使用 ${var_name} 语法访问数据源值。也可以使用指定的环境变量。有关环境的更多详情，请查阅 在不同的环境中配置测试 和 配置虚拟化环境。

  有关脚本值的更多详情，请查阅 Extensibility and Scripting Basics。

• Message Exchange Pattern: Expect Synchronous Response: 指定是否需要响应主体。  始终希望 HTTP 响应头。  如果未选择该选项，则产品将发送单向消息并等待通知头（通常为 "HTTP/1.0 202 Accepted”）。
  
  

• Connection Settings: 指定所选传输协议的保持连接或关闭连接。
  • Keep-Alive connection: 添加一个 "Connection: Keep-Alive” 数据头，在服务器支持的情况下请求保持连接。这对于 NTLM 和 Digest HTTP 身份验证是必需的。
  • Close connection (default): 不输出额外的 HTTP 头，并执行常规的 HTTP 1.0 交换。这是 HTTP 1.0 的默认行为。

• Redirect Settings (for messaging clients only—e.g., REST, SOAP, Messaging, EDI clients): 指定是否自动遵从 HTTP 重定向。如果希望在原始请求/响应流量上执行操作或验证（代替只使用最终的请求/响应对），禁用该选项。
     
• Compression Settings (for messaging clients only—e.g., REST, SOAP, Messaging, EDI clients): 指定是否研所请求和解压响应。
  • Gzip request payload: Gzips 通过网络发送的请求有效负载。将不会被压缩发送到附加工具的数据。注意，压缩不不适用于配置来发送附件或 MTOM 模式的 SOAP 客户端。
  • Decompress gzip-encoded response payload: 解压将 "Content-Encoding: gzip” 作为数据头字段的响应负载。附加工具将接收未压缩的数据。

URL Parameters 

URL Parameters 页面 选项包含：

• URL Parameters：允许向 GET 请求的 URL 中添加参数。单击 Add 按钮后，可以在打开的对话框中指定 Parameters/Value 对。如果数据源可用，还可以对值进行参数化。

Security

Security> Client side SSL 页面选项包括：

• Use Client Key Store：指定用来与服务器完成握手的密匙库。

Security> HTTP Authentication 页面选项包括：

• Use Client Key Store: 若要设置基本的、NTLM、Digest 或 Kerberos 身份验证，请选择 Perform Authentication 多选框，然后从 Type 下拉列表中选择 Basic, NTLM, Kerberos ，或 Digest 。
  
  • 对于 Basic, NTLM, 或 Digest，则输入验证请求的 Username 和 Password 。
  • 对于 Kerberos，则输入验证请求的 Service Principal 。如果未使用正确的用户名和密码，或者没有使用正确的服务主体，则不会对请求进行身份验证。
• Use Global Preferences: 作为一种选择，如果在安全首选项中设置了全局 HTTP 身份验证属性，则可以选择 Use Global Preferences 。  有关更多信息，请查阅 安全设置。

Security> OAuth Authentication 页面选项包括：

• Perform Authentication: 启用该选项，表示应该执行 OAuth Authentication。身份验证字段包含将添加到 HTTP 数据头的 Oauth 特定信息。
• Consumer Key 和 Secret Configuration：Consumer Key 和 Consumer Secret 都是客户端用来与服务器验证自身的凭证。对于每个使用 Consumer Key 的客户端来说，它都是唯一的。所有步骤都要求这两个配置。
• OAuth Authentication Mode: 指定要执行 Oauth 场景的哪个步骤。
  • Obtain Request Token: 从使用 Consumer Key 和 Secret 的服务器中请求请求令牌。
  • Scope: 限制可以访问哪些信息。该信息嵌入到消费者密钥（Consumer Key）中。
  • Exchange Request Token for Access Token: 交换请求令牌和访问令牌的验证代码。
• Request Token: 指定从服务器获得的临时请求令牌凭证（用于访问令牌交换）。
• Request Token Secret: 指定从服务器获得的临时请求令牌凭证（用于访问令牌交换）。
• Verification Code: 指定服务器提供的验证代码；这将确认资源所有者将授予权限。
  • Sign Request for OAuth Authentication: 使用特定的访问令牌和访问令牌的秘密。以获得访问用户私有资源的权限。
• Oauth Parameters：允许在 Oauth 令牌上指定其他参数。例如，时间戳和 nonce。

有关使用 Oauth 授权的更多详情，请查阅 Using OAuth Authentication。

HTTP Headers

HTTP Headers 页面选项包括：

• Add：单击该选项以添加自定义 HTTP 数据头。数据头名称不分区大小写。
• Modify：单击该选项以修改所选定的 HTTP 数据头。将显示一个对话框，允许修改数据头的名称和值。如果工具正在使用数据源，则数据头的值可以被其他数据源访问。
• Remove：单击该选项以删除所选定的 HTTP 数据头。

这些控件用于覆盖 header 字段。例如，可以通过这些控件指定所需名称和值来覆盖 Content-Type header 字段。 

默认情况下添加的以下 header 字段可以通过这些 UI 控件覆盖。

Host

该值将包含来自 HTTP 端点或资源 URL 的主机名和端口号。

Content-Type

输出消息的媒体类型。只在输出消息包含 HTTP 控制的主体时，才可发送该数据头。  发送主体的有 POST, PUT, 和 DELETE 方法，而没有 GET, OPTIONS, HEAD, 或 TRACE 方法。

默认值由发送的消息类型确定。SOAP 消息的内容类型根据 SOAP 版本变化而变化，SOAP 1.1 是 "text/xml" ，SOAP 1.2 是 "application/soap+xml"。其他 XML 消息默认使用 "text/xml"。JSON 消息将使用 "application/json"。使用表视图配置的消息将使用 "application/x-www-form-urlencoded"。使用 MIME 附件发送的消息将包含带 "start" 和 "boundary” 参数的 "multipart” 内容类型。属于 EDI、固定长度、CSV 或自定义消息格式的消息将具有消息格式的媒体类型。

Content-Length

输出消息的大小（以字节为单位）。

下面的 HTTP 数据头是有条件地进行配置的。它们是在该表之外配置的，或者具有必须动态生成的值。

SOAPAction

该 HTTP 数据头仅在 SOAP 1.1 时才发送。设置在常规（General）页面的 SOAPAction 字段中。

Authorization

该数据头根据 HTTP 身份验证和首选项（在 Security> HTTP Authentication and Oauth 下）中特定的 Oauth 设置自动构建。NTLM、Digest 和 Kerberos 身份验证的值将根据不同要素（包括动态生成的挑战响应和安全令牌）而不同。 

Connection

如果启用了 Keep-Alive connection ，则该数据头会被添加到消息中，并使其值为 Keep-Alive 。如果启用了 Close connection ，将不会发送该数据头（默认选项）。对于 NTLM 和 Digest HTTP 身份验证，必须启用 Keep-Alive。

Proxy-Authorization

该数据头根据首选项中的代理身份验证设置以及服务器是否指示需要代理身份验证构建。

Cookies

Cookies 页面选项包括：

• Reset existing cookies before sending request: 允许清除当前会话，以便下一个 HTTP 调用启动一个新会话。

使用 Oauth 身份验证

Parasoft 同时支持 OAuth 1.0a 和 2.0 安全协议，用于 Web 服务器流和客户端凭证流（两个场景）。Oauth 身份验证可以配置为 HTTP 1.0/HTTP 1.1 传输。

对于 REST 客户机，它是在 HTTP Options 选项卡下配置的。对于消息传递客户机，它是在 Transport 选项卡下配置的。

关于 OAuth

OAuth（打开授权）是一个身份验证协议，给用户提供了一个方法，该方法授权第三方应用程序在不需要登录凭证的情况下访问其私有资源。还提供了一个限制可访问信息数量的方法。该协议用于处理暴露给第三方应用程序的登录凭证。

OAuth 基于传统的 C/S 身份验证模型，但是引入了到该模型的第三方：用户（也称为资源所有者）。在传统的 C/S 身份验证模型中，客户端直接访问服务器承载的资源。在 OAuth 模型中，客户端必须获得资源所有者的权限之后才能访问服务器的资源。此权限以令牌和匹配共享密钥的形式表示。

例如，假设用户（资源所有者）希望授权打印服务（客户端）访问其存储在照片共享服务（服务端）的私有图片。代替向打印服务显示用户的登录凭证，用户可以直接执行 Oauth 身份验证以获得访问其私有图片的打印服务权限。 

这将分三个阶段进行：

1. 打印服务要求图片共享服务的临时凭证。
2. 一旦打印服务收到了凭证，它将把用户重定向到图片共享服务的 Oauth 授权 URL，然后用户提供登录凭证。注意，这个阶段的打印服务对用户登录凭证不可见。一旦用户决定让打印服务访问私有图片，将生成一个确认验证。
3. 然后打印服务交换临时凭证和访问令牌的验证代码。一旦打印服务有了访问令牌，则便可从图片共享服务中获得用户的私有图片。

使用 OAuth 1.0a

使用 OAuth 1.0a 涉及以下常规步骤：

1. 从服务提供程序中获取并授权请求令牌
2. 交换访问令牌的请求令牌
3. 签名 Oauth 请求访问受保护的资源

以下示例使用 REST 客户端向服务器发送请求消息。注意，消息传递客户端可以以相同方式使用 Oauth 1.0a。

从服务提供程序中获取并授权请求令牌 

1. 创建新的 REST 客户机并配置包含请求令牌的位置
2. 在 HTTP Options 选项卡中，选择 HTTP 1.0 或 HTTP 1.1，并通过选中 Perform Authentication启用 OAuth 身份验证。这将允许启用完成 OAuth 身份验证的其他字段。
3. 在 Consumer Key 和 Consumer Secret下，添加键和密匙。
4. 为 OAuth Mode选择 Obtain Request Token 。
5. （可选项）在 Scope 字段中提供范围。
6. （可选项）在 OAuth Parameters下添加额外的 OAuth 参数。
   
   
   
   
7. 将文本数据库附加到 REST 客户端的响应流量中，并从中提取请求令牌（通常表现为 oauth_token 和请求令牌机密。
   
   
   
   
8. 创建新的 Web 浏览器记录在 Start Recording From 字段下，输入 URL 以获得验证代码（这一步将用户重定向以提供登录到服务器的登录凭证）。URL 应该包含一个 oauth_token 参数；使用上一步骤中请求令牌所包含的值。
   
   
   
   一旦浏览器启动了，它将显示托管受保护资源的服务器的登录页面。 
9. 通过提供用户的登录凭证（用户名/密码）来登录。一旦获得授权，浏览器将把您重定向到一个带验证密码的新页面。
10. 看到验证代码之后，关闭浏览器退出记录。
11. 将浏览器数据库附加到浏览器内容（HTML 呈现），并提取验证代码的值。
12. 打开浏览器回放工具，使用“文本数据库（第 7 步骤生成的请求令牌数据域列代替文本请求令牌字符串。使用 ${varName} 语法，如下所示。
    
    

将请求令牌交换为访问令牌

1. 创建新 REST 客户机，并配置应替换为访问令牌的请求令牌所在的位置。
2. 在 HTTP Options 选项卡下，选择 HTTP 1.0 或 HTTP 1.1，然后选择 Perform Authentication启用 OAuth 身份验证。这将允许启用完成 OAuth 身份验证需要的其他字段。
3. 在 Consumer Key 和 Consumer Secret下，添加键和秘密。
4. 选择 Exchange Request Token for Access Token 作为 OAuth Mode。
5. 参数化文本数据库提取中的 Request Token 和 Request Token Secret 字段。
6. 参数化浏览器数据库中的 Verification Code 字段。
7. 将文本数据库附加到 REST 客户机的响应流量，并提取访问令牌（通常表示为 oauth_token）和访问令牌秘密（通常表示为 oauth_token_secret）。

签名 OAuth 请求以访问所保护资源

1. 创建新 REST 客户机，并配置应用于访问私有资源的请求令牌所在的位置。
2. 在 HTTP Options 选项卡下，选择 HTTP 1.0 或 HTTP 1.1，然后选择 Perform Authentication启用 OAuth 身份验证。这将允许启用完成 OAuth 身份验证需要的其他字段。
3. 在 Consumer Key 和 Consumer Secret下，添加键和秘密。
4. 选择 Sign Request for OAuth Authentication 作为 OAuth Mode。
5. 参数化文本数据库提取信息中的 Access Token 和 Access Token Secret 字段。
6. 请求用户私有资源这应该是可能的，因为已经获得了访问令牌。

使用 OAuth 2.0

OAuth 2.0 与上一个版本（OAuth 1.0a）相比，得到了显著地简化。由于 OAuth 2.0 完全是一个新的协议，所以与 OAuth 1.0a 不逆向兼容。然而，它共享相同且全面的体系结构和方法，以给用户提供授权第三方应用程序访问私有资源的方法，而无需显示登录凭证。

若想了解 OAuth 2.0 中引入的更改，请在 http://tools.ietf.org/html/draft-ietf-oauth-v2-20中查阅工作草图。

使用 OAuth 2.0 涉及以下常规步骤：

1. 请求身份验证
2. 获取访问令牌
3. 访问受保护的资源

以下示例使用 REST 客户端向服务器发送请求消息。注意，消息传递客户机可以以相同的方式使用 OAuth 2.0。

请求身份验证 

1. 通过在 Start Recording From 字段中输入所需 URL 并指定 OAuth URL 参数，创建一个 Web 浏览器记录。一旦授权成功，服务提供程序会用代码将您作为 URL 参数的一部分重定向到回调 URL。
2. 关闭浏览器以完成记录。
3. 通过在 Request -> Validate Header 上创建文本数据库（Text Data Bank）提取代码。确保选择 HTTP 流量中的浏览器数据，然后选择包含代码的重定向 URL。
   
   
   
   
   
   

获取访问令牌 

1. 创建新的 REST 客户机并为 URL 提供必要参数。其中一个 URL 参数应该被称为 code。该值应该根据上一步骤中的文本数据库提取信息进行参数化。
   
   
   
   
2. 根据响应格式，将合适的数据库（如文本、JSON）附加到 REST 客户机并提取访问令牌。

访问受保护的资源

1. 对于每次 REST API 调用，创建新的 REST 客户机并为其所需 URL 提供必要 URL 参数。其中一个 URL 参数应该被称为 oauth_token，并具有在上一测试步骤中提取到访问令牌的值。