כללי אבטחה ואימות ב-Firebase

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

זיהוי משתמשים

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

• uid: מזהה משתמש ייחודי שהוקצה למשתמש המבקש.
• token: מפה של ערכים שנאספו על ידי Authentication.

המשתנה auth.token מכיל את הערכים הבאים:

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

כשהמשתמש שמבקש גישה לא מחובר, הערך של המשתנה auth הוא null. אפשר להשתמש בזה בכללים, אם רוצים, למשל, להגביל את הגישה לקריאה למשתמשים מאומתים – auth != null. עם זאת, באופן כללי מומלץ להגביל עוד יותר את הרשאת הכתיבה.

למידע נוסף על המשתנה auth, עיינו במאמרי העזרה של Cloud Firestore, Realtime Database ו-Cloud Storage.

שימוש בפרטי משתמשים בכללים

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

בכללים, מגדירים איך המידע במשתנה auth – פרטי המשתמש של מבצע הבקשה – תואם לפרטי המשתמש שמשויכים לנתונים המבוקשים.

לדוגמה, יכול להיות שאתם רוצים לוודא שהמשתמשים באפליקציה יוכלו לקרוא ולכתוב רק את הנתונים שלהם. בתרחיש הזה, צריכה להיות התאמה בין המשתנה auth.uid לבין מזהה המשתמש בנתונים המבוקשים:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

{
  "rules": {
    "users": {
      "$userId": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($userId)
        ".write": "$userId === auth.uid"
      }
    }
  }
}

service firebase.storage {
  // Only a user can upload their file, but anyone can view it
  match /users/{userId}/{fileName} {
    allow read;
    allow write: if request.auth != null && request.auth.uid == userId;
  }
}

הגדרת פרטי משתמשים בהתאמה אישית

אפשר להשתמש במשתנה auth גם כדי להגדיר שדות מותאמים אישית שמוקצים למשתמשים באפליקציה.

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

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

service cloud.firestore {
  match /databases/{database}/documents/some_collection: {
    // Remember that, in Cloud Firestore, reads embedded in your rules are billed operations
    write: if request.auth != null && get(/databases/(database)/documents/users/$(request.auth.uid)).data.admin == true;
    read: if request.auth != null;
  }
}

אפשר לגשת לטענות נכונות בהתאמה אישית ב-Rules אחרי שיוצרים טענות נכונות בהתאמה אישית ב-Authentication. לאחר מכן תוכלו להפנות להצהרות המותאמות אישית האלה באמצעות המשתנה auth.token.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an admin claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

{
  "rules": {
    "some_path/$sub_path": {
      // Create a custom claim for the admin role
      ".write": "auth.uid !== null && auth.token.writer === true"
      ".read": "auth.uid !== null"
      }
    }
  }

service firebase.storage {
  // Create a custom claim for the admin role
  match /files/{fileName} {
    allow read: if request.auth.uid != null;
    allow write: if request.auth.token.admin == true;
  }
}

דוגמאות נוספות לשימוש ב-Rules לצורך ניצול של Authentication מפורטות במאמר כללי אבטחה בסיסיים.