Esta página faz parte de uma habilidade de agente de código IA e é escrita para agentes, não para humanos. Para a documentação legível por humanos da Base44, veja a documentação para desenvolvedores.

Exemplos RLS

Padrões práticos de Segurança em Nível de Linha para tipos comuns de aplicativos. Importante: O RLS da Base44 suporta:

Operadores lógicos: $or, $and, $nor para combinar condições
Operadores de campo (para campos data.*): $in, $nin, $ne, $all
user_condition: Apenas igualdade (sem operadores)

Conteúdo

Padrões simples (JSON Schema)
Usando operadores
Exemplos de segurança em nível de campo
Padrões complexos (UI do Dashboard ou Backend)
Melhores práticas

Padrões simples (JSON Schema)

Estes padrões funcionam com o formato RLS de JSON schema.

Aplicativo de tarefas - Acesso apenas do proprietário

Os usuários veem e gerenciam apenas suas próprias tarefas.

{
  "name": "Task",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "description": { "type": "string" },
    "completed": { "type": "boolean" },
    "priority": { "type": "string", "enum": ["low", "medium", "high"] },
    "due_date": { "type": "string", "format": "date" }
  },
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Formulário de contato - Criação pública, leitura apenas de administrador

Qualquer um pode enviar, apenas administradores podem visualizar submissões.

{
  "name": "ContactSubmission",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "email": { "type": "string", "format": "email" },
    "message": { "type": "string" }
  },
  "rls": {
    "create": true,
    "read": { "user_condition": { "role": "admin" } },
    "update": { "user_condition": { "role": "admin" } },
    "delete": { "user_condition": { "role": "admin" } }
  }
}

Perfil de usuário - Autogerenciamento

Os usuários só podem acessar seu próprio perfil.

{
  "name": "UserProfile",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "avatar_url": { "type": "string" },
    "bio": { "type": "string" },
    "preferences": { "type": "object" }
  },
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Dados de departamento - Acesso do mesmo departamento

Os usuários só podem ver registros do seu departamento.

{
  "name": "DepartmentAnnouncement",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "content": { "type": "string" },
    "department": { "type": "string" }
  },
  "rls": {
    "create": { "user_condition": { "role": "manager" } },
    "read": { "data.department": "{{user.data.department}}" },
    "update": { "user_condition": { "role": "manager" } },
    "delete": { "user_condition": { "role": "admin" } }
  }
}

Assinatura - Gerenciada por admin, legível pelo usuário via campo de e-mail

{
  "name": "Subscription",
  "type": "object",
  "properties": {
    "user_email": { "type": "string" },
    "tier": { "type": "string", "enum": ["free", "basic", "pro", "enterprise"] },
    "credits": { "type": "number" },
    "renewal_date": { "type": "string", "format": "date" }
  },
  "rls": {
    "create": { "user_condition": { "role": "admin" } },
    "read": { "data.user_email": "{{user.email}}" },
    "update": { "user_condition": { "role": "admin" } },
    "delete": { "user_condition": { "role": "admin" } }
  }
}

Nota: Este padrão permite apenas que os usuários leiam sua própria assinatura. Administradores precisam usar a UI do painel para configurar acesso de leitura adicional para si mesmos.

Dados privados - Apenas proprietário

{
  "name": "PrivateNotes",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "content": { "type": "string" },
    "tags": { "type": "array", "items": { "type": "string" } }
  },
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Leitura pública, escrita autenticada

Qualquer um pode ler, apenas usuários logados podem criar/editar seus próprios registros.

{
  "name": "BlogPost",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "content": { "type": "string" },
    "author_email": { "type": "string" }
  },
  "rls": {
    "create": true,
    "read": true,
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Usando operadores

Operadores lógicos

Combine várias condições usando $or, $and ou $nor: Acesso de proprietário OU administrador:

{
  "name": "Document",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "content": { "type": "string" }
  },
  "rls": {
    "create": true,
    "read": {
      "$or": [
        { "created_by": "{{user.email}}" },
        { "user_condition": { "role": "admin" } }
      ]
    },
    "update": {
      "$or": [
        { "created_by": "{{user.email}}" },
        { "user_condition": { "role": "admin" } }
      ]
    },
    "delete": { "user_condition": { "role": "admin" } }
  }
}

