以 RESTful 方式对网页用户进行身份验证的首选方法是什么？
我正在开发一个新的实验性 Web 应用程序框架，我决定给予 RESTful 一些关注。我已经阅读了基础知识，感觉我对 RESTful 作为一个概念有了很好的理解。
我已经启动并运行了一个系统，严格使用 URL 来定义系统中的“名词”，并从 HTTP 请求方法中获取“动词”。我使用 javascript ajax 调用来提供对 HTML 表单无法提供的 DELETE 和 PUT 方法的访问。 （我意识到这些措施并不严格要求是 RESTful，但它满足“统一接口”要求）。
问题在于身份验证的无状态性和可缓存性。网站上用户身份验证的标准模型涉及“登录”身份验证事件，之后（如果成功）用户将处于“墙内”并具有持续的安全会话，并且可以根据后续请求查看和执行未经身份验证的用户可能看不到的操作。这种身份验证的持久性似乎破坏了 RESTful 性。缓存和无状态性似乎被破坏了，因为经过身份验证的用户可能会看到与未经身份验证的用户在同一请求中看到的 HTML 不同的 HTML（例如，侧边栏中可能有一个用于登录的登录表单）出用户）。
使用 www 身份验证策略仅对需要身份验证的请求进行用户身份验证似乎是朝着正确方向迈出的一步，因为它不涉及持久安全会话的概念。然而，仍然存在一个问题，即如何向最终用户描绘“已登录”的外观，以符合我们对网站的期望。
那么，在当前的想法中，以严格的 RESTful 方式处理网页的身份验证和许可，同时仍然允许在 HTML 中进行登录装饰的首选方法是什么？
I'm developing a new experimental web-application framework, and I decided to give RESTful some attention. I've read up on the basics, and feel like I have a pretty good understanding of RESTful as a concept.
I've got a system up and running, using URLs strictly to define 'nouns' in the system and take the 'verbs' from the HTTP request methods. I'm using javascript ajax calls to provide access to the DELETE and PUT methods which HTML forms cannot provide. (I realize these measures aren't strictly required to be RESTful, but it satisfies the 'Uniform Interface' requirement).
The problem comes with stateless-ness and cacheability with authentication. The standard model for user authentication on websites involves a "login" authentication event, after which (if successful) a user is "inside the wall" with a persistent secure session and may see and do things on subsequent requests which unauthenticated users may not. This persistence of authentication seems to break RESTful-ness. Caching and statelessness appear to be broken, because the authenticated user will probably see HTML which is different from that which a non-authenticated user will see for the same request (for instance, there might be a login form in a sidebar for the logged-out user).
Using www-authenticate strategies to authenticate a user only on the requests which require authentication seems to be a step in the right direction, as it doesn't involve the concept of a persistent secure session. However there's still the question of how to portray a "logged in" appearance to the end user in keeping with what we've all come to expect from websites.
So in the current thinking, what's the preferred way to handle authentication and permissioning of a webpage in a strictly RESTful way, while still allowing for logged-in decorations in the HTML?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
“网站上用户身份验证的标准模型涉及“登录”身份验证事件，之后（如果成功）用户将在“墙内”进行持久的安全会话”
这实际上并不正确。这在一定程度上是正确的，但仅适用于发明自己的身份验证的网站。
如果您使用“摘要式身份验证”，浏览器必须随每个请求发送凭据。
如果
摘要式身份验证（每个请求的凭据）完全是 RESTful。
这样做。
为了使事情稍微简化一些，您可以根据时间计算摘要身份验证 Nonce，以便它在一段时间内有效（6 分钟、0.1 小时都可以）。每个请求几分钟后都会发送 401 状态并需要重新计算摘要。
"The standard model for user authentication on websites involves a "login" authentication event, after which (if successful) a user is "inside the wall" with a persistent secure session"
This isn't really correct. It's partly true, but only for web sites that invent their own authentication.
If you use "digest authentication" the browser must send the credentials with each request.
Digest authentication -- credentials with each request -- is totally RESTful.
Do that.
To make things slightly more streamlined, you can compute the digest authentication Nonce based on time so that it's good for some period of time (6 minutes, 0.1 hr is good). Everyone few minutes a request will send a 401 status and require recomputation of the digest.
您可能会考虑创建一个会话，而不是对用户进行身份验证。您将收到一个新的“会话 ID”以及相应的 HTTP 状态代码（200：正常、403：禁止等）。
您将询问您的 REST 服务器：“您能给我这个会话 ID 的 HTML（或任何资源）吗？”。 HTML 将根据“会话 ID”而有所不同。
通过这种方法，“持久安全会话”就不再存在障碍。您只是在执行会话。
如果您选择此方法，名词（或资源）将代表实际会话。
Instead of authenticating a user, you may think about creating a session. You will be returned a new "Session ID", along with the appropriate HTTP status code (200: OK, 403: Forbidden, etc).
You will be asking your REST server: "Can you GET me the HTML (or any resource) for this Session ID?". The HTML will be different based on the "Session ID".
With this method, there is no wall for "persistent secure sessions". You are simply acting on a session.
The noun (or the resource) would represent the the actual session, if you opt for this method.
在具有用户特定元素的页面的中介中保留可缓存性的一种选择是通过 Ajax 添加用户特定标记。您为每个用户提供相同的页面，包括一些 JavaScript，这些 JavaScript 将对资源执行 XHR 请求，该资源根据用户登录返回不同的内容。然后，您将其合并到客户端的页面中。页面的主要部分将可缓存，因为它对于每个用户都是相同的。
另一种选择是使用 ESI（边缘包含）。有了这些，缓存本身就可以合并不同的表示形式来构建最终结果。
One option to preserve cachability in intermediaries for pages with user-specific elements is to add the user-specific markup via Ajax. You serve every use the same page, including some JavaScript that will do an XHR request to a resource that returns something different based on the user login. You then merge this into the page on the client side. The major part of the page will then be cachable as it's the same for every user.
Another option is to use ESI (Edge Side Includes). With these, the cache itself can merge different representations to build up the final result.
我是这样想的：用户认证中的“名词”是会话。因此，您的登录表单使用 POST 请求来“创建”新会话，而注销则使用 DELETE 请求来“删除”会话。
我知道您所说的与 RESTful 相悖的身份验证持久性是什么意思，但 cookie（给人持久性的错觉）只是每个请求的一部分。
I think about it like this: The "noun" in user authentication is a session. So your login form uses a POST request to "create" a new session, and logging out uses a DELETE request to "delete" the session.
I know what you mean about the persistence of authentication going against RESTfulness, but the cookies (which give the illusion of persistence) are simply a part of each request.
“这种身份验证的持久性似乎破坏了 RESTful 性。缓存和无状态性似乎被破坏了，因为经过身份验证的用户可能会看到与未经身份验证的用户在同一请求中看到的 HTML 不同的 HTML”
如果根据身份验证信息，资源的表示略有不同。身份验证信息是消息的一部分，因此消息仍然是“自描述的”。从概念上讲，您仍在访问相同的资源，并且编辑和删除链接允许转换，而不是附加数据。根据谁访问资源来控制可用的转换对我来说似乎是有效的。
"This persistence of authentication seems to break RESTful-ness. Caching and statelessness appear to be broken, because the authenticated user will probably see HTML which is different from that which a non-authenticated user will see for the same request"
It is ok if the representation of the resource is slightly different based on the authentication information. The auth information is part of the message and therefore the message is still "self-descriptive". Conceptually you are still accessing the same resource, and the edit and delete links are allowed transitions, not additional pieces of data. Controlling what transitions are available based on who accesses the resource seems valid to me.
回复：丹尼尔的回答：
如果会话是一个快速删除的瞬态对象，则这不是很可缓存的，因为您创建的任何缓存的有用生命周期可能只有一天，但无论如何也会继续耗尽缓存中的空间。
将 USER 创建为对象并使用摘要身份验证（或 cookie，如果必须的话）进行身份验证不是更好吗？这样，每个用户都会获得自己的持久缓存，而不是持续一天然后消失的缓存。
这对我来说也更符合逻辑，因为您根据用户的不同使页面看起来有所不同（添加“hello [name]”等），并且“登录”和“注销”状态之间的差异取决于用户是否包含在 URL 中。特定人员是否被授予访问该用户特定 URL 的权限取决于他们是否可以作为该用户进行身份验证。
Re: Daniel's answer:
If a session is a transient object that gets quickly deleted, this is not very cachable, as any cache you create would only have a useful lifetime of maybe a day, but also continue to use up space in the cache anyway.
Wouldn't it be better to create the USER as an object, and authenticate using the digest authentication, (or a cookie if you must). that way, each user gets their own persistant cache instead of a cache that lasts a day and disappears.
This also makes more logical sense to me, since you're making a page look different depending on the USER, (adding 'hello [name]' and such) and the difference between the "logged in" and "logged out" states depends on whether the user is included in the URL. Whether a particular person is granted access to that user specific url depends on whether they can authenticate as that user.
如果您的 RESTful 框架仅由您的 Web 应用程序使用，并且不会用作第三方的 API，那么我认为您没有理由不能使用与应用程序的其余部分相同的身份验证方案。您可以将此身份验证视为比“应用程序”级别更低的级别。应用程序级别可能仍以纯 RESTful 方式保持无状态。
当然，如果您计划创建 RESTful Web API，则需要更多考虑。
If your RESTful framework is only going to be used by your web application, and will not be used as an API for third parties, I see no reason why you cannot use the same authentication scheme as the rest of your application. You could think of this authentication as a lower-level layer than the "application" level. The application level may still remain stateless in a pure RESTful way.
Of course if you are planning to create a RESTful web API, you will need to give this more thought.