通过 REST API 验证/更改密码 [英] Validate/Change Password via REST API

问题描述

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

I want to change a user password via a REST API. This is not a forgotten or reset password function, but a logged in user wanting to change their password.

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

The form requires the current password, the new password, and a confirmation for the new password. However, I want to validate each form field as the user fills it out. This is trivial for newPassword and confirmNewPassword (client side), but not for currentPassword. Currently performing update to the User object via PUT /users/:id. If a password parameter is passed, I check for the currentPassword parameter and ensure it is correct prior to saving. However, for validation, I'm unsure of the best approach.

我也有一个 POST/users/validate - 不确定这是否最好.这将验证用户对象的创建和更新，但仅验证属于用户对象的字段(email、username、password).currentPassword 不是其中之一.想知道如何处理.我考虑过的一些事情:

I also have a POST /users/validate - not sure if this is best either. This validates a User object for both create and update, but only validates fields that belong to the User object (email, username, password). currentPassword isn't one of these. Wondering how to handle this. Some things I've considered:

POST/users/check_password,POST/users/validate(如果传递了该参数，则添加对 currentPassword 的验证，并检查 currentPassword 是否与用户现有密码匹配)和POST/users/:id/validate(现有用户的单独验证，需要 currentPassword).

POST /users/check_password, POST /users/validate (adding in validation for currentPassword if that parameter is passed, and check that currentPassword matches the users existing password) and POST /users/:id/validate (separate validation for existing user, requiring currentPassword).

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

Any thoughts or advice would be greatly appreciated. My first application that only exposes functionality via REST API.

推荐答案

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

I'll start by pointing out that authentication is often handled outside of a REST model. When a user provides their credentials, they are not providing a REpresentation of their account object's STate (REST); nor is the response they receive such a representation. Because the user account resource state does not include both 'current' and 'new' passwords, the provision of both a 'current' and a 'new' password in a request can never truly fit under the REST model, but professionals often describe a 'continuum' of RESTfulness, with some APIs being completely RESTful and others falling between RPC (Remote Procedure Call) and REST.

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

It's not uncommon to have a RESTful component of an API that handles the serving of data models, and a more RPC component of an API that handles user accounts. You get to decide between the two. If your project includes super users that manage multiple user accounts, I would suggest trying to shoe-horn that into a REST API. If each user manages only their own account, I would suggest RPC.

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

If you've decided to use REST for account management, then you must choose an appropriate HTTP method (GET, POST, DELETE, HEADERS, etc). Clearly you require a method that will effect a change on the server (POST, PUT, DELETE, etc). In contrast to user orbfish's conclusion above, I'm going to say that PUT would be an appropriate method, under certain restrictions.

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

From RFC 2616, which formally defines our HTTP methods:

"方法也可以具有幂等性"的特性，因为(除了错误或过期问题)N > 0 个相同请求的副作用与单个请求相同.方法 GET、HEAD、PUT和 DELETE 共享此属性.此外，方法 OPTIONS 和 TRACE 不应有副作用，因此本质上是幂等的."

"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 正确地指出，如果我们提出请求:

Idempotency here means that if we make the same request n times in a row, the state of the server under the effects of the nth request will be the same as the state of the server under the effects of the first request. User orbfish correctly notes that if we make the request:

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

重复一遍:

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

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

that our first request should receive a response indicating success and our second request should receive a response indicating failure. However, the idempotency of PUT only requires that the state of the server is the same following both requests. And it is: after the first request the user's password is 'b' and after the second request the user's password is 'b'.

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

I mentioned restrictions above. You might want to lock a user out after m attempts to change a password unsuccessfully; this would provide security against brute-force password attacks. However, this would break the idempotency of the request: send a valid password request one time and you change your password, send it m more times and the server locks you out.

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

By specifying the PUT method, you are telling all clients that it's safe to send a request as many times as needed. If I as a client send a PUT request and our connection is interrupted such that I don't receive your response, I know that it is safe to send my PUT through again because it is idempotent: idempotency means that if you receive both requests it will be the same to your server as just receiving one. But if you're going to lock me out for an unsuccessful request, then it isn't safe to send a second request until I know whether you have received the first.

因此，您可以考虑 PATCH 或 POST.我建议使用 PATCH.POST 被描述为将新资源附加到列表或将数据附加到现有资源，而 PATCH 被描述为对已知 URI 资源的部分更新".与 PUT 不同的是，PATCH 不需要是幂等的.

For this reason, you might consider PATCH or POST. I would suggest using PATCH. Whereas POST is described as either appending a new resource to a list or appending data to an existing resource, PATCH is described as a 'partial update' on a resource at a known URI. And unlike PUT, PATCH need not be idempotent.

这篇关于通过 REST API 验证/更改密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！