将Headless CMS融入技术生态的架构与权限控制咨询

一、将CMS融入已有技术生态（含现有认证系统）的可行方案 #

• 认证前置：用API网关/反向代理隔离认证逻辑
  把CMS的API部署在已有API网关之后，所有访问CMS的请求先经过网关的认证校验（复用你现有系统的token验证、用户身份校验逻辑），校验通过后再转发到CMS。这种方式下CMS完全不需要处理认证，只负责内容的存储和查询，完美符合关注点分离原则。
• CMS自定义认证中间件
  像Strapi、Payload这类CMS都支持自定义认证中间件，你可以把现有系统的token解析、用户身份获取逻辑写成中间件挂载到CMS上。CMS只需要验证token的有效性，用户信息直接从中间件传递过来，不用在CMS里存储用户数据，避免重复开发认证逻辑。
• 新增内容聚合服务层
  在业务服务和CMS之间加一层内容聚合服务，这层服务的职责是：接收业务服务的请求，调用现有认证系统校验用户权限，再根据权限规则从CMS拉取对应内容并组装成内容树。业务服务只和这层交互，CMS依然专注内容存储。

二、支持细粒度内容项权限的开源CMS及实现思路 #

你提到的Strapi、Payload其实都支持内容项级别的权限控制，只是需要自定义配置，并非只能到集合/内容类型级别：

• Payload
  通过access控制函数可以实现细粒度权限。比如在内容模型的read权限函数中，获取请求上下文里的用户已购买产品列表（由前置认证逻辑注入），然后判断当前内容项关联的产品是否在用户的已购买列表中，返回true或false来控制访问。而且可以把权限判断的通用逻辑抽成单独的工具函数，避免重复代码。
• Keystone
  支持基于内容项属性的细粒度权限规则，你可以在权限配置中，针对内容项的产品关联字段设置规则，比如只允许用户访问关联产品包含其已购买产品的内容项。同时Keystone支持集成外部JWT认证，直接复用现有系统的token，不用在Keystone中管理用户。
• Directus
  权限系统原生支持字段级和内容项级控制，并且可以通过JWT、OIDC等方式集成外部认证系统。你可以在Directus中给内容项添加可见产品字段，然后配置权限规则，只允许用户访问可见产品包含其已购买产品的内容项。

针对你的内容树与产品绑定、跨产品共享的场景，具体实现步骤可以是：

1. 在CMS的内容模型中添加关联产品字段（多对多或数组类型），标记该内容项属于哪些产品的内容树。
2. 前置认证逻辑在请求头中注入用户的已购买产品列表。
3. 在CMS的权限函数中，对比内容项的关联产品和用户的已购买产品列表，只要有交集就允许访问。
4. 保留现有API：让现有API作为业务入口，API先调用认证系统校验用户身份和已购买产品，再带上用户权限信息调用CMS的API拉取内容，或者调用中间层的内容聚合服务组装内容树。

关于关注点分离的补充 #

CMS确实应该专注于内容存储和基础RBAC，但细粒度的内容项权限属于内容访问控制范畴，放在CMS的权限扩展逻辑中是合理的——关键是要把用户认证和内容权限判断解耦：认证由你现有系统负责，CMS只根据传递过来的用户权限上下文（比如已购买产品列表）判断是否允许访问内容项，这样既不会重复开发认证逻辑，也符合关注点分离的原则。

内容的提问来源于stack exchange，提问作者Max