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

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

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

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

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

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

שדה	תיאור
email	כתובת האימייל שמשויכת לחשבון, אם יש כזו.
email_verified	true אם המשתמש אימת שיש לו גישה לכתובת email. חלק מהספקים מאמתים באופן אוטומטי את כתובות האימייל שבבעלותם.
phone_number	מספר הטלפון שמשויך לחשבון, אם יש כזה.
name	השם המוצג של המשתמש, אם הוא הוגדר.
sub	מזהה המשתמש ב-Firebase. הערך הזה ייחודי לפרויקט.
firebase.identities	מילון של כל הזהויות שמשויכות לחשבון של המשתמש הזה. המפתחות של המילון יכולים להיות כל אחד מהבאים: email, phone, google.com, facebook.com, github.com, twitter.com. הערכים של המילון הם מערכים של מזהים ייחודיים לכל ספק זהויות שמשויך לחשבון. לדוגמה, auth.token.firebase.identities["google.com"][0] מכיל את מזהה המשתמש הראשון ב-Google שמשויך לחשבון.
firebase.sign_in_provider	ספק הכניסה ששימש לקבלת האסימון הזה. יכול להיות אחת מהמחרוזות הבאות: custom,‏ password,‏ phone,‏ anonymous,‏ google.com,‏ facebook.com,‏ github.com,‏ twitter.com.
firebase.tenant	ה-tenantId שמשויך לחשבון, אם קיים. לדוגמה, tenant2-m6tyz

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

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

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

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

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

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

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

Cloud Firestore

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

Realtime Database

{
  "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"
      }
    }
  }
}

Cloud Storage

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, אתם יכולים להוסיף שדה מותאם אישית למסמכים של המשתמשים ולאחזר את הערך של השדה הזה באמצעות קריאה מוטמעת בכללים שלכם. לכן, הכלל שמבוסס על אדמין ייראה כמו בדוגמה הבאה:

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

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

Cloud Firestore

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

Realtime Database

{
  "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"
      }
    }
  }
}

Cloud Storage

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

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