Nest Boot v8 原生 RLS

使用 MikroORM 的 @Entity({ policies }) 与 EntityManager session。

Policy 与数据库角色

• 用 Entity 的 policies 作为源定义，按需配置 command、roles、using、check 和 type；name 可省略，由 MikroORM 自动生成。command/type 是小写字面量，例如 select、all、restrictive。
• 一个或多个 policy 会默认启用 RLS；必要时显式设置 rowLevelSecurity: true 或 'force'。SQL 权限与 RLS 是两层约束，roles 和 GRANT 要由部署/初始化迁移单独配置；policy 不会创建角色或授予表权限。
• 默认 permissive policies 以 OR 合并；restrictive policies 与允许集合以 AND 合并。显式选择命令，避免把只读规则意外扩展到 all。
• 表所有者通常绕过 RLS，superuser/BYPASSRLS 也可绕过；业务验证使用真实受限角色。不要以管理员连接的成功查询证明隔离有效。
• RLS 表达稳定的行归属。动作权限、API-key 权限交集与可写字段继续由 Service/Ability 校验，不能只靠一条 workspace policy。

身份与 session

Auth 使用 app.user.id、app.workspace.id、app.member.id；空身份值是空字符串。服务账户可以有 member 而没有 user，用户会话也可以登录但未选择 workspace。不要把 app.member.id 当成所有已登录请求必有字段，也不要把请求头里的 workspace ID 当作成员资格证明。

DatabaseModuleOptions.session 是可选的同步工厂，可为每次 RequestContext 的 EM fork 提供初始 session（例如匿名角色），在 HTTP 认证之前运行；不配置时 DatabaseModule 不会自动添加匿名角色。使用 Auth 时，让认证流程维护最终身份；自定义授权入口应先验证身份和成员关系，再设置范围。业务自定义变量使用一致的完整命名，例如 app.tenant.id。