自定义 HTTP 授权标头
我想知道将自定义数据放入 HTTP 授权标头中是否可以接受。我们正在设计一个 RESTful API，我们可能需要一种方法来指定自定义授权方法。作为示例，我们将其称为 FIRE-TOKEN 身份验证。
根据规范，这样的内容是否有效并允许： Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
第二个字符串的第一部分（在“:”之前）是 API 密钥，第二部分是查询字符串的哈希值。
I was wondering if it's acceptable to put custom data in an HTTP authorization header. We're designing a RESTful API and we may need a way to specify a custom method of authorization. As an example, let's call it FIRE-TOKEN authentication.
Would something like this be valid and allowed according to the spec: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
The first part of the second string (before the ':') is the API key, the second part is a hash of query string.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
RFC2617 中定义的格式为
credentials = auth-scheme #auth-param。因此，同意 fumanchu 的观点，我认为更正后的授权方案将类似于其中
FIRE-TOKEN是方案，两个键值对是身份验证参数。虽然我相信引号是可选的（来自 p7-auth-19 的附录 B）...我相信这符合最新标准，已经在使用（见下文），并提供了用于简单扩展的键值格式（如果您需要额外的参数）。
可以在此处查看此 auth-param 语法的一些示例...
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p7-auth-19#section-4.4
https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin
https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub
The format defined in RFC2617 is
credentials = auth-scheme #auth-param. So, in agreeing with fumanchu, I think the corrected authorization scheme would look likeWhere
FIRE-TOKENis the scheme and the two key-value pairs are the auth parameters. Though I believe the quotes are optional (from Apendix B of p7-auth-19)...I believe this fits the latest standards, is already in use (see below), and provides a key-value format for simple extension (if you need additional parameters).
Some examples of this auth-param syntax can be seen here...
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p7-auth-19#section-4.4
https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin
https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub
将其放在单独的自定义标头中。
重载标准 HTTP 标头可能会导致比其价值更多的混乱，并且会违反最小惊喜原则< /a>.对于想要使用只能处理典型 HTTP 标头的标准形式（例如
Authorization）的现成工具包的 API 客户端程序员来说，这还可能会导致互操作性问题。Put it in a separate, custom header.
Overloading the standard HTTP headers is probably going to cause more confusion than it's worth, and will violate the principle of least surprise. It might also lead to interoperability problems for your API client programmers who want to use off-the-shelf tool kits that can only deal with the standard form of typical HTTP headers (such as
Authorization).不，根据 RFC 2617 中的“凭据”定义，这不是有效的产生式。您给出了有效的 auth-scheme，但 auth-param 值必须采用
token "=" ( token |quoted-string )的形式（请参阅第 1.2 节），并且您的示例不使用 " => 这样。No, that is not a valid production according to the "credentials" definition in RFC 2617. You give a valid auth-scheme, but auth-param values must be of the form
token "=" ( token | quoted-string )(see section 1.2), and your example doesn't use "=" that way.我知道这个老问题，但出于好奇：
不管你信不信，这个问题在 20 年前就已经通过 HTTP BASIC 解决了，它将值作为 base64 编码的用户名：密码传递。 参阅http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side）
（请 可以做同样的事情，这样上面的例子就会变成：
Old question I know, but for the curious:
Believe it or not, this issue was solved ~2 decades ago with HTTP BASIC, which passes the value as base64 encoded username:password. (See http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side)
You could do the same, so that the example above would become: