Regole di sicurezza per le operazioni della pipeline

Sebbene le operazioni di pipeline offrano un ricco set di funzionalità, il motore delle regole è limitato al riconoscimento dei filtri di confronto (ad es. >) e logici (ad es. or) per garantire la soddisfacibilità e la sicurezza dei vincoli.

Espressioni di filtro supportate

Affinché le operazioni di pipeline siano vincolate ai limiti impostati dalle regole, devono utilizzare operatori logici e di confronto rispetto alle costanti. Il motore delle regole riconosce i seguenti tipi di filtri:

• Confronti: eq, neq, gt, gte, lt, lte, in, arrayContains.
• Logici: and, or.

Ecco alcuni esempi:

• where(eq("foo", 2))
• where(lt("foo", 2))
• documents("/user/1", "/user/2").where(...)

Proprietà della richiesta

Puoi continuare a utilizzare l' request oggetto per convalidare l'autenticazione e il contesto della query, anche se alcune proprietà disponibili nelle query standard non sono supportate nelle operazioni di pipeline.

Proprietà supportate

Il nuovo motore continua a supportare le seguenti proprietà:

• request.auth: accedi ai dati del token e dell'UID utente.
• request.method: identifica l'operazione (ad es. get, list).
• request.path: il percorso della risorsa a cui si accede.
• request.time: il timestamp lato server della richiesta.

Proprietà non supportate

Le proprietà request.query, come limit, offset e orderBy, non sono supportate per i controlli delle regole delle operazioni di pipeline a causa della complessità della determinazione di questi valori nelle query multifase.

Gestione delle fasi della pipeline e autorizzazioni

Esistono diverse fasi della pipeline che eseguono il mapping a operazioni granulari specifiche nelle regole di sicurezza:

• Autorizzazioni allow list: attivate dalle fasi collection(), collectionGroup() e database().
• allow get autorizzazioni: attivate dalla fase documents(), che viene trattata in modo simile a un'operazione get batch.
• Fase dei valori letterali: la fase literals() non legge dal database, ma può comportare costi. Per evitare abusi, deve essere associata a un'altra fase (ad es. collection()) che può essere verificata dalle regole.

Fasi di modifica dei campi

Le regole operano solo sui dati archiviati e non sui valori derivati. Se una pipeline include fasi che modificano i campi (ad es. add_fields(...), replace_with(...), select(...), remove_fields(...)), il motore delle regole smette di applicare i vincoli di filtro dopo che viene rilevata la fase. Per assicurarti che le regole funzionino come previsto, posiziona le fasi di filtro (ovvero where) prima di qualsiasi fase che possa modificare i documenti archiviati originali.

Ad esempio, prendi la seguente regola di sicurezza:

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

Negata: questa regola rifiuta la seguente pipeline perché la fase addFields si verifica prima del filtraggio dei documenti in cui visibility è public:

const results = await db.pipeline()
  .collection("/cities")
  // Filters after a modification stage are ignored by Rules.
  .addFields(constant(1000).as("population"))
  .where(eq(field("visibility"), constant("public")))
  .execute();

Consentita: questa regola consente la seguente pipeline perché la fase where(eq(field("visibility"), constant("public"))) si verifica prima di qualsiasi fase di modifica:

const results = await db.pipeline()
  .collection("/cities")
  .where(eq(field("visibility"), constant("public")))
  .addFields(constant(1000).as("population"))
  .execute();