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

سحابة Firestore

تركيب اساسي

تستخدم قواعد أمان 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 من تعبيرات شبيهة بجافا سكريبت مضمنة في مستند 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 }
      }
    }
  }