Regras simples para o Firebase Realtime Database

Recentemente fiz uma aplicação em Flutter e usei o Firebase Realtime Database. Eu tinha que ler e escrever dados de uma loja e entender sobre como funciona a Firebase Realtime Database sua flexibilidade e como sua sintaxe funcionava e descobri que parece bastante com o Javascript que você define como o dado está estruturado, como eles serão indexados e quando pode ser lido e escrito, tudo isso de modo simples.

Essas regras ficam no servidor do Firebase e são aplicadas automaticamente e todo o tempo. Caso você faça alguma mudança no Firebase Console ela mudará imediatamente na sua aplicação. Você só tem que selecionar seu projeto e clicar na seção Database e selecionar a aba regras.

Tipos de regras

As regras tem uma sintaxe parecida com Javascript e são bem fáceis de entender:

.read
Define se e quando o usuário está habilitado a ler.
.write
Define se e quando o usuário está habilitado a escrever.
.validate
Define que um determinado dado está formatado corretamente e se estará como você deseja.
.indexOn
Especifica uma child para o índice suportar query e order by.

A Documentação do Firebase é muito boa e permite se aprofundar nisso e realmente entender o Firebase Realtime Database Rules, caso tenha interesse dê uma olhada lá.

Vamos começar!

1) Sem segurança

Essa regra permite que qualquer pessoa, mesmo que não sejam usuários da sua aplicação possam ler e escrever dados no seu banco de dados.

Durante o desenvolvimento, você pode usar a regra dessa forma, mas ciente de que qualquer pessoa pode inserir, modificar e apagar todos os dados da sua aplicação.

// No Security{
 “rules”: {
 “.read”: true,
 “.write”: true
 }
}

2) Segurança total

Desse modo ninguém pode acessar os dados nem para leitura e nem para escrita, exceto pelo Firebase Console.

{
 “rules”: {
 “.read”: false,
 “.write”: false
 }
}

3) Somente usuários autenticados

Usuários autenticados poderão ler e escrever na sua aplicação.

{
 “rules”: {
 “.read”: “auth != null”,
 “.write”: “auth != null”
 }
}

4) Somente usuários de um determinado domínio

{
 “rules”: {
 “.read”: “auth.token.email.endsWith(‘@example.com’)”,
 “.write”: “auth.token.email.endsWith(‘@example.com’)”
 }
}

5) User Data Only

Aqui é um exemplo de regra em que o usuário só pode alterar seus próprios dados, por exemplo, /post/$user_idonde $user_idé o id que o usuário obteve na Authentication. Isso é bem comum para dados privados do usuário, por exemplo.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

6) Validando usuário é moderador do sistema analisando em outro local do banco

Nesse exemplo teríamos uma tabela moderator que teria a informação se o usuário faz parte ou não do grupo de moderadores.

{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.write”: “root.child(‘users’).child(‘moderator’).val() === true”
 }
 }
 }
}

7) Validando string e tamanho

É possível validar os dados informados durante a requisição:

{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.validate”: “newData.isString() 
 && newData.val().length > 0
 && newData.val().length <= 140”
 }
 }
 }
}

8) Verifica se o objeto tem um componente filho

Pode-se verificar se o objeto está informando um determinado campo durante a requisição.

// Checks presence of child attributes{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.validate”: “newData.hasChildren([‘username’, ‘timestamp’])”
 }
 }
 }
}

9) Validando timestamp

{
 “rules”: {
 “posts”: {
 “$uid”: {
 “timestamp”: { 
 “.validate”: “newData.val() <= now” 
 }
 }
 }
 }
}

10) Análise simples de Delete ou Update

{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.write”: “!data.exists()”
 }
 }
 }
}

11) Prevenção antes de atualizar

{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.write”: “newData.exists()”
 }
 }
 }
}

12) Prevenção antes do Delete

{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.write”: “!data.exists() || !newData.exists()”
 }
 }
 }
}

13) Prevenção ao Criar e Deletar

{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.write”: “data.exists() && newData.exists()”
 }
 }
 }
}