قواعد الأمان ومصادقة 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 معرّف المستأجر المرتبط بالحساب، إن توفّر، مثل 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، راجِع قواعد الأمان الأساسية.