我有一个使用Authorization标头已通过基本身份验证保护的REST服务。这通常用于访问服务，并且对于任何请求都是必需的。即“User1”，“password1”。
我有一个“文件”资源，可以有一个与之关联的附加密码（即受密码保护的Word文档，PDF等），“docpassword”。发送此类敏感信息的最佳方式是什么？我对如何发送GET请求的密码特别感兴趣，但是我希望有一个通用解决方案，它也适用于POST请求。
也许是自定义标题？
答案 0 :(得分：0)
HTTP已经有一种身份验证方法，例如参见此RFC：https://tools.ietf.org/html/rfc2617
在澄清问题后进行编辑：即使基于单一资源，也无法阻止服务器提出其他挑战。我必须承认我还没有实现这样的东西，但每个授权都有自己的领域。如果你真的想要，你可以指定不同的领域，甚至可以指定文档级别。然后，服务器可能在每个领域中进行多次挑战（首次登录，然后是文档）。请记住，您可以在客户端（对于领域，如浏览器）缓存成功的身份验证，或者使用缓存的令牌发布cookie。
这样可以避免使用自定义标头，并且完全符合HTTP / REST。可能存在一些性能劣势，但可以通过一些有针对性的缓存来减轻它。
当然，如果您愿意，可以使用自定义标头，但通常情况下，REST会暗示客户端除了mime-types和HTTP协议之外没有先验知识。自定义标题意味着带外先验知识。
答案 1 :(得分：0)
HTTP协议定义了用于向服务器发送身份验证数据（凭据）的标准Authorization标头。此标头在RFC 7235中定义（使旧的RFC 2616过时并更新RFC 2617）：
Authorization标头字段允许用户代理进行身份验证 本身与原始服务器 - 通常，但不一定，后 收到401（未经授权）回复。它的价值包括 包含用户身份验证信息的凭据 被请求资源领域的代理。Authorization = credentials[...]
请注意，此HTTP标头的名称很不幸，因为它带有身份验证数据而不是授权。无论如何，这是用于在HTTP协议中发送凭证的标准标头。
在您使用HTTP Basic Authentication Scheme对应用程序中的用户进行身份验证后，我相信您已使用标准Authorization标题。
我通常不建议使用自定义标头，尤其是当可以使用标准标头时，但您的方案似乎并不常见：您需要对同一请求执行两次身份验证。
因此，使用文档密码的自定义标头（如X-Auth-Document或Document-Authentication）可能适用于GET个请求。如果您决定不使用GET并决定使用POST来访问此资源，则可以考虑在请求paylod中发送文档的密码。
无论如何，不要忘记使用HTTPS：一旦您通过网络发送敏感数据（如凭据），这是非常明智的。 HTTPS可以保护您免受man-in-the-middle attack。
的攻击