Scrivi le condizioni per le regole di sicurezza
Questa guida si basa sulla guida Strutturare le regole di sicurezza per mostrare come aggiungere condizioni alle regole di sicurezza di Firestore. Se non sei nozioni di base sulle regole di sicurezza di Firestore, consulta la guida introduttiva. guida.
Il componente di base principale delle regole di sicurezza di Firestore è la condizione. R condizione è un'espressione booleana che determina se una determinata operazione deve essere consentito o negato. Utilizza le regole di sicurezza per scrivere condizioni che controllare l'autenticazione degli utenti, convalidare i dati in arrivo o persino accedere ad altre parti del database.
Autenticazione
Uno dei pattern di regole di sicurezza più comuni è il controllo dell'accesso in base lo stato dell'autenticazione dell'utente. Ad esempio, l'app potrebbe voler consentire utenti che hanno eseguito l'accesso per 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 metodo molto comune consiste nell'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
documentazione.
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 al documento dati:
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, mentre resource.data
è
una mappa di tutti i campi e i valori archiviati nel documento. Per ulteriori informazioni
informazioni sulla variabile resource
, consulta il riferimento
documentazione.
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, request.resource
contiene lo stato futuro del documento. Per le operazioni update
che solo
modificherà un sottoinsieme dei campi del documento, la variabile request.resource
contengono lo stato del documento "In sospeso" dopo l'operazione. Puoi controllare il campo
valori 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
in entrata rispetto ad altri documenti nel database. Le get()
e
Entrambe le funzioni exists()
prevedono percorsi dei documenti completamente specificati. Quando si utilizza
variabili per creare percorsi per get()
e exists()
, devi creare
utilizzando la sintassi $(variable)
.
Nell'esempio seguente, la variabile database
viene acquisita dalla corrispondenza
l'istruzione match /databases/{database}/documents
e utilizzata per creare 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 una
documento dopo il completamento di una transazione o di un gruppo di scritture, ma prima che
di transazioni o batch. Come nel caso di get()
, la funzione getAfter()
utilizza una
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 le scritture in batch. Il limite precedente di 10 si applica anche a operativa.
Ad esempio, immagina di creare una richiesta di scrittura in batch con 3 operazioni e che le regole di sicurezza utilizzino 2 chiamate di accesso ai documenti e convalidare ogni scrittura. In questo caso, ogni scrittura utilizza 2 dei suoi a 10 chiamate di accesso e la richiesta di scrittura in batch utilizza 6 dei suoi 20 accessi chiamate.
Il superamento di uno dei limiti comporta un errore di autorizzazione negata. Documento le chiamate di accesso 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 influenzano le transazioni e le scritture in batch, consulta la guida per proteggere le operazioni atomiche.
Accedi alle chiamate e ai prezzi
Questa funzione esegue un'operazione di lettura nel database, Ciò significa che ti verrà addebitato il costo della lettura dei documenti anche se le tue regole vengono rifiutate la richiesta. Vedi i prezzi di Firestore per informazioni più specifiche sulla fatturazione.
Funzioni personalizzate
Man mano che le regole di sicurezza diventano più complesse, è consigliabile aggregare insiemi in funzioni riutilizzabili nel set di regole. Regole di sicurezza e supportare 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 che presenta alcune importanti limitazioni:
- Le funzioni possono contenere una sola istruzione
return
. Non possono contenere qualsiasi logica aggiuntiva. Ad esempio, non possono eseguire loop o chiamate e servizi esterni. - Functions può accedere automaticamente a funzioni e variabili dall'ambito
in cui sono definiti. Ad esempio, una funzione definita all'interno di
l'ambito
service cloud.firestore
ha accesso alla variabileresource
e funzioni integrate comeget()
eexists()
. - Le funzioni possono chiamare altre funzioni ma non sono ricorrenti. La chiamata totale la profondità dello stack è limitata a 10.
- Nella versione delle regole
v2
, le funzioni possono definire le variabili utilizzando la parola chiavelet
. Le funzioni possono avere fino a 10 associazioni Consenti, ma devono terminare con un ritorno l'Informativa.
Una funzione viene definita con la parola chiave function
e prende zero o più
argomenti. Ad esempio, puoi combinare i due tipi di condizioni utilizzati
degli 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 di funzioni nelle regole di sicurezza ne rende più gestibili la complessità delle regole aumenta.
Le regole non sono filtri
Dopo aver protetto i dati e aver iniziato a scrivere query, tieni presente che le regole non sono filtri. Non puoi scrivere una query per tutti i documenti in un e si aspetta che Firestore restituisca solo i documenti che il client attuale dispone dell'autorizzazione 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 risultato è stato impostato
può includere documenti in cui visibility
non è public
:
A rete
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:
A rete
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 suo potenziale il risultato e la richiesta non va a buon fine se è possibile restituire un documento eseguito dal client non disponi dell'autorizzazione di lettura. Le query devono seguire i vincoli impostati le tue regole di sicurezza. Per ulteriori informazioni su regole e query di sicurezza, consulta Informazioni sulla sicurezza per eseguire query sui dati.
Passaggi successivi
- Scopri in che modo le regole di sicurezza influiscono sulle query.
- Scopri come strutturare le regole di sicurezza.
- Leggi la documentazione di riferimento alle regole di sicurezza.