מבנה כללי אבטחה של Cloud Firestore

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

מדריך זה מתאר את התחביר הבסיסי של כללי האבטחה. מערבבי התחביר הזה עם תנאי כללי ביטחון ליצור rulesets המוחלטת.

הצהרת שירות ומאגר מידע

כללי האבטחה של Cloud Firestore תמיד מתחילים בהצהרה הבאה:

service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}

service cloud.firestore הכרזת טווחי כללי הענן Firestore, מניעת קונפליקטים בין ענן Firestore אבטחה חוקי ותקנון למוצרים אחרים כגון אחסון ענן.

match /databases/{database}/documents מציין הצהרה כי הכללים צריכים להתאים לכל הנתונים ענן Firestore בפרויקט. בשלב זה כל פרויקט יש מסד נתונים יחיד בשם (default) .

כללי קריאה/כתיבה בסיסיים

כללים בסיסיים מורכב match אמירה לציין נתיב מסמך ו allow ביטוי המפרט בעת קריאת הנתונים שצוינו מותר:

service cloud.firestore {
  match /databases/{database}/documents {

    // Match any document in the 'cities' collection
    match /cities/{city} {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

כל הצהרות ההתאמה צריכות להצביע על מסמכים, לא על אוספים. הצהרה המשחק יכול להצביע על מסמך ספציפי, כמו match /cities/SF כלליים או שימוש כדי להצביע על כל מסמך בנתיב שצוין, כמו match /cities/{city} .

בדוגמא לעיל, הצהרת המשחק משתמשת {city} תחביר הכללי. אמצעי זה הכלל חל על כל מסמך של cities אוסף, כגון /cities/SF או /cities/NYC . כאשר allow ביטויים בדוח ההתאמה מוערכים, את city משתנה יפתור את שם המסמך העיר, כגון SF או NYC .

פעולות גרגיריות

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

read כלל ניתן לחלק get ואת list , ואילו write כלל ניתן לחלק create , update , וכן delete :

service cloud.firestore {
  match /databases/{database}/documents {
    // A read rule can be divided into get and list rules
    match /cities/{city} {
      // Applies to single document read requests
      allow get: if <condition>;

      // Applies to queries and collection read requests
      allow list: if <condition>;
    }

    // A write rule can be divided into create, update, and delete rules
    match /cities/{city} {
      // Applies to writes to nonexistent documents
      allow create: if <condition>;

      // Applies to writes to existing documents
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
}

נתונים היררכיים

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

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

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

        // Explicitly define rules for the 'landmarks' subcollection
        match /landmarks/{landmark} {
          allow read, write: if <condition>;
        }
    }
  }
}

כאשר קינון match הצהרות, את הנתיב של פנימית match ההצהרה הוא תמיד יחסים לנתיב של החיצוני match בהצהרה. מערכי הכללים הבאים שווים אפוא:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}
service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

תווים כלליים רקורסיביים

אם אתה רוצה כללים שיחולו על היררכיה עמוקה באופן שרירותי, השתמש בתחביר הכללי רקורסיבית, {name=**} . לדוגמה:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

בעת שימוש בתחביר התווים הרקורסיביים, משתנה התווים כלל יכיל את כל קטע נתיב ההתאמה, גם אם המסמך ממוקם באוסף משנה מקונן עמוק. לדוגמה, הכללים המפורטים לעיל יתאימו מסמך הממוקם /cities/SF/landmarks/coit_tower , ואת הערך של document משתנה יהיה SF/landmarks/coit_tower .

עם זאת, שים לב שהתנהגותם של תווים כלליים רקורסיביים תלויה בגרסת החוקים.

גרסה 1

כללי האבטחה משתמשים בגרסה 1 כברירת מחדל. בגרסה 1, תווים כלליים רקורסיביים תואמים פריט נתיב אחד או יותר. הם אינם תואמים שביל ריק, אז match /cities/{city}/{document=**} תואם מסמכים מהתת-אוספים אך לא cities אוספות, ואילו match /cities/{document=**} תואם הן מסמכים cities איסוף מהתת-אוספים.

תווים כלליים רקורסיביים חייבים להגיע בסוף הצהרת משחק.

גרסה 2

בגרסה 2 של כללי האבטחה, תווים כלליים רקורסיביים תואמים לאפריטי נתיב או יותר. match/cities/{city}/{document=**} תואם מסמכים בכול מהתת-אוספים, כמו גם מסמכי cities האוספים.

עליך להצטרף כדי גירסה 2 על ידי הוספת rules_version = '2'; בראש כללי האבטחה שלך:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

תוכל לכלול תו כללי רקורסיבי אחד לכל משפט התאמה, אך בגרסה 2 תוכל למקם את התו הכללי בכל מקום בהצהרת ההתאמה. לדוגמה:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

אם אתה משתמש שאילתות קבוצה אוספות , עליך להשתמש בגרסה 2, רואה באבטחת שאילתות קבוצה אוספת .

הצהרות התאמה חופפות

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

בדוגמה לעיל, כול קריאה וכתיבה אל cities אוספות תוותר כי הכלל השני הוא תמיד true , למרות הכלל הראשון הוא תמיד false .

מגבלות חוק האבטחה

כאשר אתה עובד עם כללי אבטחה, שים לב למגבלות הבאות:

לְהַגבִּיל פרטים
מספר מרבי של exists() , get() , ולאחר getAfter() קוראת לכל בקשה
  • 10 לבקשות של מסמך יחיד ובקשות שאילתה.
  • 20 עבור קריאה מרובה מסמכים, עסקאות וכתיבה בקבוצות. המגבלה הקודמת של 10 חלה גם על כל פעולה.

    לדוגמה, דמיין שאתה יוצר בקשת כתיבה באצווה עם 3 פעולות כתיבה ושכללי האבטחה שלך משתמשים בשתי שיחות גישה למסמכים כדי לאמת כל כתיבה. במקרה זה, כל כתיבה משתמשת ב -2 מתוך 10 שיחות הגישה שלה ובקשת הכתיבה המצוות משתמשת ב -6 מתוך 20 שיחות הגישה שלה.

חריגה ממגבלה גורמת לשגיאת שלילת הרשאה.

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

מקוננות מקסימלי match לעומק הצהרה 10
אורך שביל מקסימאלי, פלחי נתיב, מותר בתוך קבוצה של מקוננות match דוחה 100
מספר מרבי של משתנה ללכוד נתיב מותר בתוך קבוצה של מקוננות match דוחה 20
עומק שיחות פונקציונלי מרבי 20
המספר המרבי של ארגומנטים של פונקציות 7
מספר מרבי של let איגודי משתנה לכל פונקציה 10
מספר מקסימלי של שיחות פונקציה רקורסיבית או מחזורית 0 (אסור)
מספר הביטויים המרבי המוערך לכל בקשה 1,000
גודל מקסימלי של מערכת כללים ערכות הכללים חייבות לציית לשתי מגבלות גודל:
  • מגבלת 256 KB בגודל של מקור טקסט מערכת הכללים שפורסם מתוך Firebase הקונסולה או מן CLI באמצעות firebase deploy .
  • מגבלה של 250 KB על גודל מערך הכללים המורכב המתקבל כאשר Firebase מעבד את המקור והופך אותו לפעיל בקצה האחורי.

הצעדים הבאים