Várias funções com $or:

{
  "rls": {
    "read": {
      "$or": [
        { "user_condition": { "role": "admin" } },
        { "user_condition": { "role": "manager" } },
        { "user_condition": { "role": "hr" } }
      ]
    }
  }
}

Operadores de campo para campos data.*

Use $in, $nin, $ne, $all para comparar campos de dados de entidade: Acesso baseado em tags ($in):

{
  "rls": {
    "read": {
      "data.category": { "$in": ["public", "shared"] }
    }
  }
}

Excluir status específicos ($nin):

{
  "rls": {
    "read": {
      "data.status": { "$nin": ["archived", "deleted"] }
    }
  }
}

Diferente ($ne):

{
  "rls": {
    "read": {
      "data.visibility": { "$ne": "private" }
    }
  }
}

Todas as tags devem corresponder ($all):

{
  "rls": {
    "read": {
      "data.required_tags": { "$all": ["approved", "reviewed"] }
    }
  }
}

Combinando operadores lógicos e de campo

{
  "rls": {
    "read": {
      "$and": [
        { "data.status": { "$ne": "draft" } },
        {
          "$or": [
            { "created_by": "{{user.email}}" },
            { "data.visibility": "public" }
          ]
        }
      ]
    }
  }
}

Exemplos de segurança em nível de campo

Controle o acesso a campos específicos dentro de uma entidade.

Campo de salário sensível

{
  "name": "Employee",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "email": { "type": "string", "format": "email" },
    "salary": {
      "type": "number",
      "description": "Annual salary",
      "rls": {
        "read": { "user_condition": { "role": "hr" } },
        "write": { "user_condition": { "role": "hr" } }
      }
    },
    "performance_notes": {
      "type": "string",
      "description": "Manager notes",
      "rls": {
        "read": {
          "$or": [
            { "user_condition": { "role": "manager" } },
            { "user_condition": { "role": "hr" } }
          ]
        },
        "write": { "user_condition": { "role": "manager" } }
      }
    }
  }
}

Campos internos apenas para admin

{
  "name": "Order",
  "type": "object",
  "properties": {
    "order_number": { "type": "string" },
    "total": { "type": "number" },
    "internal_notes": {
      "type": "string",
      "description": "Internal processing notes",
      "rls": {
        "read": { "user_condition": { "role": "admin" } },
        "write": { "user_condition": { "role": "admin" } }
      }
    },
    "profit_margin": {
      "type": "number",
      "description": "Profit margin percentage",
      "rls": {
        "read": { "user_condition": { "role": "admin" } },
        "write": false
      }
    }
  }
}

Padrões complexos (UI do Dashboard ou Backend)

Alguns padrões ainda podem exigir a UI do painel ou funções de backend.

Relacionamentos bidirecionais (por exemplo, amizades, correspondências)

Requisito: Qualquer uma das partes em um relacionamento deve ter acesso. Agora possível com $or:

{
  "rls": {
    "read": {
      "$or": [
        { "data.user_a_email": "{{user.email}}" },
        { "data.user_b_email": "{{user.email}}" }
      ]
    }
  }
}

Soluções alternativas:

Redesign de entidade: Armazenar dois registros por relacionamento (um para cada parte)
Função de backend: Consultar com lógica personalizada

Lógica de negócios complexa

Requisito: O acesso depende de vários campos de entidade com condições complexas. Limitação do JSON Schema: Embora os operadores ajudem, lógica de negócios muito complexa pode ainda ser difícil de expressar. Opções de solução:

Função de backend: Implementar lógica de acesso personalizada
Combinar regras mais simples: Dividir regras complexas em regras mais simples de nível de entidade e nível de campo

Melhores práticas

Estratégia de segurança

Use uma combinação de RLS em nível de entidade e segurança em nível de campo:

