O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Aprenda a sintaxe principal das regras de segurança do Firebase para a linguagem Cloud Storage

As regras de segurança do Firebase para Cloud Storage permitem que você controle o acesso a objetos armazenados em intervalos do Cloud Storage. A sintaxe de regras flexíveis permite que você crie regras para controlar qualquer operação, desde todas as gravações em seu intervalo de armazenamento até operações em um arquivo específico.

Este guia descreve a sintaxe básica e a estrutura das Regras de segurança de armazenamento para criar conjuntos de regras completos.

Declaração de serviço e banco de dados

As regras de segurança do Firebase para Cloud Storage sempre começam com a seguinte declaração:

service firebase.storage {
    // ...
}

A declaração de service firebase.storage escopo das regras para o Cloud Storage, evitando conflitos entre as regras de segurança do armazenamento e as regras de outros produtos, como o Cloud Firestore.

Regras básicas de leitura / gravação

As regras básicas consistem em uma instrução de match que identifica intervalos de armazenamento, uma instrução de correspondência especificando um nome de arquivo e uma expressão de allow que detalha quando a leitura dos dados especificados é permitida. allow expressões de allow especificam os métodos de acesso (por exemplo, leitura, gravação) envolvidos e as condições sob as quais o acesso é permitido ou negado.

Em seu conjunto de regras padrão, a primeira instrução de match usa uma expressão curinga {bucket} para indicar que as regras se aplicam a todos os intervalos em seu projeto. Discutiremos a ideia de correspondências de curinga mais na próxima seção.

service firebase.storage {
  // The {bucket} wildcard indicates we match files in all storage buckets
  match /b/{bucket}/o {
    // Match filename
    match /filename {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

Todas as instruções de correspondência apontam para arquivos. Uma declaração de correspondência pode apontar para um arquivo específico, como em match /images/profilePhoto.png .

Match wildcards

Além de apontar para um único arquivo, as regras podem usar curingas para apontar para qualquer arquivo com um determinado prefixo de string em seu nome, incluindo barras, como em match /images/{imageId} .

No exemplo acima, a instrução de correspondência usa a sintaxe curinga {imageId} . Isso significa que a regra se aplica a qualquer arquivo com /images/ no início de seu nome, como /images/profilePhoto.png ou /images/croppedProfilePhoto.png . Quando a allow expressões na instrução de correspondência são avaliados, o imageId variável determinará o nome do arquivo de imagem, como profilePhoto.png ou croppedProfilePhoto.png .

Uma variável curinga pode ser referenciada de dentro da match para fornecer o nome do arquivo ou a autorização do caminho:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

Dados hierárquicos

Como dissemos antes, não há estrutura hierárquica dentro de um intervalo do Cloud Storage. Mas, usando uma convenção de nomenclatura de arquivo, geralmente uma que inclui barras nos nomes dos arquivos, podemos imitar uma estrutura que se parece com uma série aninhada de diretórios e subdiretórios. É importante entender como as regras de segurança do Firebase interagem com esses nomes de arquivo.

Considere a situação de um conjunto de arquivos com nomes que começam todos com /images/ stem. As regras de segurança do Firebase se aplicam apenas ao nome de arquivo correspondente, portanto, os controles de acesso definidos em /images/ stem não se aplicam a /mp3s/ stem. Em vez disso, escreva regras explícitas que correspondam a diferentes padrões de nome de arquivo:

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      allow read, write: if <condition>;
    }

    // Explicitly define rules for the 'mp3s' pattern
    match /mp3s/{mp3Id} {
      allow read, write: if <condition>;
    }
  }
}

