RESTful 重置密码并确认电子邮件
我在想确认电子邮件和请求重置密码的最佳 RESTful 方式是什么。我的目标只是找到正确的 URI...
确认电子邮件
看起来不太 RESTful
PUT /users/{userId}/confirmEmail?code=xyz - 由于confirmEmail PUT /users/{userId， }/email?confirmedBy=xyz - 也许更好？不知道
重置密码（类似问题）
PUT /users/{userId}/resetPassword --DATA {email:[电子邮件受保护]} - 与之前的想法相同
PUT /users/{userId}/password --DATA {state:reseted,resent:[电子邮件] protected]} - 嗯......再次我不确定
你的方法是否有更好的方法 头脑？：-）
im thinking what is the best RESTful way how confirm email and request reseting password. Im only aiming to find correct URI...
confirm email
PUT /users/{userId}/confirmEmail?code=xyz - does not seem much RESTful because of confirmEmail
PUT /users/{userId}/email?confirmedBy=xyz - maybe better? dunno
reset password (similar problem)
PUT /users/{userId}/resetPassword --DATA {email:[email protected]} - same thinkin as before
PUT /users/{userId}/password --DATA {state:reseted,resent:[email protected]} - hmmm... again Im not sure
are there any better ways in your mind?:-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我最近在研究这个问题，我的看法是
POST /{base_url}/密码
因为我实际上是在创建一个新的随机密码并将其发送给用户
和
PUT /{base_url}/confirmation?token=...
因为我正在更新用户注册时已发送的确认信息。
I've recently worked on this, my take was
POST /{base_url}/password
because I was actually creating a new random password and sending it over to the user
and
PUT /{base_url}/confirmation?token=...
Because I am updating the confirmation that was already sent out when the user registered.
如果您希望 URI 引用资源，请调用资源
确认并向用户帐户发送确认。If you want your URIs to refer to resources, then call the resource
confirmationand POST confirmations to user accounts.真正的 RESTful 答案是 URL 并不重要，您无论如何都可以将其放入确认电子邮件中以供收件人遵循。使用对您的负载均衡器、反向代理、服务器等最方便的方式。
为了方便起见，您最终会接受确认，即使它来自 GET 请求，因为这是有血有肉的人类浏览器所忽视的罗伊·T·菲尔丁博士等人。单击电子邮件中的链接时发送:-)
确定它完全是学术性的，我认为您认为 PUT 是正确的，因为客户端幂等地放置可以访问电子邮件的证据。重复请求不会产生进一步的影响。
The true RESTful answer is the URL does not matter, you put it in the confirmation e-mail anyway for the recipient to follow. Use whatever is most convenient for your load balancer, reverse proxy, servers, etc.
For convenience you'll end up accepting the confirmation even if it comes in a GET request, because that's what the browsers of flesh-and-bones humans oblivious to Dr Roy T. Fielding et al. send when clicking on a link in an e-mail :-)
Having established it is completely academic, I'd argue you were right to think of PUT, as the client idempotently places evidence of having access to the e-mail. Repeating the request has no further effect.
考虑到他说的是为忘记密码的人提供重置服务，而不是为已经登录的人提供更改密码服务……
我会使用两种服务。第一次请求重置密码邮件，第二次使用收到的邮件中收到的令牌设置新密码。
第一次：
POST 基本网址/密码重置
请求正文
这可以是 POST 或 PUT，但由于邮件传递无论如何都不是受 CRUD 约束的资源，所以我们不要迂腐并使用始终在 html 表单中使用的旧 POST。
显然我会控制同一个客户端（ip？浏览器？...）不会让我在一分钟内发送 20K 邮件。
向用户发送邮件并不意味着旧密码无效。这只会在第二个请求稍后新请求更新时发生。
响应 204（即使您不知道该电子邮件，也许您也应该这样做，因为如果您返回错误，则意味着当您不返回错误时，您正在向陌生人确认给定的电子邮件已注册）
对于第二个：
POST 基本网址/密码
请求
正文 在邮件中接收令牌的位置。因此，邮件可能有一个指向包含令牌的页面的链接，当加载页面时，表单将被填写并提交，令牌是一些 JavaScript 从 URL 读取并放在这里的隐藏字段。
这实际上是您更新的资源，因此 POST。我认为使用相同的 URI 和 2 个动词是没有意义的，因为它们根本不是相同的资源/实体。
添加
顺便说一句，我将只使用 HTTPS，这就是为什么我将所有敏感信息放在正文中，而不是 URL 参数中。
Considering that he said a reset service for someone who forgot her password, and not a change password service for someone already logged in...
I would use 2 services. 1st to request the reset password mail, and 2nd to set the new password with the token received in the received mail.
For the 1st:
POST baseUrl/passwordReset
Request body
This could be POST or PUT, but since a mail delivery is not a resource subject to CRUD anyway, let's not be pedantic and use the old POST that was always used in html forms.
Obviously I would control that the same client (ip? browser? ...) doesn't make me send 20K mails in a minute.
Sending the mail to the user doesn't imply that the old password is not valid. That will only happen later in the second request when the new one updates it.
Response 204 (perhaps you should do it even if you don't know that email, because if you return error that means that when you don't return error you are confirming to a stranger that the given email is registered)
For the 2nd:
POST baseUrl/password
Request body
Where the token is received in the mail. So the mail could have a link to a page including the token, when the page is loaded, the form is filled and submitted, being the token a hidden field that some javascript reads from the URL and puts here.
This is really a resource that you update, so POST. And I don't think it makes sense to have the same URI with 2 verbs for both, because they are not the same resource/entity at all.
Add
By the way, I would make both HTTPS only, and that's why I put all the sensitive information in the body, not URL parameters.
首先，我认为
PUT不是正确的方法。PUT广泛地表示“将其放在这里”，其中 URL 标识内容应位于的位置。您实际上是在要求现有资源执行某些操作，这使得POST更加正确。要回答您的直接问题，RESTful URL 应标识您想要处理请求的资源。在这种情况下，资源要么是用户，要么是用户内的某些密码重置资源。
我的偏好是密码重置资源：
POST /users/{userid}/password-reset从 HTTP 的角度来看，这是有意义的，因为您可以发出
GET 资源上并接收指示如何执行密码重置的信息（例如提示输入关联帐户的电子邮件地址的 HTML 表单）。编辑：
出于电子邮件验证的目的，有两个明显的选项。您可以使用电子邮件地址和确认数据
POST到“确认电子邮件”资源，要求服务器处理确认，或者您可以执行PUT来放置服务器上的确认信息：POST /users/{userid}/confirm-email或
PUT /users/{userid}/email-confirmationFirstly, I don't think that
PUTis the right method for this.PUTbroadly means "put this here", where the URL is identifying where the content should be located. You're really asking an existing resource to perform some action, which makesPOSTmore correct.To answer your direct question, a RESTful URL should identify the resource you want to handle your request. In this case, the resource is either the user, or some password-resetting resource within the user.
My preference would be for a password-resetting resource:
POST /users/{userid}/password-resetThis makes sense from a HTTP point of view, since you could issue a
GETon the resource and receive something which indicates how to action a password reset (e.g. a HTML form prompting for the email address of the associated account).EDIT:
For the purposes of email validation, there are two obvious options. You could either
POSTto a "confirm email" resource with the email address and confirmation data, to ask the server to process the confirmation, or you can execute aPUTto put the confirmation information on the server:POST /users/{userid}/confirm-emailor
PUT /users/{userid}/email-confirmation这是一种 RESTful 方式。
请求
响应
URI 中不需要动词:)
Here is a RESTful way.
Request
Response
No verbs in the URI needed :)
我真的不认为像第一个例子那样使用confirmEmail有什么问题。在 URL 中，您拥有用户的密钥，confirmEmail 是操作，并且具有该操作的数据位于查询字符串中。
I don't really see anything wrong with having confirmEmail like the 1st example. In the URL you have the key to the user, confirmEmail is the action, and the data with that action is in the query string.