Join us in person and online for Firebase Summit on October 18, 2022. Learn how Firebase can help you accelerate app development, release your app with confidence, and scale with ease. Register now

قوانین اساسی امنیتی

با مجموعه‌ها، منظم بمانید ذخیره و دسته‌بندی محتوا براساس اولویت‌های شما.

قوانین امنیتی Firebase به شما امکان می دهد دسترسی به داده های ذخیره شده خود را کنترل کنید. سینتکس قوانین انعطاف پذیر به این معنی است که می توانید قوانینی را ایجاد کنید که با هر چیزی مطابقت داشته باشد، از همه نوشته ها گرفته تا کل پایگاه داده تا عملیات روی یک سند خاص.

این راهنما برخی از موارد استفاده اساسی‌تری را که ممکن است بخواهید هنگام راه‌اندازی برنامه و محافظت از داده‌های خود پیاده‌سازی کنید، توضیح می‌دهد. با این حال، قبل از شروع نوشتن قوانین، ممکن است بخواهید درباره زبانی که به آن نوشته شده و رفتار آنها بیشتر بدانید.

برای دسترسی و به‌روزرسانی قوانین خود، مراحل ذکر شده در مدیریت و استقرار قوانین امنیتی Firebase را دنبال کنید.

قوانین پیش فرض: حالت قفل شده

وقتی یک پایگاه داده یا نمونه ذخیره‌سازی در کنسول Firebase ایجاد می‌کنید، انتخاب می‌کنید که آیا قوانین امنیتی Firebase دسترسی به داده‌های شما را محدود می‌کند ( حالت قفل شده ) یا اجازه دسترسی به هر کسی را می‌دهد ( حالت آزمایشی ). در Cloud Firestore و Realtime Database، قوانین پیش‌فرض حالت قفل شده ، دسترسی همه کاربران را ممنوع می‌کند. در فضای ذخیره سازی ابری، فقط کاربران احراز هویت شده می توانند به سطل های ذخیره سازی دسترسی داشته باشند.

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

پایگاه داده بیدرنگ

{
  "rules": {
    ".read": false,
    ".write": false
  }
}

فضای ذخیره ابری

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

قوانین توسعه – محیط زیست

در حالی که روی برنامه خود کار می کنید، ممکن است بخواهید دسترسی نسبتاً باز یا بدون محدودیت به داده های خود داشته باشید. فقط مطمئن شوید که قوانین خود را قبل از استقرار برنامه خود در تولید به روز کنید. همچنین به یاد داشته باشید که اگر برنامه خود را اجرا کنید، برای عموم قابل دسترسی است - حتی اگر آن را راه‌اندازی نکرده باشید.

به یاد داشته باشید که Firebase به مشتریان اجازه دسترسی مستقیم به داده‌های شما را می‌دهد و قوانین امنیتی Firebase تنها محافظی است که دسترسی کاربران مخرب را مسدود می‌کند. تعریف قوانین جدا از منطق محصول چندین مزیت دارد: کلاینت ها مسئول اجرای امنیت نیستند، پیاده سازی های باگ داده های شما را به خطر نمی اندازند، و مهمتر از همه، شما برای محافظت از داده ها در برابر جهان به یک سرور واسطه متکی نیستید.

همه کاربران تایید شده

اگرچه توصیه نمی‌کنیم که داده‌های خود را برای هر کاربری که به سیستم وارد شده است در دسترس قرار دهید، ممکن است هنگام توسعه برنامه خود تنظیم دسترسی برای هر کاربر تأیید شده مفید باشد.

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

پایگاه داده بیدرنگ

{
  "rules": {
    ".read": "auth.uid !== null",
    ".write": "auth.uid !== null"
  }
}

فضای ذخیره ابری

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

قوانین آماده تولید

همانطور که برای استقرار برنامه خود آماده می شوید، مطمئن شوید که داده های شما محافظت می شود و دسترسی به درستی به کاربران شما داده شده است. از احراز هویت برای تنظیم دسترسی مبتنی بر کاربر و خواندن مستقیم از پایگاه داده خود برای تنظیم دسترسی مبتنی بر داده استفاده کنید.

هنگام ساختار دهی داده های خود، قوانینی را بنویسید، زیرا نحوه تنظیم قوانین بر نحوه محدود کردن دسترسی به داده ها در مسیرهای مختلف تأثیر می گذارد.

دسترسی فقط مالک محتوا

این قوانین دسترسی را فقط به مالک تایید شده محتوا محدود می کند. داده ها فقط توسط یک کاربر قابل خواندن و نوشتن هستند و مسیر داده حاوی شناسه کاربر است.

وقتی این قانون کار می‌کند: اگر داده‌ها توسط کاربر ذخیره شوند، این قانون به خوبی کار می‌کند - اگر تنها کاربری که نیاز به دسترسی به داده‌ها دارد، همان کاربری باشد که داده‌ها را ایجاد کرده است.

وقتی این قانون کار نمی‌کند: این مجموعه قوانین زمانی کار نمی‌کند که چندین کاربر باید داده‌های مشابهی را بنویسند یا بخوانند - کاربران داده‌ها را بازنویسی می‌کنند یا نمی‌توانند به داده‌هایی که ایجاد کرده‌اند دسترسی پیدا کنند.

