Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Impara la sintassi di base delle regole di sicurezza Firebase per il linguaggio Cloud Storage

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Le regole di sicurezza Firebase per Cloud Storage ti consentono di controllare l'accesso agli oggetti archiviati nei bucket di Cloud Storage. La sintassi flessibile delle regole ti consente di creare regole per controllare qualsiasi operazione, da tutte le scritture nel tuo bucket di Cloud Storage alle operazioni su un file specifico.

Questa guida descrive la sintassi di base e la struttura delle regole di sicurezza dell'archiviazione cloud per creare set di regole completi.

Dichiarazione di servizio e database

Le regole di sicurezza di Firebase per Cloud Storage iniziano sempre con la seguente dichiarazione:

service firebase.storage {
    // ...
}

La dichiarazione del service firebase.storage le regole a Cloud Storage, prevenendo conflitti tra le regole di sicurezza di Cloud Storage e le regole per altri prodotti come Cloud Firestore.

Regole di lettura/scrittura di base

Le regole di base consistono in un'istruzione di match che identifica i bucket di Cloud Storage, un'istruzione di corrispondenza che specifica un nome file e un'espressione di allow con i dettagli quando è consentita la lettura dei dati specificati. Le espressioni allow specificano i metodi di accesso (ad es. lettura, scrittura) coinvolti e le condizioni in base alle quali l'accesso è consentito o negato.

Nel tuo set di regole predefinito, la prima istruzione di match utilizza un'espressione jolly {bucket} per indicare che le regole si applicano a tutti i bucket nel tuo progetto. Discuteremo maggiormente l'idea delle corrispondenze con caratteri jolly nella prossima sezione.

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

Tutte le dichiarazioni di corrispondenza puntano a file. Una dichiarazione di corrispondenza può puntare a un file specifico, come in match /images/profilePhoto.png .

Abbina caratteri jolly

Oltre a puntare a un singolo file, Rules può utilizzare i caratteri jolly per puntare a qualsiasi file con un determinato prefisso di stringa nel nome, incluse le barre, come in match /images/{imageId} .

Nell'esempio precedente, l'istruzione match utilizza la sintassi del carattere jolly {imageId} . Ciò significa che la regola si applica a qualsiasi file con /images/ all'inizio del nome, come /images/profilePhoto.png o /images/croppedProfilePhoto.png . Quando vengono valutate le espressioni di allow nell'istruzione di corrispondenza, la variabile imageId verrà risolta nel nome del file dell'immagine, ad esempio profilePhoto.png o croppedProfilePhoto.png .

È possibile fare riferimento a una variabile con caratteri jolly dall'interno della match per fornire il nome del file o l'autorizzazione del percorso:

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

Dati gerarchici

Come abbiamo detto prima, non esiste una struttura gerarchica all'interno di un bucket di Cloud Storage. Ma usando una convenzione di denominazione dei file, spesso che include barre nei nomi dei file, possiamo imitare una struttura che assomiglia a una serie annidata di directory e sottodirectory. È importante capire come le regole di sicurezza di Firebase interagiscono con questi nomi di file.

Considera la situazione di un insieme di file con nomi che iniziano tutti con lo stelo /images/ . Le regole di sicurezza di Firebase si applicano solo al nome del file corrispondente, quindi i controlli di accesso definiti sullo stelo /images/ non si applicano allo stelo /mp3s/ . Invece, scrivi regole esplicite che corrispondano a diversi modelli di nomi di file:

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>;
    }
  }
}

Quando si annidano le istruzioni di match , il percorso dell'istruzione di match interna viene sempre aggiunto al percorso dell'istruzione di match esterna. I seguenti due set di regole sono quindi equivalenti:

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/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

Caratteri jolly di corrispondenza ricorsivi

