كيف تعمل قواعد الأمان

سحابة فايرستور

تركيب اساسي

تستخدم قواعد أمان Firebase في Cloud Firestore وCloud Storage البنية والتركيب التاليين:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

من المهم فهم المفاهيم الأساسية التالية أثناء إنشاء القواعد:

• الطلب: الطريقة أو الأساليب التي تم استدعاؤها في بيان allow . هذه هي الأساليب التي تسمح بتشغيلها. الطرق القياسية هي: get list create update delete . تتيح أساليب read write الملائمة وصولاً واسع النطاق للقراءة والكتابة على قاعدة البيانات المحددة أو مسار التخزين.
• المسار: قاعدة البيانات أو موقع التخزين، الذي يتم تمثيله كمسار URI.
• القاعدة: عبارة allow ، التي تتضمن شرطًا يسمح بالطلب إذا تم تقييمه على أنه صحيح.

قواعد الأمان الإصدار 2

اعتبارًا من مايو 2019، أصبح الإصدار 2 من قواعد أمان Firebase متاحًا الآن. يغير الإصدار 2 من القواعد سلوك أحرف البدل العودية {name=**} . يجب عليك استخدام الإصدار 2 إذا كنت تخطط لاستخدام استعلامات مجموعة المجموعة . يجب عليك الاشتراك في الإصدار 2 عن طريق جعل rules_version = '2'; السطر الأول في قواعد الأمان الخاصة بك:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

مسارات متطابقة

يجب أن تشير جميع بيانات المطابقة إلى المستندات، وليس إلى المجموعات. يمكن أن تشير عبارة المطابقة إلى مستند محدد، كما في match /cities/SF أو تستخدم أحرف البدل للإشارة إلى أي مستند في المسار المحدد، كما في match /cities/{city} .

في المثال أعلاه، تستخدم عبارة المطابقة صيغة حرف البدل {city} . وهذا يعني أن القاعدة تنطبق على أي مستند في مجموعة cities ، مثل /cities/SF أو /cities/NYC . عندما يتم تقييم تعبيرات allow في عبارة المطابقة، سيتم تحويل متغير city إلى اسم مستند المدينة، مثل SF أو NYC .

مطابقة المجموعات الفرعية

يتم تنظيم البيانات الموجودة في Cloud Firestore في مجموعات من المستندات، وقد يقوم كل مستند بتوسيع التسلسل الهرمي من خلال المجموعات الفرعية. من المهم فهم كيفية تفاعل قواعد الأمان مع البيانات الهرمية.

ضع في اعتبارك الموقف الذي تحتوي فيه كل وثيقة في مجموعة cities على مجموعة فرعية من landmarks . تنطبق قواعد الأمان فقط على المسار المطابق، وبالتالي فإن عناصر التحكم في الوصول المحددة في مجموعة cities لا تنطبق على مجموعة landmarks الفرعية. بدلاً من ذلك، اكتب قواعد واضحة للتحكم في الوصول إلى المجموعات الفرعية:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

      // Explicitly define rules for the 'landmarks' subcollection
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

عند تداخل عبارات match ، يكون مسار عبارة match الداخلية دائمًا مرتبطًا بمسار عبارة match الخارجية. وبالتالي فإن مجموعات القواعد التالية متكافئة:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

أحرف البدل العودية

إذا كنت تريد تطبيق القواعد على تسلسل هرمي عميق بشكل تعسفي، فاستخدم صيغة حرف البدل العودية، {name=**} :

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

عند استخدام صيغة حرف البدل العودية، سيحتوي متغير حرف البدل على مقطع المسار المطابق بالكامل، حتى لو كان المستند موجودًا في مجموعة فرعية متداخلة بعمق. على سبيل المثال، ستتطابق القواعد المذكورة أعلاه مع مستند موجود في /cities/SF/landmarks/coit_tower ، وستكون قيمة متغير document هي SF/landmarks/coit_tower .

ومع ذلك، لاحظ أن سلوك أحرف البدل العودية يعتمد على إصدار القواعد.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

