Como funcionam as regras de segurança do Firebase na Realtime Database?
Parte 3 — Utilizando o Simulador de Regras
Nos 2 artigos anteriores vimos como utilizar as regras do Firebase Database para: limitar as escritas e leituras na base de dados e como validar dados e criar índices.
Neste artigo, veremos como testar as regras que criamos anteriormente, através do simulador de regras incluído na consola do Firebase.
Tipo de simulação
A primeira opção que nos aparece quando abrimos o simulador pede-nos que escolhamos o tipo de simulação: leitura(.read) ou gravação(.write).
Leitura
A leitura permite verificarmos quase todas as regras que criamos com a chave .read . Basta especificarmos o caminho para o nó de onde queremos ler. Por exemplo:
Se quisermos ler os dados de um utilizador, podemos colocar no campo “Local” o directório: utilizadores/uid para indicar que vamos ler do nó “https://id-projecto.firebaseio.com/utilizadores/uid”. Tendo as regras definidas para não permitir leituras, teremos um cenário semelhante à este:
Repare que além do aviso que a leitura negada, o simulador mostra também qual foi a linha onde se encontra a regra que causou a negação. Mas não espere que isto aconteça sempre. Quando as nossas regras são complexas demais, por vezes o Firebase não consegue identificar qual delas está a negar a operação e você terá de encontrar o problema sozinho.
Se as regras definidas permitirem a leitura, o simulador ficará mais ou menos assim:
Gravação
Permite verificarmos as nossas regras de escrita, atualização e remoção de dados (.write & .validate). Para isso, temos de especificar o caminho onde vamos executar a nossa operação e indicar o JSON que contém os dados que iremos colocar nesse caminho.
Por exemplo, podemos testar a escrita de um novo utilizador na base de dados. Só temos de indicar o local /utilizadores/qualquerUide colocar no campo Dados(JSON) os dados desse utilizador:
{
"nome": "Bruce Wayne"
"email": "bruce@wayne.co.mz"
}O resultado mostrado na consola será o mesmo da leitura: vermelho para operação negada e verde para operação com sucesso.
Autenticação
Por padrão, o simulador de regras executa os testes como se o utilizador que está a fazer a leitura/gravação não estivesse autenticado (não possui uma conta no Firebase Auth). Isto significa que ao testar as regras que contêm auth!=null, elas serão sempre negadas. Por isso, existe a opção “autenticado” que permite-nos simular que um utilizador autenticado está a fazer a leitura/gravação.
Provedor
Ao activar a opção “Autenticado”, a primeira opção que nos surge é o provedor. Ela permite que especifiquemos o serviço de autenticação que queremos simular (Google, Facebook, Twitter, Anonimo, ou até um provedor personalizado).
UID
Outra opção que faz parte da autenticação é a possibilidade de indicar o UID do utilizador que está a ler/escrever dados. Assim, podemos testar as regras que envolvem verificar o auth.uid.
Note que ao utilizar os provedores Google, Facebook, Twitter ou Anonimo, o Firebase mostra um payload (um JSON) de autenticação muito simples, com apenas 2 atributos: provider e uid. Estas são as variáveis que utilizamos nas nossas regras como auth.provider e auth.uid, respectivamente.
Até então não tem problema nenhum. Mas se as nossas regras utilizam outros atributos como por exemplo, o auth.token.email ou auth.token.name, então estes 4 provedores não podem nos ajudar (pois na simulação eles não contêm estas variáveis por padrão). E é por isso que existe o provedor Custom.
Custom Auth
O provedor custom é tal igual à qualquer outro provedor de autenticação, a única diferença é que podemos passar um “payload” de autenticação personalizado. Isto permite-nos testar regras que utilizam auth.token.email, auth.token.name ou qualquer outra variável que faz parte do auth.token.
Por exemplo, se tivermos uma regra que permite criar um novo utilizador só se ele for o utilizador logado e tiver o mesmo email que consta no Firebase Auth:
“.write”:”auth!=null && $uid == auth.uid && newData.child(‘email’).val() == auth.token.email”Podemos testá-la com o local “/utilizadores/batman/” e este JSON:
{
"nome": "Bruce Wayne",
"email": "bruce@wayne.co.mz"
}Desde que especifiquemos o email no nosso Payload de Autenticação:
{
"provider": "google",
"uid": "batman",
"token":{
"email":"bruce@wayne.co.mz"
}
}Note que no princípio do artigo eu mencionei que o simulador permite verificarmos “quase” todas as regras que criamos com a chave .read. Isso porque o simulador ainda não permite testar as query-based rules que vimos no artigo anterior. Mas espero que eles atualizem o simulador em breve.
Este foi o último artigo das regras de segurança do Firebase na Realtime Database. No próximo artigo da série irei mostrar as regras de segurança do Cloud Storage For Firebase.
Espero que você já seja capaz de criar regras para garantir a segurança da sua database. Mas
Caso tenha alguma dúvida ou sugestão, pode me contactar pelo email rosariofernandes51@gmail.com ou pelo Telegram. Será um prazer conversar com você. 🙂