Tipo de dados	Abordagem	Exemplo
Editável pelo usuário	RLS de entidade: apenas proprietário	UserProfile com verificação `created_by`
Campos sensíveis	RLS em nível de campo	Campo de salário com verificação de função HR
Acesso multi-função	`$or` com user_condition	Acesso Admin OU Manager
Acesso condicional	Operadores de campo	`$in`, `$ne` em campos de dados
Conteúdo público	RLS de entidade: `read: true`	PublicPost
Conteúdo privado	RLS de entidade: apenas proprietário	PrivateNote

Quando usar cada abordagem

Requisito	Abordagem
Condição única (proprietário, admin, departamento)	RLS de JSON Schema
Várias condições OR/AND	RLS de JSON Schema com `$or`/`$and`
Verificações de valor de campo com `$in`/`$ne`/etc.	RLS de JSON Schema para campos `data.*`
Controle de acesso em nível de campo	FLS de JSON Schema (`rls` em nível de campo)
Operadores de comparação complexos (`$gt`, `$lt`)	Funções de backend
Lógica de negócios muito complexa	Funções de backend

Padrões comuns de função

Função	Acesso típico
`admin`	Acesso total a todos os registros
`moderator`	Acesso de leitura/atualização, exclusão limitada
`manager`	Acesso com escopo de departamento
`user`	Apenas próprios registros

Resumo dos operadores suportados

Operador	Suportado	Notas
`$or`	Sim	Combina várias condições
`$and`	Sim	Todas as condições devem corresponder
`$nor`	Sim	Nenhuma das condições corresponde
`$in`	Sim	Apenas para campos `data.*`
`$nin`	Sim	Apenas para campos `data.*`
`$ne`	Sim	Apenas para campos `data.*`
`$all`	Sim	Apenas para campos `data.*`
`$gt`, `$lt`, `$gte`, `$lte`	Não	Use funções de backend
`$regex`	Não	Use funções de backend

Resumo de limitações

Não suportado	Alternativa
Operadores em `user_condition`	Use apenas igualdade para verificações de usuário
Operadores de comparação (`$gt`, `$lt`)	Funções de backend
Correspondência de regex (`$regex`)	Funções de backend
Relacionamentos entre entidades	Funções de backend

Esta página foi traduzida usando IA. Para informações mais precisas e atualizadas, consulte a versão em inglês.

​Exemplos RLS

​Conteúdo

​Padrões simples (JSON Schema)

​Aplicativo de tarefas - Acesso apenas do proprietário

​Formulário de contato - Criação pública, leitura apenas de administrador

​Perfil de usuário - Autogerenciamento

​Dados de departamento - Acesso do mesmo departamento

​Assinatura - Gerenciada por admin, legível pelo usuário via campo de e-mail

​Dados privados - Apenas proprietário

​Leitura pública, escrita autenticada

​Usando operadores

​Operadores lógicos

​Operadores de campo para campos data.*

​Combinando operadores lógicos e de campo

​Exemplos de segurança em nível de campo

​Campo de salário sensível

​Campos internos apenas para admin

​Padrões complexos (UI do Dashboard ou Backend)

​Relacionamentos bidirecionais (por exemplo, amizades, correspondências)

​Lógica de negócios complexa

​Melhores práticas

​Estratégia de segurança

​Quando usar cada abordagem

​Padrões comuns de função

​Resumo dos operadores suportados

​Resumo de limitações

Exemplos RLS

Conteúdo

Padrões simples (JSON Schema)

Aplicativo de tarefas - Acesso apenas do proprietário

Formulário de contato - Criação pública, leitura apenas de administrador

Perfil de usuário - Autogerenciamento

Dados de departamento - Acesso do mesmo departamento

Assinatura - Gerenciada por admin, legível pelo usuário via campo de e-mail

Dados privados - Apenas proprietário

Leitura pública, escrita autenticada

Usando operadores

Operadores lógicos

Operadores de campo para campos data.*

Combinando operadores lógicos e de campo

Exemplos de segurança em nível de campo

Campo de salário sensível

Campos internos apenas para admin

Padrões complexos (UI do Dashboard ou Backend)

Relacionamentos bidirecionais (por exemplo, amizades, correspondências)

Lógica de negócios complexa

Melhores práticas

Estratégia de segurança

Quando usar cada abordagem

Padrões comuns de função

Resumo dos operadores suportados

Resumo de limitações