我想了解如何处理REST API中的授权，端点如下
GET /resource/:idDELETE /resource/:idGET /resource
假设
- 用户Bob通过认证。
- Bob只拥有id为
1,2,4,5,6但3的资源 - 系统具有访问控制层和业务逻辑层
- 业务层没有任何数据所有权的意识
- 访问控制层对
resources和users有policies，可以检查用户是否有权限访问资源和使用HTTP403拒绝请求或将其传递给业务逻辑待处理层
场景
- Bob向
GET /resource/2发送请求，应用程序返回HTTP 200的资源详细信息 - Bob向
DELETE /resource/3发送请求，应用程序返回HTTP 403。 - Bob发送一个请求来列出资源
GET /resources?page=1&pageSize=10，应用程序返回1,2,4,5,6但是3的资源摘要
问题
访问控制层可以通过使用定义的策略检查用户对给定资源的声明来阻止(403)访问特定资源。但是在访问搜索端点时不应该被阻止(403)。
方法1
- 可以假设搜索将包括不属于经过身份验证的用户的资源摘要。
方法2
- 搜索端点可以完全分离，具有资源所有权意识，并负责解析所有权和过滤。
- 其他端点保持干净，只有业务逻辑。
问题
- 哪种方法更好?
- 有其他选择吗?
- 我是否混淆了数据所有权、访问控制和业务逻辑的概念?
我认为你把这些概念混在一起了。让我们从头开始:
如果一个特定的用户(在本例中是Bob)通过了身份验证，并且他的身份验证记录有一个策略，该策略定义了对一组特定资源的访问(或定义了对一组特定资源的访问阻止)，那么该状态应该是prevent。为什么?
Bob被阻止访问特定的资源。FILTERED表示过滤数据，即使Bob可以访问数据，您也可以这样做。当Bob接收到200个OK状态和他想要的记录时，API的内部功能仍然可以过滤数据，这些数据将适应Bob身份验证记录所持有的策略。
如果我们的数据库中有这样一组记录:[1,2,3,4,5,6,7,8,9,10]如果我们想要创建策略来阻止某些用户访问特定的记录那么我们可以在描述记录的方式中设置策略来定义特定用户的访问权限。例如，策略可以定义一个数组([3])中保存数字3的记录，基于此，我们可以创建一个逻辑，明显地过滤掉数组中的数据并返回[1,2,4,5,6,7,8,9,10]。
然而，这个模型在很大程度上取决于数据的结构。在设计策略记录之前可能想要问自己的问题:
- 我的记录结构如何?他们有记录/表，我可以拆分我的数据?如果是这样，我可以定义
<COLLECTION/TABLE_NAME>:<ACCESS_LEVEL>，在这种情况下会生成numbers:*或numbers:[1,2,4,5,6,7,8,9,10]。 - 我可以保存我的记录所需的访问权限吗?通常的做法是将所需的访问定义保存在所保存数据的记录或相关记录中。例如:
access_needed: [ "read", "write" ]
同样，这一切都归结于您的记录，并在此基础上构建如何定义策略格式。