כללי אבטחה לפעולות בצינור

למרות שלפעולות של צינור עיבוד הנתונים יש מגוון רחב של תכונות, מנוע הכללים מוגבל לזיהוי של מסנני השוואה (למשל >) ולוגיים (למשל or) כדי להבטיח את האפשרות לספק אילוצים ואת האבטחה.

ביטויי סינון נתמכים

כדי שהפעולות בצינור יוגבלו לגבולות שהוגדרו בכללים, צריך להשתמש באופרטורים לוגיים ולהשוות בין קבועים. מנוע הכללים מזהה את סוגי המסננים הבאים:

• השוואות: eq, neq, gt, gte, lt, lte, in, arrayContains.
• Logical: and, or.

הנה כמה דוגמאות:

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

מאפייני הבקשה

עדיין אפשר להשתמש באובייקט request כדי לאמת את ההזדהות ולשאול על ההקשר, אבל חלק מהמאפיינים שזמינים בשאילתות רגילות לא נתמכים בפעולות של צינורות.

מאפיינים נתמכים

המנוע החדש ממשיך לתמוך במאפיינים הבאים:

• ‫request.auth: גישה לנתוני uid ואסימון של משתמשים.
• ‫request.method: מזהה את הפעולה (לדוגמה, get, ‏ list).
• ‫request.path: הנתיב של המשאב שאליו מתבצעת גישה.
• ‫request.time: חותמת הזמן בצד השרת של הבקשה.

מאפיינים שלא נתמכים

לא ניתן להשתמש במאפיינים של request.query כמו limit, ‏ offset ו-orderBy בבדיקות של כללי פעולות בצינור עיבוד הנתונים, כי קשה לקבוע את הערכים האלה בשאילתות מרובות שלבים.

טיפול בשלב בצינור עיבוד נתונים והרשאות

יש שלבים שונים בצינור שמתאימים לפעולות ספציפיות ומפורטות בכללי האבטחה:

• הרשאות allow list: מופעלות על ידי שלבי collection(), collectionGroup() ו-database().
• allow get הרשאות: מופעל על ידי השלב documents(), שמתייחסים אליו באופן דומה לפעולת get אצווה.
• שלב הליטרלים: בשלב literals() לא מתבצעת קריאה ממסד הנתונים, אבל יכולות להיות עלויות. כדי למנוע שימוש לרעה, צריך לשלב אותו עם שלב אחר (כמו collection()) שאפשר לאמת באמצעות כללים.

שלבי השינוי של השדה

הכללים פועלים רק על נתונים מאוחסנים ולא על ערכים נגזרים. אם צינור הנתונים כולל שלבים שמשנים שדות (לדוגמה, add_fields(...),‏ replace_with(...),‏ select(...),‏ remove_fields(...)), מנוע הכללים מפסיק להחיל אילוצי סינון אחרי השלב הזה. כדי לוודא שהכללים פועלים כמצופה, צריך למקם את שלבי הסינון (כלומר where) לפני שלבים שיכולים לשנות את המסמכים המקוריים שמאוחסנים.

לדוגמה, ניקח את כלל האבטחה הבא:

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

נדחה: הכלל הזה דוחה את צינור העיבוד הבא כי השלב addFields מתרחש לפני הסינון למסמכים שבהם 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();

מותר: הכלל הזה מאפשר את צינור הנתונים הבא כי השלב where(eq(field("visibility"), constant("public"))) מתרחש לפני כל שלבי השינוי:

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