【问题标题】:REST API Endpoint for changing email with multi-step procedure and changing passwordREST API 端点,用于通过多步骤过程更改电子邮件和更改密码
【发布时间】:2017-12-21 19:06:42
【问题描述】:

我需要帮助来创建 REST 端点。有几个活动:

要更改电子邮件,需要 3 个 URL 请求:

  1. /changeemail : 这里一次性密码 (OTP) 被发送到用户的手机

  2. /users/email : 用户发送上一步的一次性密码,系统发送邮件给新用户点击邮件激活链接

  3. /activateemail : 用户点击新邮件收件箱中的链接,服务器更新新邮件

修改密码:

  1. /users/password (PATCH) : 用户提交旧密码和新密码,系统相应更新新密码

同样,还有其他端点可以更改个人资料(字段包括生日、名字和姓氏)

在线阅读后,我相信我的系统只有 users 作为资源 --> 所以为了更新我正在考虑使用单个 PATCH 更改电子邮件和更改密码的属性以及类似操作字段的内容,所以以上两个功能看起来像:

换邮箱:

  1. 操作:'sendOTPForEmailChange'
  2. 操作:'sendEmailActivationLink'
  3. 操作:'activateEmail'

修改密码:

  1. 操作:“更改密码”

对于上述所有操作,我将只有一个端点(在 nodejs 中):

app.patch('/users', function (req, res) {
  // depending upon the operation I delegate it to the respective method
   if (req.body.operation === 'sendOTPForEmailChange') {
       callMethodA();
   } else if (req.body.operation === 'sendEmailActivationLink') {
     callMethodB();
   } else if (req.body.operation === 'activateEmail') {
      callMethodC();
   } else if (req.body.operation === 'changePassword') {
      callMethodC();
   } else sendReplyError();

});

这听起来是个好主意吗?如果没有,有人可以帮我形成 changeemail 和 changepassword 的端点。

回答

我最终决定在 HTTP 请求正文中使用带有操作字段的 PATCH 来指示必须执行的操作。 因为我只修改了资源的一个字段,所以我使用了 PATCH 方法。 另外,我想避免在 URI 中使用动词,因此使用“操作”字段看起来更好。

我在做这个决定时参考了一些参考资料:

威尔茨回答link here

马克诺丁汉的博客link article

最后是 JSON MERGE PATCH link RFC

【问题讨论】:

  • 我正在使用带有路由、控制器和模型的 nodejs,并且有一个用于更改生成的电子邮件请求代码的数据库,这些代码作为电子邮件发送给用户。上面的例子在路由和控制器方面会是什么样子
  • 即使是编辑配置文件,我也会使用相同的端点,如 /users/:user_id 和操作:getProfile。

标签: node.js rest api


【解决方案1】:

大部分同意 Ghulam 的回复,关注点分离是关键。我建议略有不同的端点如下:

1. POST /users/otp      -> as we are creating a new OTP which should be returned with 200 response. 
2. POST /users/email    -> to link new email, request to include OTP for verification. 
3. PUT  /users/email    -> to activate the email.
4. PUT  /users/password -> to update users password.

【讨论】:

  • 你是对的,但我不同意这个链接,因为它没有描述资源本身,它应该描述它将执行验证 otp 和发送密码电子邮件的操作。 users/email 没有描述它将为密码和任何指向 otp 的链接生成电子邮件
  • @Deven:请查看我对 Ghulam 的回答。
【解决方案2】:

您应该创建定义特定资源的链接,避免使用 PATCH 并将所有逻辑添加到一个链接中,以保持简单并在 API 中使用关注点分离 像这样

1- /users/otp with HTTP Verb: GET -> to get OTP for any perpose
2- /users/password/otp with HTTP Verb: POST -> to verify OTP for password and sending link via email
3- /users/activate with HTTP Verb: POST to activate the user
4- /users/password with HTTP Verb: PUT to update users password

【讨论】:

  • 我认为在 URI 中使用动词不是一个好主意,例如- 启用。此外,对于密码,有两种情况,例如更改密码(用户记住旧密码)和重置密码(用户不记得旧密码),因此 URI '/users/password' 不会有太大帮助。我决定使用补丁,因为我只更新了资源“用户”的一部分,在这里查看 Selvamani 的答案:link here
  • 我使用 PATCH 进行所有操作,并在请求正文中添加了一个操作字段。类似于 JSON Merge Patch link here 的概念
  • 我认为你应该阅读这篇PATCH不是为了这个目的“PUT和PATCH请求的区别体现在服务器处理封闭实体以修改Request-URI标识的资源的方式上. 在 PUT 请求中,封闭实体被认为是存储在源服务器上的资源的修改版本,并且客户端请求替换存储的版本。但是,对于 PATCH,封闭实体包含一组指令描述如何修改当前驻留在源服务器上的资源以生成新版本”
  • 你只是在修改资源你并没有告诉服务器如何修改这个资源,PATCH是一种告诉服务器如何修改特定资源的方法
  • 我相信在 PUT 中您将不得不共享整个资源表示,并且它将在服务器上被旧的资源表示完全替换。对于 PATCH,您提到了您要修改的内容,并且仅更改了该部分(以节省带宽)另外,请查看 Wilt 在 cmets 中的回答 link here,我们同意该操作应该是 PATCH 而不是 PUT。
【解决方案3】:

Hashing Security 是必读的,恕我直言,如果您想实现自己的用户帐户系统。
应始终考虑两因素识别,至少作为选择加入的功能。您将如何将其集成到您的登录方案中?
身份联盟呢?您的用户可以利用他们的社交帐户来使用您的应用吗?

快速浏览一下 Google 产生了 this and this, as well as this

除非您有充分的理由自己做,否则我会花时间集成一个由强大社区支持的解决方案,用于项目的实用性方面,并将我的时间集中在为您的客户实现业务价值上。

注意:我的文字对于 cmets 来说太长了

【讨论】:

  • 感谢 Sumi 分享链接。我正在使用 bcrypt,目前我们不考虑社交媒体帐户。 Sumi,如果你的 cmets 很长,你应该把它们分开,因为如果没有人回答这个问题 - 赏金将奖励给你,你的回答对我的问题没有帮助。
  • 我理解您对评论的看法,但我不同意我的回答对您没有帮助这一事实。我向您指出了一个图书馆交互方向,很多人都会同意这是更好的方法,因为您可以专注于您的核心业务并依赖一个解决常见问题的社区。至于 bcrypt,目前最先进的是 Argon,它赢得了哈希算法竞赛。但是,我会使用 PBKDF2 和 SHA256 或 SHA512,因为它经过了实战测试。这个经过时间检验的论点在安全方面很重要(你还记得 HeartBleed 吗?)
  • Sumi,SO 社区早些时候建议我使用标准的 Auth Provider Service,但它们似乎很昂贵。因为,我们决定至少在开始时自己实现它——我一直在寻找问题的答案。也许我应该在问题中澄清这一点。你分享的知识绝对有帮助:)
  • 上下文很重要。
猜你喜欢
  • 2012-06-24
  • 2014-12-02
  • 1970-01-01
  • 2014-01-16
  • 2018-01-07
  • 2019-11-04
  • 2017-06-23
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多