برای تنظیم این قانون: یک قانون ایجاد کنید که تأیید کند کاربر درخواست کننده دسترسی به خواندن یا نوشتن داده ها، کاربری است که آن داده ها را دارد.

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{documents=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

پایگاه داده بیدرنگ

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

فضای ذخیره ابری

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

دسترسی مختلط عمومی و خصوصی

این قانون به هر کسی اجازه می‌دهد یک مجموعه داده را بخواند، اما توانایی ایجاد یا تغییر داده‌ها در یک مسیر معین را فقط به مالک محتوای تأیید شده محدود می‌کند.

وقتی این قانون کار می‌کند: این قانون برای برنامه‌هایی که به عناصر قابل خواندن برای عموم نیاز دارند، اما نیاز به محدود کردن دسترسی ویرایش به مالکان آن عناصر دارند، به خوبی کار می‌کند. به عنوان مثال، یک برنامه یا وبلاگ چت.

هنگامی که این قانون کار نمی کند: مانند قانون فقط مالک محتوا، این مجموعه قوانین زمانی کار نمی کند که چندین کاربر نیاز به ویرایش داده های مشابه داشته باشند. کاربران در نهایت داده های یکدیگر را بازنویسی می کنند.

برای تنظیم این قانون: قانونی ایجاد کنید که دسترسی خواندن را برای همه کاربران (یا همه کاربران احراز هویت شده) فعال می‌کند و تأیید می‌کند که داده‌های نوشتن کاربر مالک است.

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow create: if request.auth.uid == request.resource.data.author_uid;
      allow update, delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}

پایگاه داده بیدرنگ

{
// Allow anyone to read data, but only authenticated content owners can
// make changes to their data

  "rules": {
    "some_path": {
      "$uid": {
        ".read": true,
        // or ".read": "auth.uid !== null" for only authenticated users
        ".write": "auth.uid === $uid"
      }
    }
  }
}

فضای ذخیره ابری

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

دسترسی مبتنی بر ویژگی و نقش محور

برای اینکه این قوانین کار کنند، باید در داده های خود ویژگی هایی را برای کاربران تعریف کرده و به آنها اختصاص دهید. قوانین امنیتی Firebase درخواست را در برابر داده های پایگاه داده یا فراداده فایل شما بررسی می کند تا دسترسی را تأیید یا رد کند.

وقتی این قانون کار می‌کند: اگر نقشی را به کاربران اختصاص می‌دهید، این قانون محدودیت دسترسی بر اساس نقش‌ها یا گروه‌های خاصی از کاربران را آسان می‌کند. به عنوان مثال، اگر نمرات را ذخیره می‌کردید، می‌توانید سطوح دسترسی متفاوتی را به گروه «دانش‌آموزان» (فقط برای خواندن محتوای آن‌ها)، گروه «معلمان» (خواندن و نوشتن در موضوع خود)، و گروه «مدیران» (بخوانید) اختصاص دهید. تمام مطالب).

وقتی این قانون کار نمی‌کند: در پایگاه داده بیدرنگ و ذخیره‌سازی ابری، قوانین شما نمی‌توانند از متد get() استفاده کنند که قوانین Cloud Firestore می‌توانند در آن گنجانده شوند. در نتیجه، شما باید پایگاه داده یا فراداده فایل خود را ساختار دهید تا ویژگی هایی را که در قوانین خود استفاده می کنید منعکس کند.

برای تنظیم این قانون: در Cloud Firestore، فیلدی را در اسناد کاربران خود بگنجانید که بتوانید آن را بخوانید، سپس قانون خود را طوری ساختار دهید که آن فیلد را بخواند و به صورت مشروط به آن دسترسی بدهید. در پایگاه داده بیدرنگ، یک مسیر داده ایجاد کنید که کاربران برنامه شما را تعریف می کند و به آنها نقشی در یک گره فرزند می دهد.

همچنین می‌توانید ادعاهای سفارشی را در Authentication تنظیم کنید و سپس آن اطلاعات را از متغیر auth.token در قوانین امنیتی Firebase بازیابی کنید.

ویژگی ها و نقش های تعریف شده از داده ها

این قوانین فقط در Cloud Firestore و پایگاه داده Realtime کار می کنند.

Cloud Firestore

به یاد داشته باشید که هر زمانی که قوانین شما شامل خواندن باشد، مانند قوانین زیر، برای عملیات خواندن در Cloud Firestore صورتحساب دریافت می کنید.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, Check a boolean `admin` attribute
    allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
   }
  }
}

پایگاه داده بیدرنگ

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
        ".read": true
      }
    }
  }
}

ویژگی‌ها و نقش‌های ادعای سفارشی

برای اجرای این قوانین، ادعاهای سفارشی را در Firebase Authentication تنظیم کنید و سپس از ادعاهای موجود در قوانین خود استفاده کنید.

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

پایگاه داده بیدرنگ

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to leverage
        ".write": "auth.uid !== null && auth.token.writer === true",
        ".read": "auth.uid !== null && auth.token.reader === true"
      }
    }
  }
}

فضای ذخیره ابری

service firebase.storage {
  // 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;
  }
}

ویژگی های اجاره نشینی

برای اجرای این قوانین، چند مستاجری را در Google Cloud Identity Platform (GCIP) راه‌اندازی کنید و سپس از مستاجر در قوانین خود استفاده کنید. مثال‌های زیر امکان نوشتن از یک کاربر را در یک مستاجر خاص به‌عنوان مثال tenant2-m6tyz

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // For tenant-based access control, check for a tenantID
    allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
    allow read: true;
  }
}

پایگاه داده بیدرنگ

{
  "rules": {
    "some_path": {
      "$uid": {
        // Only allow reads and writes if user belongs to a specific tenant
        ".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
        ".read": "auth.uid !== null
      }
    }
  }
}

فضای ذخیره ابری

service firebase.storage {
  // Only allow reads and writes if user belongs to a specific tenant
  match /files/{tenantId}/{fileName} {
    allow read: if request.auth != null;
    allow write: if request.auth.token.firebase.tenant == tenantId;
  }
}