Condições de uso nas regras de segurança do Firebase Cloud Storage

Este guia tem por base a aprender a sintaxe do núcleo da linguagem Regras Firebase segurança guia para mostrar como adicionar condições aos seus Regras Firebase segurança para Cloud Storage.

O principal bloco de construção de regras de segurança de armazenamento em nuvem é a condição. Uma condição é uma expressão booleana que determina se uma determinada operação deve ser permitida ou negada. Para regras básicas, utilizando true e false literais como condições funciona prefectly bem. Mas as regras de segurança do Firebase para a linguagem Cloud Storage oferecem maneiras de escrever condições mais complexas que podem:

• Verifique a autenticação do usuário
• Validar dados de entrada

Autenticação

As regras de segurança do Firebase para Cloud Storage se integram ao Firebase Authentication para fornecer autenticação poderosa com base no usuário para o Cloud Storage. Isso permite o controle de acesso granular com base em declarações de um token do Firebase Authentication.

Quando um autenticado executa usuário um pedido contra o Cloud Storage, o request.auth variável é preenchida com o usuário uid ( request.auth.uid ), bem como as reivindicações da autenticação JWT Firebase ( request.auth.token ).

Além disso, ao usar autenticação personalizada, créditos adicionais estão à tona na request.auth.token campo.

Quando um utilizador autenticado executa um pedido, o request.auth variável é null .

Usando esses dados, existem várias maneiras comuns de usar autenticação para proteger arquivos:

• Público: ignorar request.auth
• Autenticado privada: cheque que request.auth não é null
• Usuário privada: cheque que request.auth.uid é igual a um caminho uid
• Grupo privado: verifique as declarações do token personalizado para corresponder a uma declaração escolhida ou leia os metadados do arquivo para ver se existe um campo de metadados

Público

Qualquer regra que não considera o request.auth contexto pode ser considerado um public regra, uma vez que não considera o contexto de autenticação do usuário. Essas regras podem ser úteis para revelar dados públicos, como ativos de jogos, arquivos de som ou outro conteúdo estático.

// Anyone to read a public image if the file is less than 100kB
// Anyone can upload a public file ending in '.txt'
match /public/{imageId} {
  allow read: if resource.size < 100 * 1024;
  allow write: if imageId.matches(".*\\.txt");
}

Privado autenticado

Em certos casos, você pode desejar que os dados possam ser visualizados por todos os usuários autenticados de seu aplicativo, mas não por usuários não autenticados. Desde o request.auth variável é null para todos os usuários não autenticados, tudo que você tem a fazer é verificar o request.auth variável existe, a fim de exigir autenticação:

// Require authentication on all internal image reads
match /internal/{imageId} {
  allow read: if request.auth != null;
}

Usuário privado

De longe, o caso de uso mais comum para request.auth será para fornecer aos usuários individuais com permissões granulares em seus arquivos: de perfil carregar imagens para a leitura de documentos privados.

Como os arquivos em Cloud Storage tem um "caminho" completo para o arquivo, tudo o que preciso para fazer um arquivo controlado por um usuário é um pedaço de informação única, identificação de usuário no prefixo nome de arquivo (como o usuário uid ) que pode ser verificado quando a regra é avaliada:

// Only a user can upload their profile picture, but anyone can view it
match /users/{userId}/profilePicture.png {
  allow read;
  allow write: if request.auth.uid == userId;
}

Grupo privado

Outro caso de uso igualmente comum será permitir permissões de grupo em um objeto, como permitir que vários membros da equipe colaborem em um documento compartilhado. Existem várias abordagens para fazer isso:

• Mint uma autenticação Firebase costume símbolo que contém informações adicionais sobre um membro do grupo (como um ID de grupo)
• Inclua informações de grupo (como um ID de grupo ou lista de autorizados uid s) no metadados do arquivo

Depois que esses dados são armazenados no token ou metadados do arquivo, eles podem ser referenciados a partir de uma regra:

// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

Solicitar Avaliação

Uploads, downloads, alterações de metadados e exclusões são avaliados utilizando o request enviado ao Cloud Storage. Além de identificação única do usuário e a carga de autenticação Firebase na request.auth objeto como descrito acima, o request variável contém o caminho do arquivo onde a solicitação está sendo realizada, o momento em que o pedido é recebido, eo novo resource valor se o pedido é uma escrita. Cabeçalhos HTTP e estado de autenticação também estão incluídos.

