RESTful 浏览器用户代理和身份验证

Question

我已经看到很多关于 RESTful 身份验证的问题，但我想知道在对 RESTful Web 服务进行身份验证时使用了哪些策略来保持浏览器用户代理无状态。

使用自定义 REST 客户端执行此操作非常“简单”：我们可以使用 Basic Auth、Digest、OAuth 或滚动您自己的（自定义标头、令牌、签名等）。因此，对于机器对机器，我们几乎涵盖了，但我只对使用日常浏览器用户代理（IE、Firefox 等）进行身份验证感兴趣。例如 JSON 已退出，因为浏览器无法呈现/使用它；)

以下是我对浏览器限制的一些想法：

• AFAICS 浏览器是否无法发送自定义标头，例如 OAuth 使用的标头？ （对吧？）
• 我有一种感觉，应该能够有一个用户登录的登录页面（例如 html+ssl）。 （无基本身份验证）然后浏览器捕获一个令牌并将其与每个请求一起传回服务器。 Basic Auth 的问题是我没有“漂亮的自定义登录页面”。当前的身份验证机制是否可扩展以使其保持稳定？
• 我在打破/放松 REST 约束时非常小心，因为有可能失去可扩展性的好处。

A similar answer here 但我有一个针对 cookie 的特殊情况：（无需详细说明）：浏览器当前使用 cookie 的工作方式是不可能的，因为服务器处于控制之中的饼干。 （来自服务器端状态的“Set-Cookie”标头）。客户端不理解或解释它提供的 cookie 的内容，只是返回它。问题是客户端无法控制 cookie。因此，是的，我们可以在“自定义/机器到机器客户端”中以一种安静的方式使用 cookie，但这不是浏览器实现它的方式。

您一直在使用哪些策略和最佳实践，您的经验是什么？有没有多余的cmets？

Answer 1

我认为您提到的浏览器限制对于大多数用例而言基本上是无法克服的。我们个人的解决方案是向用户展示一个包含自定义 REST 客户端的轻量级非 RESTful 层；例如，对于 JavaScript 应用程序，我们通过 JSON-RPC 公开服务器端 REST 客户端。

Answer 2

如果您使用的是 apache 网络服务器，您可能需要查看this document。