Scrivi le condizioni per le regole di sicurezza

Questa guida si basa sulla guida relativa alla strutturazione delle regole di sicurezza e mostra come aggiungere condizioni alle regole di sicurezza di Firestore. Se non conosci le nozioni di base sulle regole di sicurezza di Firestore, consulta la guida introduttiva.

Il componente di base principale delle regole di sicurezza di Firestore è la condizione. Una condizione è un'espressione booleana che determina se una determinata operazione deve essere consentita o negata. Utilizza le regole di sicurezza per scrivere condizioni che controllano l'autenticazione degli utenti, convalidare i dati in entrata o persino accedere ad altre parti del tuo database.

Autenticazione

Uno dei pattern di regole di sicurezza più comuni è il controllo dell'accesso in base allo stato dell'autenticazione dell'utente. Ad esempio, la tua app potrebbe voler consentire solo agli utenti che hanno eseguito 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 pattern comune è assicurarsi che gli utenti possano leggere e scrivere solo 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 l'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, consulta la documentazione di riferimento.

Convalida dei dati

Molte app memorizzano le informazioni di controllo dell'accesso come campi sui documenti nel database. Le regole di sicurezza di Firestore possono consentire o negare dinamicamente l'accesso in base ai dati dei documenti:

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 fa riferimento al documento richiesto e resource.data è una mappa di tutti i campi e i valori archiviati nel documento. Per ulteriori informazioni sulla variabile resource, consulta la documentazione di riferimento.

Durante la scrittura dei dati, è consigliabile confrontare i dati in entrata con quelli esistenti. In questo caso, se il set di regole consente la scrittura in attesa, 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 In attesa del documento dopo l'operazione. Puoi controllare i valori dei campi in request.resource per impedire aggiornamenti indesiderati o incoerenti dei dati:

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

Accedere ad altri documenti

Utilizzando le funzioni get() e exists(), le regole di sicurezza possono valutare le richieste in arrivo rispetto ad altri documenti nel database. Entrambe le funzioni get() e exists() prevedono percorsi dei documenti completamente specificati. Quando utilizzi le variabili per creare percorsi per get() e exists(), devi utilizzare la sintassi $(variable) in modo esplicito di escape.

Nell'esempio riportato di seguito, la variabile database viene acquisita dall'istruzione di corrispondenza 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, puoi 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() utilizza un percorso del documento completamente specificato. Puoi utilizzare getAfter() per definire set di scritture che devono avvenire insieme come transazione o batch.

Accedere ai limiti delle chiamate

Esiste un limite alle chiamate di accesso ai documenti per valutazione di una serie di regole:

  • 10 per richieste di documenti singoli e di query.

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

    Ad esempio, immagina di creare una richiesta di scrittura in batch con 3 operazioni di scrittura e che le tue regole di sicurezza utilizzino 2 chiamate di accesso ai documenti per convalidare ogni scrittura. In questo caso, ogni 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 comporta un errore di autorizzazione negata. Alcune chiamate di accesso ai documenti possono 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, consulta la guida per proteggere le operazioni atomiche.

Accedi alle chiamate e ai 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 regole rifiutano la richiesta. Consulta i prezzi di Firestore per informazioni più specifiche sulla fatturazione.

Funzioni personalizzate

Man mano che le regole di sicurezza diventano più complesse, potresti voler aggregare insiemi di condizioni in funzioni che puoi riutilizzare nel set di regole. Le regole di sicurezza supportano funzioni personalizzate. La sintassi per le funzioni personalizzate è simile a 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 una sola istruzione return. e non possono contenere alcuna logica aggiuntiva. Ad esempio, non possono eseguire loop 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 service cloud.firestore ha accesso alla variabile resource e alle funzioni integrate come get() e exists().
  • Le funzioni possono chiamare altre funzioni ma non sono ricorrenti. La profondità totale dello stack di chiamate è limitata a 10.
  • Nella versione delle regole v2, le funzioni possono definire le variabili utilizzando la parola chiave let. Le funzioni possono avere fino a 10 associazioni L, ma devono terminare con un'istruzione restituita.

Una funzione viene definita con la parola chiave function e prende zero o più argomenti. Ad esempio, puoi combinare i due tipi di condizioni usati 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 ne aumenta la gestibilità man mano che la complessità delle regole aumenta.

Le regole non sono filtri

Dopo aver protetto i 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 di una raccolta e puoi aspettarti che Firestore restituisca solo i documenti a cui il client attuale è autorizzato ad accedere.

Ad esempio, considera 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';
    }
  }
}

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

Web 
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:

Web 
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 Firestore valutano ogni query in base al relativo risultato potenziale e non vanno a buon fine se la richiesta restituisce un documento che il client non dispone dell'autorizzazione di lettura. Le query devono seguire i vincoli impostati dalle tue regole di sicurezza. Per ulteriori informazioni su regole e query di sicurezza, consulta l'articolo su come eseguire query sui dati in modo sicuro.

Passaggi successivi