O request objeto também contém identificação única do usuário e a carga de autenticação Firebase na request.auth objeto, que será explicado mais adiante na segurança de usuário baseada em seção dos docs.

A lista completa das propriedades do request objeto está disponível abaixo:

Avaliação de Recursos

Ao avaliar as regras, você também pode querer avaliar os metadados do arquivo que está sendo carregado, baixado, modificado ou excluído. Isso permite que você crie regras complexas e poderosas que fazem coisas como permitir que apenas arquivos com certos tipos de conteúdo sejam carregados ou apenas arquivos maiores que um determinado tamanho sejam excluídos.

Regras de Segurança Firebase para Cloud Storage fornece metadados do arquivo no resource objeto, que contém pares de chave / valor dos metadados à tona em um objeto Cloud Storage. Estas propriedades podem ser inspecionados na read ou write solicitações para garantir a integridade dos dados.

Na write solicitações (tais como envios, atualizações de metadados e exclusões), além do resource objeto, que contém metadados para o arquivo que existe atualmente no caminho da solicitação, você também tem a capacidade de usar o request.resource objeto, que contém um subconjunto dos metadados do arquivo a serem gravados se a gravação for permitida. Você pode usar esses dois valores para garantir a integridade dos dados ou impor restrições do aplicativo, como tipo ou tamanho de arquivo.

A lista completa das propriedades do resource objeto está disponível abaixo:

request.resource contém todos estes com exceção de generation , metageneration , etag , timeCreated e updated .

Validar dados

Regras de Segurança Firebase para Cloud Storage também pode ser usado para validação de dados, incluindo a validação de nome de arquivo e caminho, bem como propriedades de metadados de arquivos, como contentType e size .

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      // Only allow uploads of any image file that's less than 5MB
      allow write: if request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

Funções personalizadas

À medida que suas regras de segurança do Firebase se tornam mais complexas, convém envolver conjuntos de condições em funções que podem ser reutilizadas em seu conjunto de regras. As regras de segurança oferecem suporte a funções personalizadas. A sintaxe para funções personalizadas é um pouco como JavaScript, mas as funções das regras de segurança do Firebase são escritas em uma linguagem específica de domínio que tem algumas limitações importantes:

• As funções podem conter apenas um único return comunicado. Eles não podem conter nenhuma lógica adicional. Por exemplo, eles não podem executar loops ou chamar serviços externos.
• As funções podem acessar automaticamente funções e variáveis ​​do escopo em que são definidas. Por exemplo, uma função definida dentro do service firebase.storage escopo tem acesso ao resource variável, e para Cloud Firestore única, built-in funções como get() e exists() .
• As funções podem chamar outras funções, mas não podem ser repetidas. A profundidade total da pilha de chamadas é limitada a 10.
• Na versão rules2 , as funções podem definir variáveis usando o let palavra-chave. As funções podem ter qualquer número de ligações let, mas devem terminar com uma instrução return.

A função é definida com a function palavra-chave e leva zero ou mais argumentos. Por exemplo, você pode querer combinar os dois tipos de condições usados ​​nos exemplos acima em uma única função:

service firebase.storage {
  match /b/{bucket}/o {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }
    match /images/{imageId} {
      allow read, write: if signedInOrPublic();
    }
    match /mp3s/{mp3Ids} {
      allow read: if signedInOrPublic();
    }
  }
}

O uso de funções nas regras de segurança do Firebase as torna mais fáceis de manter à medida que a complexidade das regras aumenta.

Próximos passos

Após esta discussão sobre as condições, você terá um entendimento mais sofisticado das regras e estará pronto para:

Aprenda a lidar com os principais casos de uso e aprenda o fluxo de trabalho para desenvolver, testar e implantar regras:

• Escrever regras que endereço cenários comuns .
• Desenvolver a seu conhecimento por rever situações onde você deve detectar e evitar regras inseguras .
• Regras para o teste usando o emulador de armazenamento em nuvem e biblioteca de teste Regras de Segurança dedicada .
• Rever os métodos disponíveis para a implantação de regras .