如何对资源上可见数据的限制进行建模? [英] How to model restrictions on data visible on resources?

问题描述

如何对资源上可见数据的限制进行建模?不同的人访问相同的资源，但具有不同的角色，因此他们无法查看所有信息.

How to model restrictions on data visible on resources? Different people are accessing the same resources but with different roles so they are not allowed to see all the information.

我正在处理的案例:
没有信息访问限制的解决方案:

The case I am working on:
Solution without access restriction on information:

User:
  name
  phoneNumber

如果任何人都可以访问它，这将很容易建模为:

If anyone could access it this would be easy to model as:

GET /User -> [{name:"John", phoneNumber: "322-333"}]
GET /User/{id} -> {name:"John", phoneNumber: "322-333"}

但是，假设我有两个角色，管理员和用户.phoneNumber 只能对同时也是管理员的用户可见.授权令牌在 cookie、标头或类似物中传输.服务器将知道请求者具有哪些角色.如何设计一个 API 来处理这个问题?我有几个想法:

However, say I have two roles, admin and user. The phoneNumber must only be visible to users who are also admins. Authorization token is transmitted in a cookie, header or similar. The server will know which roles a requester has. How would one design an API to handle this? I have a couple of ideas:

1) 天真的解决方案是过滤它并在不允许您访问它的情况下不设置字段.

1) The naive solution would be to just filter it and leave the fields unset if you arent allowed to access it ie.

If user: GET /User -> [{name:"John"}]
If admin: GET /User -> [{name:"John", phoneNumber: "322-333"}]

2) 在 url 中嵌入角色:

2) Embed the role in the url:

If user is wanted as a User: GET /User/User -> [{name:"John"}]
If user is wanted as an Admin: GET /Admin/User -> [{name:"John", phoneNumber: "322-333"}]

3) 为每个可能的字段子集定义一个新资源:

3) Define a new resource for each possible subset of fields:

If user is wanted as a User:   GET /PublicUserInfo -> [{name:"John"}]
If user is wanted as an Admin: GET /FullUserInfo -> [{name:"John", phoneNumber: "322-333"}]

采用不同的方法会更好吗?
有没有人有过实践中行之有效的解决方案的经验?

Would a different approach be better ?
Does anyone have experience with a solution that worked out in practice?

推荐答案

根据经过身份验证的用户使用选项 1.如果您选择 2 或 3 个客户端来实现您的 API，则必须担心两倍于任何 API 端点以及何时应该使用它们.

Use option 1 based on the authenticated user. If you opt for 2 or 3 clients implementing your API have to worry about twice as any API endpoints and when they should be used.

这篇关于如何对资源上可见数据的限制进行建模?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！