إذا كنت تستخدم استعلامات مجموعة المجموعة ، فيجب عليك استخدام الإصدار 2، راجع تأمين استعلامات مجموعة المجموعة .

تداخل بيانات المباراة

من الممكن أن يتطابق المستند مع أكثر من بيان match واحد. في حالة تطابق تعبيرات allow المتعددة مع الطلب، يُسمح بالوصول إذا true أي من الشروط:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

في المثال أعلاه، سيتم السماح بجميع عمليات القراءة والكتابة لمجموعة cities لأن القاعدة الثانية true دائمًا، على الرغم من أن القاعدة الأولى false دائمًا.

حدود قواعد الأمان

أثناء التعامل مع قواعد الأمان، لاحظ الحدود التالية:

سحابة التخزين

تركيب اساسي

تستخدم قواعد أمان Firebase في Cloud Firestore وCloud Storage البنية والتركيب التاليين:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

من المهم فهم المفاهيم الأساسية التالية أثناء إنشاء القواعد:

• الطلب: الطريقة أو الأساليب التي تم استدعاؤها في بيان allow . هذه هي الأساليب التي تسمح بتشغيلها. الطرق القياسية هي: get list create update delete . تتيح أساليب read write الملائمة وصولاً واسع النطاق للقراءة والكتابة على قاعدة البيانات المحددة أو مسار التخزين.
• المسار: قاعدة البيانات أو موقع التخزين، الذي يتم تمثيله كمسار URI.
• القاعدة: عبارة allow ، التي تتضمن شرطًا يسمح بالطلب إذا تم تقييمه على أنه صحيح.

مسارات متطابقة

match قواعد أمان التخزين السحابي مع مسارات الملفات المستخدمة للوصول إلى الملفات الموجودة في التخزين السحابي. يمكن match القواعد مع المسارات الدقيقة أو مسارات أحرف البدل، ويمكن أيضًا أن تكون القواعد متداخلة. إذا لم تسمح أي قاعدة مطابقة بطريقة طلب، أو إذا تم تقييم الحالة إلى false ، فسيتم رفض الطلب.

التطابقات الدقيقة

// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
  allow write: if <condition>;
}

// Exact match for "images/croppedProfilePhoto.png"
match /images/croppedProfilePhoto.png {
  allow write: if <other_condition>;
}

مباريات متداخلة

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/profilePhoto.png"
  match /profilePhoto.png {
    allow write: if <condition>;
  }

  // Exact match for "images/croppedProfilePhoto.png"
  match /croppedProfilePhoto.png {
    allow write: if <other_condition>;
  }
}

مباريات البدل

يمكن أيضًا استخدام القواعد match النمط باستخدام أحرف البدل. حرف البدل هو متغير مسمى يمثل إما سلسلة واحدة مثل profilePhoto.png ، أو أجزاء مسار متعددة، مثل images/profilePhoto.png .

