2

我有一个用户：

GET /user/1 -> {id:1,name:"john"}

我的授权引擎确保任何人都可以GET /user/1，但PUT /user/1或PATCH /user/1仅限于约翰本人或系统管理员。

如何处理只能由管理员修改的用户部分？例如，如果我有一个属性blocked，它决定是否允许用户登录？出于显而易见的原因，john 应该无法更改他的阻止状态，只有管理员才能更改。

我看到两种方法可以做到这一点：

  1. 使权限成为一个完全独立的资源，可以在/permissions/:user或访问/user/:user/permissions，并且只允许管理员访问该路径。因此PUT，PATCH为了/user/:user可以随心所欲地更改用户，它实际上只修改用户可修改的数据，而/permissions管理员可修改的数据
  2. 将权限内置到用户对象中，但在PUTorPATCH处理程序中执行逻辑以防止管理员以外的任何人修改它。

选项 2 保持用户对象不变，而选项 1 允许我完全封装和分离用户或管理员可以更改的数据和只有管理员可以更改的数据。

4

1 回答 1

0

PUT 和 PATCH 请求之间的区别体现在服务器处理封闭实体以修改由 Request-URI 标识的资源的方式上。在 PUT 请求中，包含的实体被认为是存储在源服务器上的资源的修改版本，并且客户端请求替换存储的版本。然而，对于 PATCH，封闭的实体包含一组指令，描述如何修改当前驻留在源服务器上的资源以生成新版本。PATCH 方法会影响 Request-URI 标识的资源，也可能对其他资源产生副作用；即，可以通过应用 PATCH 创建新资源或修改现有资源。

根据PATCH 方法定义。

我没有找到任何关于如何定义完整和部分术语的信息，所以这可能取决于你。因此，在实际的身份验证上下文中，完整可能意味着当前用户可以访问的所有内容，而部分可能意味着不完整。

因此，当您的用户无法修改权限时，如果您没有在 PUT 中发送权限，则没有任何问题，只是一个管理员。

因此，权限既可以是子资源，也可以是单独的资源，甚至可以是单独的安全服务的一部分。

于 2013-12-02T11:18:00.153 回答