validation - 通过 REST API 验证/更改密码

Question

我想通过 REST API 更改用户密码。这不是忘记或重置密码功能，而是想要更改密码的登录用户。

该表单需要当前密码、新密码和新密码确认。但是，我想在用户填写时验证每个表单字段。这对于 newPassword 来说是微不足道的和 confirmNewPassword (客户端)，但不适用于 currentPassword .当前正在通过 PUT /users/:id 更新用户对象.如果传递了密码参数，我会检查 currentPassword参数并在保存之前确保它是正确的。但是，为了验证，我不确定最好的方法。

我也有 POST /users/validate - 不确定这是否最好。这将验证用户对象的创建和更新，但仅验证属于用户对象的字段( email 、 username 、 password )。 currentPassword不是其中之一。想知道如何处理。我考虑过的一些事情:
POST /users/check_password ,POST /users/validate (如果通过该参数，则添加对 currentPassword 的验证，并检查 currentPassword 是否与用户现有密码匹配)和POST /users/:id/validate (现有用户的单独验证，需要 currentPassword )。

任何想法或建议将不胜感激。我的第一个仅通过 REST API 公开功能的应用程序。

Answer 1

我首先要指出身份验证通常是在 REST 模型之外处理的。当用户提供其凭据时，他们并未提供其帐户对象状态 (REST) 的表示；他们收到的回应也不是这样的代表。由于用户帐户资源状态不包括“当前”和"new"密码，因此在请求中同时提供“当前”和"new"密码永远不可能真正适合 REST 模型，但专业人士经常描述REST 性的“连续统”，一些 API 是完全 RESTful 的，而另一些则介于 RPC(远程过程调用)和 REST 之间。

拥有处理数据模型服务的 API 的 RESTful 组件和处理用户帐户的 API 的更多 RPC 组件并不少见。您可以在两者之间做出决定。如果您的项目包含管理多个用户帐户的 super 用户，我建议尝试将其硬塞到 REST API 中。如果每个用户只管理自己的帐户，我建议使用 RPC。

如果您决定使用 REST 进行帐户管理，那么您必须选择合适的 HTTP 方法(GET、POST、DELETE、HEADERS 等)。显然，您需要一种方法来影响服务器上的更改(POST、PUT、DELETE 等)。与上面用户 orbfish 的结论相反，我要说的是，在某些限制下，PUT 将是一种合适的方法。

来自 RFC 2616 ，它正式定义了我们的 HTTP 方法:

"Methods can also have the property of 'idempotence' in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent. "

这里的幂等性是指如果我们连续发出 n 次相同的请求，第 n 个请求影响下的服务器状态将与第一个请求影响下服务器的状态相同。用户 orbfish 正确地指出，如果我们提出请求:

PUT /users/:id/account {current-password: 'a', new-password: 'b'}

并重复一遍:

PUT /users/:id/account {current-password: 'a', new-password: 'b'}

我们的第一个请求应该收到一个表示成功的响应，而我们的第二个请求应该收到一个表示失败的响应。但是，PUT 的幂等性只要求服务器的状态在两个请求之后是相同的。它是:在第一次请求之后，用户的密码是“b”，在第二次请求之后，用户的密码是“b”。

我上面提到了限制。您可能希望在 m 次尝试更改密码失败后锁定用户；这将提供针对暴力密码攻击的安全性。但是，这会破坏请求的幂等性:发送一次有效的密码请求，您更改密码，再发送一次，服务器会将您锁定。

通过指定 PUT 方法，您可以告诉所有客户端根据需要多次发送请求是安全的。如果我作为客户端发送 PUT 请求并且我们的连接被中断以至于我没有收到您的响应，我知道再次发送我的 PUT 是安全的，因为它是幂等的:幂等意味着如果您收到两个请求将与您的服务器相同，因为只是接收一个。但是，如果您要因请求失败而将我锁定，那么在我知道您是否收到第一个请求之前，发送第二个请求是不安全的。

出于这个原因，您可能会考虑 PATCH 或 POST。我建议使用 PATCH。 POST 被描述为将新资源附加到列表或将数据附加到现有资源，而 PATCH 被描述为对已知 URI 资源的“部分更新”。与 PUT 不同的是，PATCH 不需要是幂等的。