Cerberus验证期间禁用readonly权限的实现方案咨询

首先明确：管理员确实可以绕过readonly限制，但递归遍历Schema把所有readonly设为False是比较粗暴的做法，有更优的方案可以参考：

1. 基于角色的Schema变体 #

不要直接修改原始Schema，而是为管理员生成一个专属的Schema副本：

• 写一个工具函数，接收原始Schema和当前用户角色，当用户是管理员时，返回移除了readonly约束的Schema副本（注意操作副本，绝不修改原始Schema）
• 这样既保留了普通用户的readonly限制，又给管理员开了合法的权限通道，还不会污染原始Schema的定义

示例代码（以JSON Schema为例）：

function getSchemaForRole(originalSchema, userRole) {
  if (userRole !== 'admin') return originalSchema;
  
  // 深拷贝原始Schema，避免修改原数据
  const adminSchema = JSON.parse(JSON.stringify(originalSchema));
  // 递归移除readonly约束
  function stripReadOnly(schemaNode) {
    if (schemaNode.readonly) delete schemaNode.readonly;
    if (schemaNode.properties) {
      Object.values(schemaNode.properties).forEach(stripReadOnly);
    }
    if (schemaNode.items) {
      stripReadOnly(schemaNode.items);
    }
  }
  stripReadOnly(adminSchema);
  return adminSchema;
}

2. 验证阶段的条件跳过 #

如果你的验证库支持条件逻辑扩展，可以在验证环节针对管理员跳过readonly检查：

• 比如使用AJV这类验证器时，自定义readonly关键字的验证逻辑，当用户是管理员时直接返回验证通过
• 这种方式不需要修改Schema本身，而是在验证层面做灵活的权限适配

示例（AJV自定义验证逻辑）：

const ajv = new Ajv();
// 重写readonly关键字的验证规则
ajv.addKeyword('readonly', {
  validate: function(isReadonly, data, ctx) {
    // 管理员直接跳过readonly校验
    if (currentUser.role === 'admin') return true;
    // 普通用户执行原有的readonly约束逻辑
    return isReadonly ? false : true;
  }
});

3. 权限前置的数据过滤 #

在Schema验证之前，先根据用户角色处理提交的数据：

• 对普通用户，过滤掉所有readonly字段的修改请求；对管理员，允许提交全部字段
• 这种方式和Schema验证配合使用，管理员的数据直接走完整验证流程，完全不需要修改Schema

示例（后端Python处理逻辑）：

def process_config_submission(submit_data, user_role):
    if user_role != 'admin':
        # 从Schema中提取readonly字段列表，过滤普通用户的修改请求
        readonly_fields = extract_readonly_fields(config_schema)
        submit_data = {k: v for k, v in submit_data.items() if k not in readonly_fields}
    # 执行标准Schema验证
    validate(submit_data, config_schema)
    # 后续保存配置逻辑...

为什么不推荐递归修改原始Schema？ #

• 会污染原始Schema的定义，可能导致普通用户的验证流程出现权限漏洞
• 缺乏可维护性：如果Schema后续更新，递归修改的逻辑需要同步调整，容易遗漏
• 不符合权限分离的设计原则：应该通过角色区分权限范围，而不是直接破坏约束本身

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