Ao aninhar as instruções de match , o caminho da instrução de match interna é sempre anexado ao caminho da instrução de match externa. Os dois conjuntos de regras a seguir são, portanto, equivalentes:

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Exact match for "images/profilePhoto.png"
      match /profilePhoto.png {
        allow write: if <condition>;
      }
    }
  }
}
service firebase.storage {
  match /b/{bucket}/o {
    // Exact match for "images/croppedProfilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

Caracteres curinga de correspondência recursiva

Além dos curingas que correspondem e retornam strings no final de um nome de arquivo, um curinga de vários segmentos pode ser declarado para uma correspondência mais complexa adicionando =** ao nome do curinga, como {path=**} :

// Partial match for files that start with "images"
match /images {

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

Se várias regras corresponderem a um arquivo, o resultado será o OR do resultado de todas as avaliações de regras. Ou seja, se qualquer regra que o arquivo corresponder for avaliada como true , o resultado será true .

Nas regras acima, o arquivo "images / profilePhoto.png" pode ser lido se a condition ou other_condition avaliada como verdadeira, enquanto o arquivo "images / users / user: 12345 / profilePhoto.png" está sujeito apenas ao resultado de other_condition .

As regras de segurança de armazenamento não são propagadas e as regras são avaliadas apenas quando o caminho da solicitação corresponde a um caminho com as regras especificadas.

Versão 1

As regras de segurança do Firebase usam a versão 1 por padrão. Na versão 1, os curingas recursivos correspondem a um ou mais elementos do nome do arquivo, não a zero ou mais elementos. Portanto, match /images/{filenamePrefixWildcard}/{imageFilename=**} corresponde a um nome de arquivo como /images/profilePics/profile.png, mas não /images/badge.png. Use /images/{imagePrefixorFilename=**} vez disso.

Os curingas recursivos devem vir no final de uma instrução de correspondência.

Recomendamos que você use a versão 2 por seus recursos mais poderosos.

Versão 2

Na versão 2 das regras de segurança do Firebase, os caracteres curinga recursivos correspondem a zero ou mais itens de caminho. Portanto, /images/{filenamePrefixWildcard}/{imageFilename=**} corresponde a nomes de arquivos /images/profilePics/profile.png e /images/badge.png.

Você deve rules_version = '2'; a versão 2 adicionando rules_version = '2'; no topo de suas regras de segurança:

rules_version = '2';
service cloud.storage {
  match /b/{bucket}/o {
   ...
 }
}

Você pode ter no máximo um curinga recursivo por instrução de correspondência, mas na versão 2, você pode colocar esse curinga em qualquer lugar da instrução de correspondência. Por exemplo:

rules_version = '2';
service firebase.storage {
 match /b/{bucket}/o {
   // Matches any file in a songs "subdirectory" under the
   // top level of your storage bucket.
   match /{prefixSegment=**}/songs/{mp3filenames} {
     allow read, write: if <condition>;
   }
  }
}

Operações granulares

Em algumas situações, é útil dividir a read e a write em operações mais granulares. Por exemplo, seu aplicativo pode querer impor condições diferentes na criação do arquivo e na exclusão do arquivo.

Uma operação de read pode ser dividida em get e list .

Uma regra de write pode ser dividida em create , update e delete :

service firebase.storage {
  match /b/{bucket}/o {
    // A read rule can be divided into read and list rules
    match /images/{imageId} {
      // Applies to single document read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (Rules Version 2)
      allow list: if <condition>;

    // A write rule can be divided into create, update, and delete rules
    match /images/{imageId} {
      // Applies to writes to nonexistent files
      allow create: if <condition>;

      // Applies to writes to existing files
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
 }
}

Declarações de correspondência sobrepostas

É possível que um nome de arquivo corresponda a mais de uma instrução de match . No caso em que várias expressões de allow correspondem a uma solicitação, o acesso é permitido se alguma das condições for true :

service firebase.storage {
  match b/{bucket}/o {
    // Matches any filename containing string '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches all filenames containing string `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

No exemplo acima, todas as leituras e gravações em arquivos com a string /images/ em qualquer lugar no nome do arquivo serão permitidas porque a segunda regra é sempre true , embora a primeira regra seja sempre false .

Regras não são filtros

Depois de proteger seus dados e começar a executar operações de arquivo, lembre-se de que as regras de segurança não são filtros. Você não pode executar operações em um conjunto de arquivos que correspondem a um padrão de nome de arquivo e esperar que o Storage acesse apenas os arquivos que o cliente atual tem permissão para acessar.

Por exemplo, considere a seguinte regra de segurança:

service firebase.storage {
  match /b/{bucket}/o {
    // Allow the client to read files with contentType 'image/png'
    match /aFileNamePrefix/{aFileName} {
      allow read: if resource.contentType == 'image/png';
    }
  }
}

Negado : esta regra rejeita a seguinte solicitação porque o conjunto de resultados pode incluir arquivos onde contentType não é image/png :

Rede
filesRef = storage.ref().child("aFilenamePrefix");

filesRef.listAll()
    .then(function(result) {
      console.log("Success: ", result.items);
    })
});

Regras em Regras de segurança de armazenamento avaliam cada consulta em relação ao seu resultado potencial e falha na solicitação se ela puder retornar um arquivo que o cliente não tem permissão para ler. As solicitações de acesso devem seguir as restrições definidas por suas regras.

Próximos passos

Você pode aprofundar sua compreensão das regras de segurança do Firebase para Cloud Storage:

  • Aprenda o próximo conceito principal da linguagem das Regras, as condições dinâmicas, que permitem que suas Regras verifiquem a autorização do usuário, comparem dados existentes e recebidos, validem dados recebidos e muito mais.

  • Revise os casos de uso de segurança típicos e as definições das regras de segurança do Firebase que os abordam .

Você pode explorar casos de uso de regras de segurança do Firebase específicos para o Google Cloud Storage: