【问题标题】:PUT or PATCH to change only one field valuePUT 或 PATCH 仅更改一个字段值
【发布时间】:2015-05-20 16:03:56
【问题描述】:

我正在考虑创建一个 API 供用户更改密码。
用户表有一些字段,如名字、姓氏等。 对于这个 API,我应该像下面这样使用 PATCH 吗?

PATCH /users/{userId}

{
  "password": "new_password"
}

或者,我应该使用 PUT 吗?

PUT /users/{userId}/{password}

这对于安全性来说似乎很糟糕。

顺便说一句,我不希望用户更改其他字段的值。我认为 PATCH 必须让用户能够更改任何字段的值。这就是我想知道的原因。

【问题讨论】:

    标签: rest restful-url http-1.1


    【解决方案1】:

    路径信息和查询字符串将使用 HTTPS/TLS 加密 - 用于该 HTTP 会话。但是,将密码放在那里仍然不是一个好主意,因为它们很可能在浏览器历史记录和/或服务器日志中

    PUT /users/{userId}/{password}
    

    ... 将保留在 Web 服务器日志中。作为安全开发人员,我们甚至不应该将密码存储在可能被盗的数据库中(我们要存储密码的哈希值和盐值)。在 Web 服务器日志中使用明文密码更糟糕。

    在 TLS 会话中将其发送到正文中是最好的。

    PATCH /users/{userId}
    {
      "password": "new_password"
    }
    

    ...然后对其进行哈希+加盐并存储。登录时,您执行相同的过程(单向哈希匹配)。

    看到这个:HTTPS, URL path, and query string

    【讨论】:

      【解决方案2】:

      从安全 POV 来看没有区别。攻击可以读取查询字符串和请求正文。您应该使用 TLS。

      我觉得这两个请求都很好。它们的 URL 和它们的主体是良好、可靠的 REST。

      如果您不想接受对所有字段的更改,请在您的服务器中编写逻辑来拒绝尝试更改用户不应更改的字段的请求。但这不是PUTPATCHPOST 的问题。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2013-04-05
        • 1970-01-01
        • 2021-10-29
        • 2020-01-09
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2021-12-27
        相关资源
        最近更新 更多