specsfy-specialist-supabase

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Supabase

Quando usar

适用场景

Acionar quando o projeto tem
```
supabase/config.toml
```
, migrations em
```
supabase/migrations/
```
, ou clientes
```
@supabase/supabase-js
```
e a tarefa envolve RLS, Auth, Storage, Realtime, Edge Functions ou ambiente local Supabase (
```
supabase start
```
).
Acionar também para revisão de política de acesso, policy RLS ausente ou incorreta, ou exposição indevida de
```
service_role
```
.
Não acionar para tuning puro de índice/plano/isolation do Postgres subjacente sem o contexto Supabase — usar
```
$specsfy-specialist-postgres
```
e trazer o resultado de volta para as policies.
Combinar com
```
$specsfy-specialist-application-security
```
quando a revisão envolver JWT, claims customizadas ou superfícies de autorização fora do banco.

当项目包含
```
supabase/config.toml
```
、
```
supabase/migrations/
```
下的迁移文件，或
```
@supabase/supabase-js
```
客户端，且任务涉及RLS、Auth、Storage、Realtime、Edge Functions或Supabase本地环境（
```
supabase start
```
）时触发。
当需要审查访问策略、缺失或错误的RLS policy，或
```
service_role
```
不当暴露时也可触发。
若仅针对底层Postgres进行索引/执行计划/隔离级别调优且无Supabase上下文，请勿触发此类任务——应使用
```
$specsfy-specialist-postgres
```
，并将结果应用到相关policies中。
当审查涉及JWT、自定义claims或数据库外的授权面时，需结合
```
$specsfy-specialist-application-security
```
。

Fluxo

流程

Identificar SDK usado (
```
@supabase/supabase-js
```
,
```
ssr
```
, framework específico), projeto, schemas expostos via API, migrations existentes e estratégia de ambientes (local, preview, produção).
Mapear identidades, tenants, papéis (
```
anon
```
,
```
authenticated
```
, papéis customizados) e a origem de cada claim usada em decisão de acesso (
```
auth.uid()
```
,
```
auth.jwt()
```
, metadata).
Modelar tabelas, funções e views no Postgres primeiro — a API REST/ GraphQL e os tipos gerados são derivados do schema, não o contrário.
Definir privilégios (
```
GRANT
```
) para o objeto e políticas RLS para cada operação (
```
SELECT
```
,
```
INSERT
```
,
```
UPDATE
```
,
```
DELETE
```
) e papel, negando por padrão.
Implementar a migration versionada e testar com usuários representativos de cada papel, incluindo o caso sem sessão (
```
anon
```
).
Validar Auth, Storage, Realtime ou Edge Functions apenas quando o projeto de fato os usa — não configurar superfície que a aplicação não expõe.
Verificar tipos TypeScript gerados, estratégia de pooling (session vs transaction), logs e política de backup/rollback antes de considerar pronto.

识别使用的SDK（
```
@supabase/supabase-js
```
、
```
ssr
```
、特定框架）、项目、通过API暴露的schemas、现有迁移文件及环境策略（本地、预览、生产）。
映射身份、租户、角色（
```
anon
```
、
```
authenticated
```
、自定义角色），以及访问决策中使用的每个claim的来源（
```
auth.uid()
```
、
```
auth.jwt()
```
、元数据）。
先在Postgres中建模表、函数和视图——REST/GraphQL API及生成的类型均派生自schema，而非反之。
为对象定义权限（
```
GRANT
```
），并为每个操作（
```
SELECT
```
、
```
INSERT
```
、
```
UPDATE
```
、
```
DELETE
```
）和角色设置RLS policies，默认拒绝所有访问。
实现版本化迁移，并使用各角色的代表性用户进行测试，包括无会话场景（
```
anon
```
）。
仅当项目实际使用Auth、Storage、Realtime或Edge Functions时才进行配置验证——不要配置应用未暴露的访问面。
在确认完成前，检查生成的TypeScript类型、连接池策略（session vs transaction）、日志及备份/回滚策略。

Padrões

最佳实践

Habilitar RLS em toda tabela de schema exposto à API e negar por padrão — tabela com RLS desabilitada em schema público é acessível por qualquer
```
anon
```
que descubra o nome.
Nunca expor
```
service_role
```
no cliente (browser, app mobile, bundle público); ela ignora RLS e só pertence a ambiente de servidor confiável.
Testar cada policy separadamente para
```
anon
```
,
```
authenticated
```
e qualquer papel de aplicação — uma policy que "parece" restringir mas usa
```
USING (true)
```
equivale a não ter policy.
Tratar como superfície crítica: funções
```
SECURITY DEFINER
```
(rodam com privilégio do dono, não do chamador — precisam de
```
search_path
```
fixo e validação interna própria), claims customizadas no JWT (podem ser manipuladas se a fonte não for confiável) e buckets de Storage marcados como públicos.
Versionar toda mudança de schema em migration (
```
supabase migration new
```
); edição manual no dashboard de produção diverge do histórico e quebra
```
supabase db diff
```
/CI.
Separar autorização de produto (o que este usuário pode fazer com este registro) da mera autenticação (quem é o usuário) — RLS resolve a primeira, Auth resolve a segunda.
Planejar conexão direta (poucas conexões persistentes, migrations), session pool (compatibilidade ampla,
```
PREPARE
```
funciona) ou transaction pool (alta concorrência, serverless) conforme o workload e o driver.

