Hasura GraphQL Engine 中隐藏字段与关系权限的深度解析

在基于Hasura构建GraphQL服务时，开发者常会遇到一个典型场景：需要利用某些敏感字段（如支付相关的ID）作为关系查询的桥梁，但又不希望将这些字段直接暴露给客户端。本文将以用户与Stripe支付系统的集成案例为切入点，深入探讨权限控制与关系查询的平衡之道。

核心问题场景

假设我们有一个用户表，包含id和stripe_customer_id等字段，需要实现以下功能：

1. 通过GraphQL查询用户关联的Stripe客户信息
2. 查询用户的支付方式列表
3. 但要求前端不能直接获取stripe_customer_id字段

在Hasura中直接配置关系映射时，如果从角色权限中移除了对stripe_customer_id字段的访问权限，相关的关系查询也会随之失效。这是因为Hasura默认的安全机制会阻止基于不可见字段的关系解析。

技术解决方案比较

方案一：保留字段可见性（不推荐）

最简单的做法是保持stripe_customer_id对角色可见，但这违反了最小权限原则，可能带来安全隐患。

方案二：参数预设（推荐方案）

Hasura提供了ArgumentPresets功能，允许将会话变量（如用户ID）自动映射为命令参数。这种方案完全避免了暴露底层字段：

permissions:
  - role: user
    fields: [id, name] # 不包含stripe_customer_id
    commands:
      GetCustomersCustomer:
        argumentPresets:
          id: "X-Hasura-User-Id" # 使用会话变量

方案三：自定义解析器（高级方案）

对于复杂场景，可以创建自定义解析器，在服务端获取所需字段后构建查询参数。这种方式虽然灵活，但增加了实现复杂度。

架构设计建议

1. 分层权限设计：将字段权限与命令权限解耦，关系解析应视为服务端行为而非客户端权限
2. 敏感信息隔离：支付相关ID等字段建议存储在单独的表或扩展表中
3. 查询性能考量：ArgumentPresets方案可能需要在命令中实现额外的用户ID到支付ID的转换逻辑

最佳实践

对于支付系统集成类场景，建议采用以下模式：

1. 使用会话变量作为查询锚点
2. 在业务逻辑层维护ID映射关系
3. 通过Hasura的远程Schema或Actions机制实现复杂授权逻辑
4. 对支付相关查询实施严格的速率限制

通过合理设计权限模型和查询结构，可以在保证系统安全性的同时，提供完整的业务功能支持。Hasura强大的权限系统与灵活的扩展能力，为这类敏感数据场景提供了多种解决方案。