Firebase Security Rules מספקים בקרת גישה ואימות נתונים בפורמט שתומך כמה רמות מורכבות. כדי לפתח מערכות גישה מבוססות-משתמשים ומבוססות-תפקידים שישמרו על אבטחת נתונים, יש להשתמש ב-Firebase Authentication עם Firebase Security Rules
זיהוי משתמשים
Authentication מזהה משתמשים שמבקשים גישה לנתונים שלך ומספק את הפרטים הבאים:
בתור משתנה שניתן להשתמש בו בכללים. המשתנה auth
מכיל את המידע הבא:
uid
: מזהה משתמש ייחודי שמוקצה למשתמש ששלח את הבקשה.token
: מפת ערכים שנאספו על ידי Authentication.
המשתנה auth.token
מכיל את הערכים הבאים:
שדה | תיאור |
---|---|
email |
כתובת האימייל המשויכת לחשבון, אם יש כזו. |
email_verified |
true אם המשתמש אימת שיש לו גישה לכתובת email . ספקים מסוימים מאמתים באופן אוטומטי כתובות אימייל שבבעלותם. |
phone_number |
מספר הטלפון המשויך לחשבון, אם קיים. |
name |
השם המוצג של המשתמש, אם מוגדר. |
sub |
ה-UID ב-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;
}
}
אפשר לגשת לטענות נכונות בהתאמה אישית ב-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;
}
}
דוגמאות נוספות לשימוש ב-Rules לצורך ניצול Authentication מפורטות במאמר כללי אבטחה בסיסיים.