http - 以 RESTful 方式对网页用户进行身份验证的首选方法是什么？

Question

我正在开发一个新的实验性 Web 应用程序框架，我决定给予 RESTful 一些关注。我已经阅读了基础知识，感觉我对 RESTful 这个概念有了很好的理解。

我已经启动并运行了一个系统，严格使用 URL 来定义系统中的“名词”，并从 HTTP 请求方法中获取“动词”。我正在使用 javascript ajax 调用来提供对 HTML 表单无法提供的 DELETE 和 PUT 方法的访问。 (我意识到这些措施并不严格要求是 RESTful，但它满足“统一接口(interface)”要求)。

问题来自身份验证的无状态性和可缓存性。网站上用户身份验证的标准模型涉及“登录”身份验证事件，之后(如果成功)用户通过持久安全 session 进入“墙内”，并且可以在后续请求中看到和执行未经身份验证的用户可能看不到的事情。这种身份验证的持久性似乎破坏了 RESTful-ness。缓存和无状态似乎被破坏了，因为经过身份验证的用户可能会看到与未经过身份验证的用户针对同一请求看到的 HTML 不同的内容(例如，侧边栏中可能有一个登录表单用于登录-出用户)。

使用 www-authenticate 策略仅在需要身份验证的请求上对用户进行身份验证似乎是朝着正确方向迈出的一步，因为它不涉及持久安全 session 的概念。然而，仍然存在如何向最终用户描绘“已登录”外观以符合我们对网站的所有期望的问题。

那么在目前的想法中，以严格的 RESTful 方式处理网页的身份验证和许可的首选方式是什么，同时仍然允许在 HTML 中进行登录装饰？

Answer 1

“网站上用户身份验证的标准模型涉及“登录”身份验证事件，之后(如果成功)用户通过持久安全 session 进入“墙内”

1. 这并不正确。这部分正确，但仅适用于发明了自己的身份验证的网站。

2. 如果您使用“摘要式身份验证”，浏览器必须随每个请求发送凭据。

摘要式身份验证——每个请求的凭据——完全是 RESTful。

那样做。

为了稍微简化一些事情，您可以根据时间计算摘要身份验证 Nonce，以便它在一段时间内有效(6 分钟，0.1 小时是好的)。几分钟后，每个请求都会发送 401 状态并需要重新计算摘要。