Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Condizioni di scrittura per le regole di sicurezza di Cloud Firestore

Questa guida si basa sulla guida alla strutturazione delle regole di sicurezza per mostrare come aggiungere condizioni alle regole di sicurezza del Cloud Firestore. Se non si ha familiarità con le basi del cloud Firestore Regole di sicurezza, vedere il introduttiva guida.

Il blocco predefinito delle regole di sicurezza di Cloud Firestore è la condizione. Una condizione è un'espressione booleana che determina se una determinata operazione deve essere consentita o negata. Utilizzare le regole di sicurezza per scrivere condizioni che controllano l'autenticazione dell'utente, convalidare i dati in arrivo o persino accedere ad altre parti del database.

Autenticazione

Uno dei modelli di regole di sicurezza più comuni è il controllo dell'accesso basato sullo stato di autenticazione dell'utente. Ad esempio, l'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 l'app utilizza l'autenticazione Firebase, la variabile request.auth contiene le informazioni di autenticazione per i dati di richiesta del client. Per ulteriori informazioni su request.auth , consultare la documentazione di riferimento .

Convalida dei dati

Molte app memorizzano le informazioni di controllo dell'accesso come campi nei 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 di resource riferisce al documento richiesto e resource.data è una mappa di tutti i campi e valori memorizzati nel documento. Per ulteriori informazioni sulla variabile di resource , consultare la documentazione di riferimento .

Quando si scrivono dati, è possibile che si desideri confrontare i dati in entrata con quelli esistenti. In questo caso, se il set di regole consente la scrittura in sospeso, la variabile request.resource contiene lo stato futuro del documento. Per le operazioni di update che modificano solo un sottoinsieme dei campi del documento, la variabile request.resource conterrà lo stato del documento in sospeso dopo l'operazione. È possibile controllare i valori dei campi in request.resource per impedire 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() aspettano entrambi percorsi di documento completamente specificati. Quando si utilizzano le variabili per costruire percorsi per get() ed exists() , è necessario uscire esplicitamente dalle variabili utilizzando la sintassi $(variable) .

Nell'esempio seguente, la variabile del database viene acquisita 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 batch di scritture, ma prima che la transazione o il batch getAfter() . Come get() , la funzione getAfter() accetta un percorso documento completamente specificato. È possibile utilizzare getAfter() per definire insiemi di scritture che devono avvenire insieme come transazione o batch.

Accedi ai limiti di chiamata

Esiste un limite per le chiamate di accesso ai documenti per valutazione della serie di regole:

  • 10 per richieste di documenti singoli e richieste di query.
  • 20 per letture di più documenti, transazioni e scritture in batch. Il limite precedente di 10 si applica anche a ciascuna operazione.

    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 al documento 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 nella cache non contano ai fini dei limiti.

Per una spiegazione dettagliata di come questi limiti influenzano le transazioni e le scritture in batch, consultare la guida per proteggere le operazioni atomiche .

Accedi a chiamate e prezzi

L'utilizzo di queste funzioni esegue un'operazione di lettura nel database, il che significa che verrà addebitato il costo per la lettura dei documenti anche se le 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, è possibile che si desideri racchiudere insiemi di condizioni in funzioni che è possibile riutilizzare nel 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 dichiarazione di return . Non possono contenere alcuna logica aggiuntiva. Ad esempio, non possono eseguire loop o chiamare servizi esterni.
  • Le funzioni possono accedere automaticamente alle funzioni e alle variabili dall'ambito in cui sono definite. Ad esempio, una funzione definita nell'ambito del service cloud.firestore ha accesso alla variabile di resource e 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 regole, le funzioni possono definire le variabili usando la parola chiave let . Le funzioni possono avere fino a 10 vincoli 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 utilizzate negli esempi sopra 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'uso delle funzioni nelle regole di sicurezza le rende più gestibili con l'aumentare della complessità delle regole.

Le regole non sono filtri

Dopo aver protetto i dati e aver iniziato a scrivere query, tenere presente che le regole di sicurezza non sono filtri. Non è possibile scrivere una query per tutti i documenti in una raccolta e aspettarsi che Cloud Firestore restituisca solo i documenti a cui il client corrente ha l'autorizzazione ad accedere.

Ad esempio, prendi 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 poiché il set di risultati può includere documenti in cui la 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 poiché la clausola where("visibility", "==", "public") garantisce che il set di risultati soddisfi le condizioni 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 non soddisfano la richiesta se potrebbero restituire un documento che il client non ha l'autorizzazione a leggere. Le query devono seguire i vincoli stabiliti dalle regole di sicurezza. Per ulteriori informazioni su regole e query di sicurezza, consultare la sezione relativa alla query sicura dei dati .

Prossimi passi