Condizioni di scrittura per le regole di sicurezza di Cloud Firestore

Questa guida si basa sulla guida alle regole di sicurezza per la strutturazione per mostrare come aggiungere condizioni alle regole di sicurezza di Cloud Firestore. Se non hai familiarità con le nozioni di base delle regole di sicurezza di Cloud Firestore, consulta la guida introduttiva .

L'elemento fondamentale delle regole di sicurezza di Cloud Firestore è la condizione. Una condizione è un'espressione booleana che determina se una particolare operazione deve essere consentita o negata. Utilizza le regole di sicurezza per scrivere condizioni che controllino l'autenticazione dell'utente, convalidino i dati in entrata o addirittura accedano ad altre parti del tuo database.

Autenticazione

Uno dei modelli di regole di sicurezza più comuni è il controllo dell'accesso in base allo stato di autenticazione dell'utente. Ad esempio, la tua app potrebbe voler consentire solo agli utenti che hanno effettuato l'accesso di scrivere dati:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to access documents in the "cities" collection
    // only if they are authenticated.
    match /cities/{city} {
      allow read, write: if request.auth != null;
    }
  }
}

Un altro modello comune è assicurarsi che gli utenti possano solo leggere e scrivere i propri dati:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }
  }
}

Se la tua app utilizza Firebase Authentication o Google Cloud Identity Platform , la variabile request.auth contiene le informazioni di autenticazione per il client che richiede i dati. Per ulteriori informazioni su request.auth , consultare la documentazione di riferimento .

Convalida dei dati

Molte app archiviano le informazioni sul controllo degli accessi come campi sui documenti nel database. Le regole di sicurezza di Cloud Firestore possono consentire o negare dinamicamente l'accesso in base ai dati del documento:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

La variabile resource si riferisce al documento richiesto e resource.data è una mappa di tutti i campi e i valori archiviati nel documento. Per ulteriori informazioni sulla variabile resource , consultare la documentazione di riferimento .

Durante la scrittura dei dati, potresti voler confrontare i dati in arrivo con i dati esistenti. In questo caso, se il tuo set di regole consente la scrittura in sospeso, la variabile request.resource contiene lo stato futuro del documento. Per le operazioni update che modificano solo un sottoinsieme dei campi del documento, la variabile request.resource conterrà lo stato del documento in sospeso dopo l'operazione. Puoi controllare i valori dei campi in request.resource per evitare aggiornamenti di dati indesiderati o incoerenti:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure all cities have a positive population and
    // the name is not changed
    match /cities/{city} {
      allow update: if request.resource.data.population > 0
                    && request.resource.data.name == resource.data.name;
    }
  }
}

Accedi ad altri documenti

Utilizzando le funzioni get() ed exists() , le regole di sicurezza possono valutare le richieste in arrivo rispetto ad altri documenti nel database. Le funzioni get() ed exists() si aspettano entrambe percorsi di documenti completamente specificati. Quando si utilizzano variabili per costruire percorsi per get() ed exists() , è necessario eseguire l'escape esplicito delle variabili utilizzando la sintassi $(variable) .

Nell'esempio seguente, la variabile database viene catturata dall'istruzione match /databases/{database}/documents e utilizzata per formare il percorso:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      // Make sure a 'users' document exists for the requesting user before
      // allowing any writes to the 'cities' collection
      allow create: if request.auth != null && exists(/databases/$(database)/documents/users/$(request.auth.uid))

      // Allow the user to delete cities if their user document has the
      // 'admin' field set to 'true'
      allow delete: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true
    }
  }
}

Per le scritture, è possibile utilizzare la funzione getAfter() per accedere allo stato di un documento dopo il completamento di una transazione o di un batch di scritture ma prima del commit della transazione o del batch. Come get() , la funzione getAfter() accetta un percorso del documento completamente specificato. È possibile utilizzare getAfter() per definire serie di scritture che devono avvenire insieme come transazione o batch.

Accedi ai limiti delle chiamate

