6

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

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

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

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

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

4

7 回答 7

4

“网站上用户身份验证的标准模型涉及“登录”身份验证事件，之后（如果成功）用户通过持久的安全会话“在墙内”

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

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

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

去做。

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

于 2010-01-06T03:44:07.167 回答
3

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

您可以考虑创建会话，而不是验证用户。您将收到一个新的“会话 ID”以及相应的 HTTP 状态代码（200：OK，403：Forbidden 等）。

用户可能会看到与未经身份验证的用户在同一请求中看到的不同的 HTML

您将询问您的 REST 服务器：“您能给我获取此会话 ID 的 HTML（或任何资源）吗？”。HTML 将根据“会话 ID”而有所不同。

使用这种方法，“持久安全会话”就没有墙了。您只是在执行会话。

如果您选择此方法，名词（或资源）将代表实际会话。

于 2010-01-06T03:29:42.127 回答
2

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

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

于 2010-01-08T15:33:06.057 回答
1

我这样想：用户身份验证中的“名词”是会话。因此，您的登录表单使用 POST 请求“创建”新会话，注销使用 DELETE 请求“删除”会话。

我知道您所说的针对 RESTful 的身份验证持久性是什么意思，但是 cookie（给人一种持久性的错觉）只是每个请求的一部分。

于 2010-01-06T03:19:32.577 回答
1

“这种身份验证的持久性似乎破坏了 RESTful-ness。缓存和无状态似乎被破坏了，因为经过身份验证的用户可能会看到与未经身份验证的用户在同一请求中看到的 HTML 不同”

如果资源的表示基于身份验证信息略有不同，则可以。身份验证信息是消息的一部分，因此消息仍然是“自我描述的”。从概念上讲，您仍在访问相同的资源，并且允许编辑和删除链接转换，而不是其他数据。根据谁访问资源来控制可用的转换对我来说似乎是有效的。

于 2010-01-09T03:00:04.173 回答
1

回复：丹尼尔的回答：

如果会话是一个快速删除的临时对象，那么这不是很可缓存的，因为您创建的任何缓存都只有可能一天的有用生命周期，但无论如何也会继续用完缓存中的空间。

将 USER 创建为对象并使用摘要身份验证（如果必须的话，使用 cookie）进行身份验证不是更好吗？这样，每个用户都会获得自己的持久缓存，而不是持续一天然后消失的缓存。

这对我来说也更合乎逻辑，因为您使页面看起来因用户而异（添加“hello [name]”等），并且“登录”和“注销”状态之间的区别取决于用户是否包含在 URL 中。是否授予特定人员访问该用户特定 url 的权限取决于他们是否可以作为该用户进行身份验证。

于 2010-03-05T03:46:17.137 回答
0

如果您的 RESTful 框架仅由您的 Web 应用程序使用，并且不会用作第三方的 API，那么我认为您没有理由不能使用与应用程序的其余部分相同的身份验证方案。您可以将此身份验证视为比“应用程序”级别更低级别的层。应用程序级别可能仍以纯 RESTful 方式保持无状态。

当然，如果您打算创建一个 RESTful Web API，则需要多加考虑。

于 2010-01-06T03:23:23.550 回答