对所有暴露给API的schema中的表启用RLS并默认拒绝访问——公共schema中未启用RLS的表可被任何发现其名称的
```
anon
```
用户访问。
切勿在客户端（浏览器、移动应用、公开打包文件）中暴露
```
service_role
```
；它会绕过RLS，仅应在可信服务器环境中使用。
针对
```
anon
```
、
```
authenticated
```
及任何应用角色分别测试每个policy——使用
```
USING (true)
```
的policy等同于未设置任何policy。
将以下内容视为关键访问面：
```
SECURITY DEFINER
```
函数（以所有者权限而非调用者权限运行——需固定
```
search_path
```
并自行进行内部验证）、JWT中的自定义claims（若来源不可信则可能被篡改）、标记为公开的Storage buckets。
所有schema变更均通过迁移进行版本化（
```
supabase migration new
```
）；在生产仪表盘中手动编辑会偏离历史记录，导致
```
supabase db diff
```
/CI失效。
将产品授权（该用户可对该记录执行哪些操作）与单纯的身份验证（用户是谁）分离——RLS解决前者，Auth解决后者。
根据工作负载和驱动程序，规划直接连接（少量持久连接、迁移）、session pool（兼容性广、支持
```
PREPARE
```
）或transaction pool（高并发、serverless）。

Antipadrões

反模式

Policy
```
USING (true)
```
/
```
WITH CHECK (true)
```
deixada "temporariamente" para destravar desenvolvimento e nunca revisada antes de produção — equivale a RLS desabilitada.
Checar tenant/ownership só no cliente (filtrar a query pelo
```
tenant_id
```
no frontend) sem policy correspondente no banco — qualquer chamada direta à API contorna o filtro.
Função
```
SECURITY DEFINER
```
sem
```
SET search_path = ''
```
/schema fixo — permite sequestro de função por objeto de mesmo nome em outro schema no
```
search_path
```
do chamador.
Migration aplicada manualmente em produção via dashboard, divergindo do histórico versionado — o próximo
```
db push
```
/
```
db diff
```
não sabe reconciliar o estado real.
Confiar em claim customizada do JWT sem validar sua origem (ex.: campo gravável pelo próprio usuário sendo usado como papel de autorização).

为了解锁开发而临时设置
```
USING (true)
```
/
```
WITH CHECK (true)
```
的policy，且在上线前未进行审查——等同于未启用RLS。
仅在客户端检查租户/所有权（在前端通过
```
tenant_id
```
过滤查询），而未在数据库中设置对应的policy——任何直接调用API的请求均可绕过该过滤。
```
SECURITY DEFINER
```
函数未设置
```
SET search_path = ''
```
/固定schema——允许调用者
```
search_path
```
中其他schema内的同名对象劫持该函数。
通过仪表盘中手动在生产环境应用迁移，偏离版本化历史记录——下一次
```
db push
```
/
```
db diff
```
将无法协调实际状态。
信任JWT中的自定义claims而不验证其来源（例如：允许用户自行修改的字段被用作授权角色）。

Validação

验证步骤

Provar acesso permitido e negado com identidades reais de teste para cada papel, incluindo sessão ausente (
```
anon
```
) e o "vizinho" de outro tenant.
Executar
```
supabase db reset
```
/lint/migrations no ambiente local antes de promover — o projeto local reproduz o schema e as policies de produção.
Conferir tipos gerados (
```
supabase gen types
```
) atualizados, replicação/ Realtime restrita ao mesmo modelo de tenancy, policies de Storage por bucket, e segredos de Edge Functions fora do código-fonte.
Avaliar recuperação e exportação dos dados além do backup gerenciado — testar um restore ou export completo, não assumir que o backup automático garante RTO aceitável.
Não declarar uma tabela "protegida por RLS" sem o teste negativo (acesso que deveria falhar, falhando de fato).

使用各角色的真实测试身份验证允许和拒绝的访问情况，包括无会话场景（
```
anon
```
）及其他租户的“邻接用户”。
在推广到生产环境前，在本地环境执行
```
supabase db reset
```
/lint/迁移——本地项目需复刻生产环境的schema和policies。
检查更新后的生成类型（
```
supabase gen types
```
）、限制在同一租户模型内的复制/Realtime、按bucket设置的Storage policies，以及代码库之外的Edge Functions密钥。
除托管备份外，评估数据恢复和导出能力——测试完整的恢复或导出操作，不要假设自动备份能保证可接受的RTO。
若声明某表“受RLS保护”，必须进行否定测试（应被拒绝的访问确实被拒绝）。

specsfy-specialist-supabase

Original

Translation

Supabase

Supabase

Quando usar

适用场景

Fluxo

流程

Padrões

最佳实践

Antipadrões

反模式

Validação

验证步骤

Skills relacionadas

相关技能