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

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

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

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

• שווה ולא שווה: eq, neq.
• השוואות: gt, gte, lt, lte.
• חברות: in, arrayContains.

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

• 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 אצווה.
• שלבים בשינוי שדה: הכללים פועלים רק על נתונים מאוחסנים ולא על ערכים נגזרים. אם צינור כולל שלבים שמשנים שדות (לדוגמה, AddFields, ReplaceWith, Select), מנוע הכללים מפסיק להחיל אילוצי סינון אחרי השלב הזה.
• שלב Literals: השלב literals() לא קורא ממסד הנתונים, אבל יכול להיות שיהיו בו עלויות. כדי למנוע שימוש לרעה, צריך לשלב אותו עם שלב אחר (כמו collection()) שאפשר לאמת באמצעות כללים.