以RESTful方式验证网页用户的首选方法是什么？

Question

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

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

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

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

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

Answer 1

身份验证的这种持久性似乎打破了RESTful

您可以考虑创建会话，而不是对用户进行身份验证。您将返回一个新的“会话ID"，以及相应的HTTP状态代码(200: OK，403:禁止，等等)。

用户看到的超文本标记语言可能与未经身份验证的用户看到的相同请求的超文本标记语言不同

你会问你的REST服务器：“你能给我这个会话ID的HTML (或任何资源)吗？”HTML将根据“会话ID”而有所不同。

使用这种方法，没有“持久安全会话”的围墙。您只是在会话上执行操作。

如果您选择此方法，名词(或资源)将表示实际的会话。

Answer 2

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

，

1. ，这不是真的正确。这在一定程度上是正确的，但只有对于发明了自己的authentication.
2. If的网站，才会使用“摘要身份验证”浏览器必须在每次请求时发送凭据。

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

就这么做吧。

为了使事情更简单，您可以根据时间计算摘要身份验证随机数，以便它在一段时间内是有效的(6分钟，0.1小时为好)。每个人只要几分钟的请求就会发送401状态，并要求重新计算摘要。

Answer 3

在包含特定于用户的元素的页面的中介中保留可缓存性的一种选择是通过Ajax添加特定于用户的标记。您为每个用户提供相同的页面，包括一些对资源执行XHR请求的JavaScript，该资源将根据用户登录返回不同的内容。然后将其合并到客户端的页面中。然后页面的主要部分将是可缓存的，因为它对每个用户都是相同的。

另一种选择是使用ESI (Edge Side Includes)。有了这些，缓存本身就可以合并不同的表示来构建最终结果。