自定义HTTP Authorization标头
我想知道将自定义数据放在HTTP授权标头中是否可以接受。我们正在设计一个RESTful应用程序接口，我们可能需要一种方法来指定自定义的授权方法。作为示例，我们称其为FIRE-TOKEN身份验证。
根据规范，这样的代码是否有效并被允许：Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
第二个字符串的第一部分(在‘：’之前)是API密钥，第二部分是查询字符串的哈希。
回答 4
Stack Overflow用户
发布于 2012-07-11 03:39:45
RFC2617中定义的格式是credentials = auth-scheme #auth-param。因此，在同意福满语的基础上，我认为更正后的授权方案应该如下所示
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="其中FIRE-TOKEN是方案，两个键值对是身份验证参数。尽管我认为引文是可选的(来自p7-auth-19的附录B)……
auth-param = token BWS "=" BWS ( token / quoted-string )我相信这符合最新的标准，已经在使用中(见下文)，并为简单扩展提供了一个键-值格式(如果你需要额外的参数)。
可以在这里看到这种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
Stack Overflow用户
发布于 2011-10-18 11:55:44
将其放在单独的自定义标头中。
重载标准的HTTP头可能会引起更多的混乱，并且会违反principle of least surprise。对于那些想要使用现成的工具包(这些工具包只能处理标准格式的典型HTTP头(比如Authorization) )的API客户端程序员来说，这也可能导致互操作性问题。
Stack Overflow用户
发布于 2011-10-18 23:08:06
不，根据RFC 2617中的"credentials“定义，这不是有效的产品。您提供了一个有效的auth-scheme，但是auth-param值的格式必须是token "=" ( token | quoted-string ) (请参见第1.2节)，并且您的示例没有使用"=“。
https://stackoverflow.com/questions/7802116
复制相似问题