Answers:
RFC2617中定义的格式为credentials = auth-scheme #auth-param
。因此,我同意fumanchu,更正后的授权方案看起来像
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="
FIRE-TOKEN
方案在哪里,两个键值对是auth参数。尽管我相信引号是可选的(摘自p7-auth-19的附录B)...
auth-param = token BWS "=" BWS ( token / quoted-string )
我相信这符合最新标准,已经在使用中(请参阅下文),并且提供了用于简单扩展的键值格式(如果需要其他参数)。
可以在此处查看此auth-param语法的一些示例...
http://tools.ietf.org/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标头可能会造成比其应有的更多的混乱,并且会违反“ 最少惊喜”的原则。如果您的API客户端程序员希望使用仅能处理典型HTTP标头(例如Authorization
)的标准格式的现成工具包,也可能会导致互操作性问题。
Authorization
具有您自己的自定义方案的spec-standard 标头应该绰绰有余。另外,您避免使用@wilmoore指示的飞行前Origin请求。自定义方案不会干扰我所知道的任何合理的现代HTTP服务器,此外,如果您使用自己的方案,则必须自己解析它-库不应该发生冲突(否则库编写得不好)。
Authorization
标头(而不是自定义标头)中传输凭据的一个很好的理由是,代理和记录器知道将信息视为敏感信息。
不,根据RFC 2617中的“凭据”定义,这不是有效的产品。您提供了有效的auth-scheme,但是auth-param值必须采用以下格式token "=" ( token | quoted-string )
(请参见1.2节),并且您的示例不使用“ =”。
我知道一个老问题,但出于好奇:
信不信由你,这个问题在大约20年前用HTTP BASIC解决了,该问题将值传递为base64编码的username:password。(请参阅http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side)
您可以执行相同的操作,因此上面的示例将变为:
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==