Esiste un limite alle chiamate di accesso ai documenti per valutazione del set di regole:

  • 10 per richieste di documento singolo e richieste di interrogazione.

  • 20 per letture di più documenti, transazioni e scritture in batch. Per ogni operazione vale anche il precedente limite di 10.

    Ad esempio, immagina di creare una richiesta di scrittura in batch con 3 operazioni di scrittura e che le regole di sicurezza utilizzino 2 chiamate di accesso ai documenti per convalidare ciascuna scrittura. In questo caso, ciascuna scrittura utilizza 2 delle sue 10 chiamate di accesso e la richiesta di scrittura in batch utilizza 6 delle sue 20 chiamate di accesso.

Il superamento di uno dei limiti genera un errore di autorizzazione negata. Alcune chiamate di accesso ai documenti potrebbero essere memorizzate nella cache e le chiamate memorizzate nella cache non vengono conteggiate ai fini dei limiti.

Per una spiegazione dettagliata di come questi limiti influiscono sulle transazioni e sulle scritture in batch, consultare la guida per la protezione delle operazioni atomiche .

Accedi a chiamate e prezzi

L'utilizzo di queste funzioni esegue un'operazione di lettura nel database, il che significa che ti verrà addebitata la lettura dei documenti anche se le tue regole rifiutano la richiesta. Consulta i prezzi di Cloud Firestore per informazioni di fatturazione più specifiche.

Funzioni personalizzate

Man mano che le regole di sicurezza diventano più complesse, potresti voler racchiudere serie di condizioni in funzioni che puoi riutilizzare nel tuo set di regole. Le regole di sicurezza supportano funzioni personalizzate. La sintassi per le funzioni personalizzate è un po' come JavaScript, ma le funzioni delle regole di sicurezza sono scritte in un linguaggio specifico del dominio che presenta alcune importanti limitazioni:

  • Le funzioni possono contenere solo una singola istruzione return . Non possono contenere alcuna logica aggiuntiva. Ad esempio, non possono eseguire cicli o chiamare servizi esterni.
  • Le funzioni possono accedere automaticamente a funzioni e variabili dall'ambito in cui sono definite. Ad esempio, una funzione definita nell'ambito del service cloud.firestore ha accesso alla variabile resource e alle funzioni integrate come get() ed exists() .
  • Le funzioni possono chiamare altre funzioni ma non possono ricorrere. La profondità totale dello stack di chiamate è limitata a 10.
  • Nella versione v2 delle regole, le funzioni possono definire variabili utilizzando la parola chiave let . Le funzioni possono avere fino a 10 associazioni let, ma devono terminare con un'istruzione return.

Una funzione è definita con la parola chiave function e accetta zero o più argomenti. Ad esempio, potresti voler combinare i due tipi di condizioni utilizzati negli esempi precedenti in un'unica funzione:

service cloud.firestore {
  match /databases/{database}/documents {
    // 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 /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

L'utilizzo delle funzioni nelle regole di sicurezza le rende più gestibili man mano che la complessità delle regole aumenta.

Le regole non sono filtri

Una volta protetti i tuoi dati e iniziato a scrivere query, tieni presente che le regole di sicurezza non sono filtri. Non puoi scrivere una query per tutti i documenti in una raccolta e aspettarti che Cloud Firestore restituisca solo i documenti a cui il client corrente è autorizzato ad accedere.

Ad esempio, prendiamo la seguente regola di sicurezza:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

Negato : questa regola rifiuta la seguente query perché il set di risultati può includere documenti la cui visibility non è public :

ragnatela
db.collection("cities").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
    });
});

Consentito : questa regola consente la seguente query perché la clausola where("visibility", "==", "public") garantisce che il set di risultati soddisfi la condizione della regola:

ragnatela
db.collection("cities").where("visibility", "==", "public").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
        });
    });

Le regole di sicurezza di Cloud Firestore valutano ogni query rispetto al suo potenziale risultato e falliscono la richiesta se potrebbe restituire un documento che il client non è autorizzato a leggere. Le query devono rispettare i vincoli stabiliti dalle regole di sicurezza. Per ulteriori informazioni sulle regole e sulle query di sicurezza, vedere esecuzione di query sicure sui dati .

Prossimi passi