cUrls 的选项“-u" [英] cUrls's option "-u"

问题描述

来自 cUrl 文档:

From cUrl docs:

-u, --user <user:password;options>

Specify the user name, password and optional login options to use for server authentication. Overrides -n, --netrc and --netrc-optional.

它被翻译成什么，这意味着我如何在服务器上捕获它以对用户进行身份验证:它们是在 GET 参数中还是在 POST 参数中?

What it gets translated to, meaning how do I catch it on the server to authenticate the user: are they in GET or in POST parameters?

语言不重要，想法很重要.

The language is not important, the idea is important.

推荐答案

这完全取决于 身份验证方法 但对于最常见的方法 - 基本身份验证 和 Digest Auth，这适用于临时 HTTP 标头.这是基本身份验证的示例:

It all depends on the authentication method but for the most common ones - Basic Auth and Digest Auth, this works with ad hoc HTTP headers. Here's an example with Basic Auth:

curl -u john:pwd http://foo.com/misc

这将使用相应的标头执行 GET 请求:

This performs a GET request with the corresponding header:

GET /misc HTTP/1.1
Authorization: Basic am9objpwd2Q=
User-Agent: curl/7.33.0
Host: foo.com
Accept: */*

Authorization 标头包含服务器应该解析、base64 解码[1] 和使用的身份验证数据.将使用 POST 请求设置相同的标头.您可以使用 httpbin(1) 之类的服务轻松测试它(请参阅 /basic-auth/:user/:passwd 端点).

The Authorization header contains the authentication data the server is supposed to parse, base64 decode[1] and use. The same header would be set with a POST request. You can easily test it out with a service like httpbin(1) (see /basic-auth/:user/:passwd endpoint).

摘要身份验证有点复杂，但也适用于 HTTP 标头:

Digest auth is a bit more complex but works with HTTP headers too:

• 客户端首先发送它的请求，服务器回复一个 401 Unauthorized 包括一个 WWW-Authenticate 标头和一个需要解决的挑战，
• 客户端解决挑战并发送另一个请求，并将响应包含在 Authorization 标头中，该标头必须在服务器端进行解析和验证.

• the client first send its request, the server replies with a 401 Unauthorized including a WWW-Authenticate header with a challenge to solve,
• the client solves the challenge and send another request with the response included into a Authorization header which has to be parsed and validated on the server-side.

[1]: base64("john:pwd") -> am9objpwd2Q=

这篇关于cUrls 的选项“-u"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！