在Supabase的私人多租户证据工作流程上, 该项目是从一个非常具体的问题开始的: 在不公开文件、不泄露租户数据或不在整个应用中重复授权逻辑的情况下,如何将照片、文件或其他证据附加到商业对象?
该工具包有意使基础设施规模小并具有可知性。
它目前提供:私人Supabase存储;从文件字节中分离出的证据元数据;与行级安全局的租户隔离;短寿命的签名URL;在元数据持续存在失败时补偿清理;租户会员和证据授权的参考迁移.
但最新发行的有趣部分并不是最初的落实.
这是审查循环。
社区审查发现,我与Supabase社区分享了该项目,并收到了详细的安保审查。
反馈提出了几个重要问题:角色存在,但授权仍然过于接近于平员;删除证据需要更明确的特权界限;缺乏UpDATE支持需要故意而非偶然;围绕",表主"的RLS假设需要记录;授权需要行为测试,而不仅仅是静态的SQL断言.
这些反馈已经足够好, 我把它变成一个执行的任务。
使用 Codex 作为执行循环, 而不是问 Codex 类似“改善安全”之类的问题。
我给了它一个范围很窄的问题,有明确的接受标准。
工作流程变为:社区审查 范围问题 守则执行 人文审查 修正通过 – CI – 发布 第一次执行是有益的,但审查仍然发现问题。
例如,它最初改变了现有的INSERT行为,只修改了最初的迁移,不会安全地升级已经应用过它的设施.
所以任务又回到了另一个通道。
第二道通行证产生了我真正想要的版本. v0.1.3 租户证据箱中的变化现在包括:特定操作证据权限;仅限于和.删除证据;为活跃成员保留现有读取/创建行为;明确附加的证据元数据;现有设施的单独迁移;真实的Supabase/pgTAP授权测试;数据库授权的CI覆盖;RLS执行边界的明确文档,包括表格所有者和.
存储和Postgres现在对证据操作使用相同的许可模式.
目标不是建立一个大型授权框架。
其目的是使现有的安全边界更加明确、可检验和升级安全。
我学到一件事 这里使用代理最有用的部分不是代码生成.
它给了代理商一个可审查的工程界限.
象“使这种安全性更强”这样的模糊要求为解释留下了太多的余地。
任务有: 保存当前读取/创建行为; 限制敏感删除; 添加升级迁移; 以行为测试证明授权模式; 记录 RLS 绕行边界; 更容易评价.
人类审查步骤仍然重要。
很多东西 Links GitHub: https://github.com/oitydob-crypto/tenant-evidence-kit npm: https://www.npmjs.com/package/tenant-evidence-kit 当前发布:v0.1.3.
我很想听听其他开发商如何安排代理任务.