Oltre ai caratteri jolly che corrispondono e restituiscono stringhe alla fine di un nome file, è possibile dichiarare un carattere jolly a più segmenti per una corrispondenza più complessa aggiungendo =** al nome del carattere jolly, come {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 più regole corrispondono a un file, il risultato è l' OR del risultato di tutte le valutazioni delle regole. Cioè, se una qualsiasi regola il file corrisponde a true , il risultato è true .

Nelle regole di cui sopra, il file "images/profilePhoto.png" può essere letto se sia condition che other_condition true, mentre il file "images/users/user:12345/profilePhoto.png" è soggetto solo al risultato di other_condition .

Le regole di sicurezza dell'archiviazione cloud non sono a cascata e le regole vengono valutate solo quando il percorso della richiesta corrisponde a un percorso con le regole specificate.

Versione 1

Le regole di sicurezza di Firebase utilizzano la versione 1 per impostazione predefinita. Nella versione 1, i caratteri jolly ricorsivi corrispondono a uno o più elementi del nome file, non a zero o più elementi. Pertanto, match /images/{filenamePrefixWildcard}/{imageFilename=**} corrisponde a un nome file come /images/profilePics/profile.png, ma non /images/badge.png. Utilizzare invece /images/{imagePrefixorFilename=**} .

I caratteri jolly ricorsivi devono trovarsi alla fine di una dichiarazione di corrispondenza.

Ti consigliamo di utilizzare la versione 2 per le sue funzionalità più potenti.

Versione 2

Nella versione 2 delle regole di sicurezza Firebase, i caratteri jolly ricorsivi corrispondono a zero o più elementi del percorso. Pertanto, /images/{filenamePrefixWildcard}/{imageFilename=**} corrisponde ai nomi dei file /images/profilePics/profile.png e /images/badge.png.

Devi accettare la versione 2 aggiungendo rules_version = '2'; in cima alle tue regole di sicurezza:

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

Puoi avere al massimo un carattere jolly ricorsivo per dichiarazione di corrispondenza, ma nella versione 2 puoi inserire questo carattere jolly in qualsiasi punto della dichiarazione di corrispondenza. Per esempio:

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

Operazioni granulari

In alcune situazioni, è utile suddividere la read e la write in operazioni più granulari. Ad esempio, la tua app potrebbe voler imporre condizioni diverse alla creazione del file rispetto all'eliminazione del file.

Un'operazione di read può essere suddivisa in get e list .

Una regola di write può essere suddivisa in create , update ed 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 file 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 file contents
      allow create: if <condition>;

      // Applies to updates to (pre-existing) file metadata
      allow update: if <condition>;

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

Dichiarazioni di corrispondenza sovrapposte

È possibile che un nome file corrisponda a più di un'istruzione di match . Nel caso in cui più espressioni di allow corrispondano a una richiesta, l'accesso è consentito se una delle condizioni è true :

service firebase.storage {
  match b/{bucket}/o {
    // Matches file names directly inside of '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches file names anywhere under `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

Nell'esempio sopra, tutte le letture e le scritture su file il cui nome inizia con /images/ sono consentite perché la seconda regola è sempre true , anche quando la prima regola è false .

Le regole non sono filtri

Dopo aver protetto i dati e aver iniziato a eseguire operazioni sui file, tieni presente che le regole di sicurezza non sono filtri. Non puoi eseguire operazioni su un set di file che corrispondono a un modello di nome file e aspettarti che Cloud Storage acceda solo ai file a cui il client corrente dispone dell'autorizzazione ad accedere.

Ad esempio, prendi la seguente regola di sicurezza:

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';
    }
  }
}

Denied : questa regola rifiuta la seguente richiesta perché il set di risultati può includere file in cui contentType non è image/png :

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

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

Regole nelle regole di sicurezza dell'archiviazione cloud valutano ogni query rispetto al suo potenziale risultato e non supera la richiesta se potrebbe restituire un file che il client non dispone dell'autorizzazione per la lettura. Le richieste di accesso devono seguire i vincoli stabiliti dalle tue regole.

Prossimi passi

Puoi approfondire la tua comprensione delle regole di sicurezza di Firebase per il cloud storage:

  • Impara il prossimo concetto principale del linguaggio delle regole, le condizioni dinamiche, che consentono alle tue regole di controllare l'autorizzazione dell'utente, confrontare i dati esistenti e in entrata, convalidare i dati in entrata e altro ancora.

  • Esamina i casi d'uso tipici della sicurezza e le definizioni delle regole di sicurezza Firebase che li affrontano .

Puoi esplorare i casi d'uso delle regole di sicurezza Firebase specifici per Cloud Storage: