אבטחת נתוני משתמשים

Firebase Security Rules ל-Cloud Storage משתלב עם Firebase Authentication כדי לספק אימות מבוסס-משתמשים רב עוצמה ל-Cloud Storage. כך אפשר בקרת גישה פרטנית שמבוססת על הצהרות על אסימון Firebase Authentication.

אימות משתמשים

כשמשתמש מאומת שולח בקשה נגד Cloud Storage, המשתנה request.auth מאוכלס ב-uid של המשתמש (request.auth.uid) וגם להצהרות של JWT Firebase Authentication (request.auth.token).

בנוסף, כשמשתמשים באימות מותאם אישית, יוצגו תלונות נוספות בשדה request.auth.token.

כשמשתמש לא מאומת מבצע בקשה, המשתנה request.auth null.

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

• ציבורי: התעלמות מ-request.auth
• פרטי מאומת: יש לוודא ש-request.auth אינו null
• משתמש פרטי: בודקים ש-request.auth.uid שווה לנתיב uid
• קבוצה פרטית: בודקים את ההצהרות של האסימון המותאם אישית כדי להתאים להצהרה שנבחרה, או לקרוא את המטא-נתונים של הקובץ כדי לבדוק אם קיים שדה מטא-נתונים

גלוי לכולם

כל כלל שלא מתייחס להקשר של request.auth יכול להיחשב public, כי הוא לא מביא בחשבון את הקשר האימות של המשתמש. הכללים האלה יכולים להיות שימושיים כדי להציג נתונים ציבוריים, כמו נכסי משחקים, קובצי קול או תוכן סטטי אחר.

// Anyone to read a public image if the file is less than 100kB
// Anyone can upload a public file ending in '.txt'
match /public/{imageId} {
  allow read: if resource.size < 100 * 1024;
  allow write: if imageId.matches(".*\\.txt");
}

פרטי מאומת,

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

// Require authentication on all internal image reads
match /internal/{imageId} {
  allow read: if request.auth != null;
}

פרטי למשתמש

התרחיש הנפוץ ביותר לשימוש ב-request.auth הוא מתן הרשאות מפורטות על הקבצים של משתמשים ספציפיים: החל מהעלאת תמונות פרופיל ועד לקריאת מסמכים פרטיים.

לקבצים ב-Cloud Storage יש נתיב מלא אל הקובץ, לכן כל מה שצריך לעשות הוא ליצירת קובץ שנשלט על ידי משתמש הוא קטע מידע בנתיב הקובץ (למשל, uid של המשתמש), שניתן לבדוק הכלל נבדק:

// Only a user can upload their profile picture, but anyone can view it
match /users/{userId}/profilePicture.png {
  allow read;
  allow write: if request.auth != null && request.auth.uid == userId;
}

קבוצה פרטית

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

• הטבעת אסימון בהתאמה אישית של Firebase Authentication שמכיל מידע נוסף על חבר קבוצה (כמו מזהה קבוצה)
• מטא-נתוני הקובץ צריכים לכלול את פרטי הקבוצה (כמו מזהה קבוצה או רשימת uid מורשים)

אחרי שהנתונים האלה מאוחסנים במטא-נתונים של האסימון או הקובץ, אפשר להפנות אליהם מתוך כלל:

// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

דוגמה מלאה

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

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Anyone can view any image (no auth, publicly readable)
      match /{allImages=**} {
        allow read;
      }

      // Only authenticated users can write to "public" images
      match /public/{imageId} {
        allow write: if request.auth != null;
      }

      // Only an individual user can write to "their" images
      match /{userId}/{imageId} {
        allow write: if request.auth.uid == userId;
      }

      // Allow a "group" of users to read/write to shared images
      // An owner metadata property on the object contains the groupId for reads
      // A custom token has been minted with a groupId property for writes
      match /{groupId}/{imageId} {
        allow read: if resource.metadata.owner == request.auth.token.groupId;
        allow write: if request.auth.token.groupId == groupId;
      }
    }
  }
}