ajax - 坚持我的 REST 武器还是打破无国籍状态？需要建议

Question

我写了一个 RESTful servlet，UI 开发人员希望将登录状态保存在服务器上。

他提出了一个奇怪的说法:“我还没有遇到过纯 REST 的生产 REST 实现。我见过的都让服务器维护 session 。”

我觉得这很难接受。首先，技术上存在大量纯 HTTP 页面，全都是纯 RESTful 的。其次，是的，有标记为 RESTful 的非 RESTful 实现，就像标记为“黄金”的黄铜一样。第三，仅仅因为其他人跳下桥并不意味着我应该。

背景:它是一个使用 HTTPS 和基本身份验证的 JavaScript Ajax Web 应用程序。为避免出现通常的(不可自定义的)浏览器登录弹出框，该应用程序会显示一个登录屏幕，其中包含产品 Logo 以及名称和密码的文本框。名称和密码存储在文档中，并在每个请求的 Authorization header 中发送。如果刷新页面，名称和密码将丢失，用户必须再次输入。这被认为是一个错误； UI 开发人员希望能够在不再次输入密码的情况下按下刷新按钮。

所以开发者想要使用cookie 或JSP session 。 Abby，最终每个 REST 实现都会在服务器上维护应用程序状态，这是真的吗？或者有什么方法可以解决这个问题并且仍然保持我的 RESTful 纯度？

Answer 1

我认为出于实际原因(主要是可浏览能力)，您需要区分应用程序状态和身份验证状态。我想不出任何不会在服务器端保留某种形式的状态的身份验证机制。

真正重要的是它与应用程序的分离程度。例如，HTTP Digest 在服务器上保留了某种形式的状态，但这显然被抽象为正常 WWW-Authenticate 的一部分。和 Authorization header 协商。因为大多数浏览器本身都支持它，所以这与应用程序是正交的，因此不会破坏 REST 的无状态原则。

如今，由于用户对 HTTP Basic/Digest 身份验证在浏览器中无法满足的审美期望，网站倾向于使用基于表单的身份验证，随后使用 cookie。公平地说，这不仅仅是它的外观，它还涉及可用性(例如“忘记密码”信息，尽管这可能在 401 响应的正文中)和安全性。浏览器不会让您轻松地从 Basic/Digest/Certificate 身份验证中注销，除非它完全在单个页面中的 Ajax 中完成，正如您所提到的，这可以帮助 CSRF。

我认为 cookie 可以用于身份验证，但请确保不要在 session 中存储与应用程序相关的变量。

你可以阅读一些 Roy Fielding's comments on the topic :

Authentication is orthogonal. Cookies are also orthogonal when they are simply used for content negotiation or authentication. However, Cookie authentication is not allowed in REST because it lacks visibility, which causes security problems because the other components don't know it is sensitive information.

编辑 (关于安全方面的进一步评论):

我意识到 Roy Fielding 在我引用的消息中的评论是出于安全原因反对 cookie。他当然是对的。但是，在我看来，通过 Basic/Digest/Cert (在 2003 年，该消息的日期并没有真正引起人们的注意)来防止 CSRF 比防止 cookie 盗窃更难。当然，这取决于实现。没有完美的解决方案，但如果您使用 cookie，请通过 HTTPS 使用安全 cookie。