项目组成

我正在做一个由两个前端应用程序组成的项目，这些应用程序请求一个后端REST-API。
我们的应用程序的组织目前非常简单，但它很快就会发展。

前端：

• Web应用程序（React）
• 移动的应用（React Native）
  后台：
• API REST（Ruby RoR中）。

访问策略问题

• 背景：*
• • 前端应用需要知道给定用户的UI的哪些部分应该根据访问策略显示。*
• • 我们似乎有一个RBAC + ABAC的混合模型 *

目前，我们没有一个清晰的架构来管理访问策略，业务逻辑分布在两个应用程序中，这导致了几个问题：

*后端+前端的访问策略代码重复（因此，我们可能最终会在同一策略的代码库的3个不同部分中重复相同的代码）。
***前端复杂条件：**在某些情况下，我们需要获取多个实体来决定用户是否可以访问某个功能。

解决方案

我最初的想法是将访问策略逻辑集中在API上。这样我们就可以防止重复，所有规则都在代码库的一部分中，如果我们以后决定添加前端应用程序甚至API微服务，它也会更好地扩展。
缺少的一点是：如何在后端和前端之间共享访问策略？

• 从一个API端点公开这样的配置是一个好的约定吗？

示例如下：

route: GET /user/access_policies
response :

{
  author: {
    read: true,
    create: true,
    update: false,
    delete: false
  },
  books: {
    read: true,
    create: true,
    update: true,
    delete: false,
  }
}

字符串
我还可以在简单的CRUD动词之外公开特定的业务策略：

{
  books: {
    read: true,
    create: false,
    update: false,
    delete: false,
    deleteOwnBooks: true, // custom business policy (only delete the books owned by the current user)
    deletePublishedBook: true, // same

  }
}

型
关于共享此类访问策略，您是否有其他建议或最佳做法？

编辑（2023年12月5日）

我们最终采用了以下解决方案：在User资源上公开全局权限。

type User = {
  id: string
  permissions: {
    author: {
      read: boolean,
      create: boolean,
      update: boolean,
      delete: boolean
    },
    books: {
      read: boolean,
      create: boolean,
      update: boolean,
      delete: boolean // Your user role allow you to delete books
    }
  }
}

型
为了启用细粒度的资源权限，我们直接从指定的资源公开它们。

type Book = {
  id: string
  name: string
  permissions: {
    // Can only delete own books
    // Can only delete published books
    delete: boolean
  }
}

型
目前，这种模式很适合我们的需求。但是，需要注意的一个方面是性能，因为它引入了额外的计算。通常，我们通过使用Rest API中的专用查询参数按需查询权限来解决这个问题。