يتم إنشاء حرف البدل عن طريق إضافة أقواس متعرجة حول اسم حرف البدل، مثل {string} . يمكن الإعلان عن حرف بدل متعدد المقاطع عن طريق إضافة =** إلى اسم حرف البدل، مثل {path=**} :

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/*"
  // e.g. images/profilePhoto.png is matched
  match /{imageId} {
    // This rule only matches a single path segment (*)
    // imageId is a string that contains the specific segment matched
    allow read: if <condition>;
  }

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

إذا تطابقت قواعد متعددة مع ملف ما، فإن النتيجة هي OR نتيجة جميع تقييمات القواعد. أي أنه إذا تم تقييم أي قاعدة يطابقها الملف إلى true ، فإن النتيجة تكون true .

في القواعد المذكورة أعلاه، يمكن قراءة الملف "images/profilePhoto.png" إذا تم تقييم أي من condition أو other_condition على أنها صحيحة، في حين أن الملف "images/users/user:12345/profilePhoto.png" يخضع فقط لنتيجة other_condition .

يمكن الإشارة إلى متغير بدل من داخل match التي توفر اسم الملف أو ترخيص المسار:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

لا تتتالي قواعد أمان التخزين السحابي، ويتم تقييم القواعد فقط عندما يتطابق مسار الطلب مع مسار بقواعد محددة.

طلب التقييم

يتم تقييم عمليات التحميل والتنزيلات وتغييرات البيانات التعريفية والحذف باستخدام request المرسل إلى Cloud Storage. يحتوي متغير request على مسار الملف حيث يتم تنفيذ الطلب، والوقت الذي يتم فيه استلام الطلب، وقيمة resource الجديدة إذا كان الطلب كتابة. يتم أيضًا تضمين رؤوس HTTP وحالة المصادقة.

يحتوي كائن request أيضًا على المعرف الفريد للمستخدم وحمولة مصادقة Firebase في كائن request.auth ، والذي سيتم شرحه بشكل أكبر في قسم المصادقة في المستندات.

تتوفر قائمة كاملة بالخصائص الموجودة في كائن request أدناه:

تقييم الموارد

عند تقييم القواعد، قد ترغب أيضًا في تقييم البيانات التعريفية للملف الذي يتم تحميله أو تنزيله أو تعديله أو حذفه. يتيح لك ذلك إنشاء قواعد معقدة وقوية تقوم بأشياء مثل السماح فقط بتحميل الملفات التي تحتوي على أنواع معينة من المحتوى، أو حذف الملفات التي يزيد حجمها عن حجم معين فقط.

توفر قواعد أمان Firebase للتخزين السحابي بيانات تعريف الملف في كائن resource ، والذي يحتوي على أزواج المفاتيح/القيمة للبيانات التعريفية التي تظهر في كائن التخزين السحابي. يمكن فحص هذه الخصائص عند طلبات read أو write لضمان سلامة البيانات.

في طلبات write (مثل التحميلات وتحديثات بيانات التعريف والحذف)، بالإضافة إلى كائن resource ، الذي يحتوي على بيانات تعريف الملف للملف الموجود حاليًا في مسار الطلب، لديك أيضًا القدرة على استخدام كائن request.resource ، الذي يحتوي على مجموعة فرعية من البيانات التعريفية للملف المراد كتابتها إذا سمح بالكتابة. يمكنك استخدام هاتين القيمتين لضمان تكامل البيانات أو فرض قيود التطبيق مثل نوع الملف أو حجمه.

تتوفر قائمة كاملة بالخصائص الموجودة في كائن resource أدناه:

يحتوي request.resource على كل هذه العناصر باستثناء generation metageneration و etag و timeCreated updated .

حدود قواعد الأمان

أثناء التعامل مع قواعد الأمان، لاحظ الحدود التالية:

مثال كامل

بتجميع كل ذلك معًا، يمكنك إنشاء مثال كامل لقواعد حل تخزين الصور:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Cascade read to any image type at any path
     match /{allImages=**} {
       allow read;
     }

     // Allow write files to the path "images/*", subject to the constraints:
     // 1) File is less than 5MB
     // 2) Content type is an image
     // 3) Uploaded content type matches existing content type
     // 4) File name (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       allow write: if request.resource.size < 5 * 1024 * 1024
                    && request.resource.contentType.matches('image/.*')
                    && request.resource.contentType == resource.contentType
                    && imageId.size() < 32
     }
   }
 }
}

قاعدة بيانات الوقت الحقيقي

تركيب اساسي

في قاعدة بيانات Realtime، تتكون قواعد أمان Firebase من تعبيرات تشبه JavaScript موجودة في مستند JSON.

يستخدمون بناء الجملة التالي:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

هناك ثلاثة عناصر أساسية في القاعدة:

• المسار: موقع قاعدة البيانات. وهذا يعكس بنية JSON الخاصة بقاعدة بياناتك.
• الطلب: هذه هي الطرق التي تستخدمها القاعدة لمنح حق الوصول. تمنح قواعد read write وصولاً واسع النطاق للقراءة والكتابة، بينما تعمل قواعد validate كتحقق ثانوي لمنح الوصول استنادًا إلى البيانات الواردة أو الموجودة.
• الشرط: الشرط الذي يسمح بالطلب إذا تم تقييمه على أنه صحيح.

كيفية تطبيق القواعد على المسارات

في Realtime Database، يتم تطبيق القواعد بشكل ذري، مما يعني أن القواعد الموجودة في العقد الأصلية ذات المستوى الأعلى تتجاوز القواعد الموجودة في العقد الفرعية الأكثر دقة والقواعد الموجودة في العقدة الأعمق لا يمكنها منح الوصول إلى المسار الأصلي. لا يمكنك تحسين أو إلغاء الوصول إلى مسار أعمق في بنية قاعدة البيانات الخاصة بك إذا كنت قد منحته بالفعل لأحد المسارات الأصلية.

خذ بعين الاعتبار القواعد التالية:

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          // ignored, since read was allowed already
          ".read": false
        }
     }
  }
}

تسمح بنية الأمان هذه بقراءة /bar/ عندما يحتوي /foo/ على baz فرعي بقيمة true . ".read": false ضمن /foo/bar/ ليس لها أي تأثير هنا، حيث لا يمكن إلغاء الوصول بواسطة مسار فرعي.

على الرغم من أن الأمر قد لا يبدو بديهيًا على الفور، إلا أنه يعد جزءًا قويًا من لغة القواعد ويسمح بتنفيذ امتيازات الوصول المعقدة للغاية بأقل جهد. وهذا مفيد بشكل خاص للأمان المستند إلى المستخدم .

ومع ذلك، لا تتالي قواعد .validate . يجب استيفاء جميع قواعد التحقق من الصحة على جميع مستويات التسلسل الهرمي حتى يُسمح بالكتابة.

بالإضافة إلى ذلك، نظرًا لأن القواعد لا تنطبق مرة أخرى على المسار الأصلي، فستفشل عملية القراءة أو الكتابة إذا لم تكن هناك قاعدة في الموقع المطلوب أو في موقع أصل يمنح الوصول. حتى إذا كان من الممكن الوصول إلى كل مسار فرعي متأثر، فستفشل القراءة في الموقع الأصلي تمامًا. النظر في هذا الهيكل:

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

بدون فهم أن القواعد يتم تقييمها ذريًا، قد يبدو أن جلب المسار /records/ سيؤدي إلى إرجاع rec1 ولكن ليس rec2 . لكن النتيجة الفعلية هي خطأ:

var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
  // success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
  // cancel block triggered with PERMISSION_DENIED
}];

var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // success block is not called
}, withCancelBlock: { error in
    // cancel block triggered with PERMISSION_DENIED
})

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // success method is not called
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback triggered with PERMISSION_DENIED
  });
});

curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

نظرًا لأن عملية القراءة في /records/ ذرية، ولا توجد قاعدة قراءة تمنح الوصول إلى جميع البيانات الموجودة ضمن /records/ ، فسيؤدي ذلك إلى ظهور خطأ PERMISSION_DENIED . إذا قمنا بتقييم هذه القاعدة في محاكي الأمان في وحدة تحكم Firebase الخاصة بنا، فيمكننا أن نرى أنه تم رفض عملية القراءة:

Attempt to read /records with auth=Success(null)
    /
    /records

No .read rule allowed the operation.
Read was denied.

تم رفض العملية لأنه لا توجد قاعدة قراءة تسمح بالوصول إلى المسار /records/ ، لكن لاحظ أنه لم يتم تقييم قاعدةريك rec1 لأنها لم تكن في المسار الذي طلبناه. لجلبريك rec1 ، سنحتاج إلى الوصول إليه مباشرة:

var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];

var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // SUCCESS!
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback is not called
  }
});

curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

متغير الموقع

تدعم قواعد قاعدة بيانات الوقت الفعلي متغير $location لمطابقة مقاطع المسار. استخدم البادئة $ أمام مقطع المسار الخاص بك لمطابقة القاعدة الخاصة بك مع أي عقد فرعية على طول المسار.

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

يمكنك أيضًا استخدام $variable بالتوازي مع أسماء المسارات الثابتة.

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }