Cấu trúc các quy tắc bảo mật của Cloud Firestore

Cloud Firestore Security Rules cho phép bạn kiểm soát quyền truy cập vào tài liệu và trong cơ sở dữ liệu của mình. Cú pháp quy tắc linh hoạt cho phép bạn tạo quy tắc khớp với bất kỳ thứ gì, từ tất cả lượt ghi vào toàn bộ cơ sở dữ liệu cho đến thao tác trên một tài liệu cụ thể.

Hướng dẫn này mô tả cú pháp và cấu trúc cơ bản của quy tắc bảo mật. Kết hợp ngữ pháp này với điều kiện quy tắc bảo mật để tạo các bộ quy tắc hoàn chỉnh.

Khai báo cơ sở dữ liệu và dịch vụ

Cloud Firestore Security Rules luôn bắt đầu bằng nội dung khai báo sau:

service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}

Nội dung khai báo service cloud.firestore sẽ đặt phạm vi cho các quy tắc là Cloud Firestore, ngăn chặn xung đột giữa Cloud Firestore Security Rules và các quy tắc cho các sản phẩm khác như Bộ nhớ trên đám mây.

Khai báo match /databases/{database}/documents chỉ định rằng các quy tắc phải khớp với cơ sở dữ liệu Cloud Firestore bất kỳ trong dự án. Hiện tại, mỗi dự án chỉ có một cơ sở dữ liệu duy nhất có tên là (default).

Quy tắc đọc/ghi cơ bản

Các quy tắc cơ bản bao gồm câu lệnh match chỉ định đường dẫn đến tài liệu và biểu thức allow nêu chi tiết thời điểm đọc dữ liệu được chỉ định:

service cloud.firestore {
  match /databases/{database}/documents {

    // Match any document in the 'cities' collection
    match /cities/{city} {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

Tất cả câu lệnh so khớp phải trỏ đến tài liệu, chứ không phải bộ sưu tập. Trận đấu câu lệnh có thể trỏ đến một tài liệu cụ thể, như trong match /cities/SF hoặc sử dụng ký tự đại diện để trỏ đến tài liệu bất kỳ trong đường dẫn được chỉ định, như trong match /cities/{city}.

Trong ví dụ trên, câu lệnh so khớp sử dụng cú pháp ký tự đại diện {city}. Tức là quy tắc này áp dụng cho mọi tài liệu trong tập hợp cities, chẳng hạn như /cities/SF hoặc /cities/NYC. Khi biểu thức allow trong câu lệnh khớp là được đánh giá, biến city sẽ phân giải thành tên tài liệu của thành phố, chẳng hạn như SF hoặc NYC.

Toán tử chi tiết

Trong một số trường hợp, bạn nên chia nhỏ readwrite thành các thao tác chi tiết hơn. Ví dụ: ứng dụng của bạn có thể muốn thực thi các chế độ cài đặt khác nhau hơn là điều kiện để tạo tài liệu so với khi xoá tài liệu. Hoặc bạn có thể muốn cho phép đọc một tài liệu nhưng từ chối các truy vấn lớn.

Quy tắc read có thể được chia thành getlist, trong khi quy tắc write có thể được chia thành create, updatedelete:

service cloud.firestore {
  match /databases/{database}/documents {
    // A read rule can be divided into get and list rules
    match /cities/{city} {
      // Applies to single document read requests
      allow get: if <condition>;

      // Applies to queries and collection read requests
      allow list: if <condition>;
    }

    // A write rule can be divided into create, update, and delete rules
    match /cities/{city} {
      // Applies to writes to nonexistent documents
      allow create: if <condition>;

      // Applies to writes to existing documents
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
}

Dữ liệu phân cấp

Dữ liệu trong Cloud Firestore được sắp xếp thành các tập hợp tài liệu và mỗi tập hợp có thể mở rộng hệ phân cấp thông qua các tập hợp con. Điều quan trọng là hiểu cách các quy tắc bảo mật tương tác với dữ liệu phân cấp.

Hãy xem xét trường hợp mỗi tài liệu trong tập hợp cities chứa một tập hợp con landmarks. Quy tắc bảo mật chỉ áp dụng cho đường dẫn phù hợp, vì vậy, các biện pháp kiểm soát quyền truy cập được xác định trong tập hợp cities không áp dụng cho Bộ sưu tập con landmarks. Thay vào đó, hãy viết các quy tắc rõ ràng để kiểm soát quyền truy cập vào các bộ sưu tập con:

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

Khi lồng các câu lệnh match, đường dẫn của câu lệnh match bên trong luôn luôn so với đường dẫn của câu lệnh match bên ngoài. Bộ quy tắc sau do đó tương đương:

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

Ký tự đại diện đệ quy

Nếu bạn muốn áp dụng các quy tắc cho một hệ phân cấp sâu tuỳ ý, hãy sử dụng cú pháp ký tự đại diện đệ quy, {name=**}. Ví dụ:

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

Khi sử dụng cú pháp ký tự đại diện đệ quy, biến đại diện sẽ chứa toàn bộ phân đoạn đường dẫn khớp, ngay cả khi tài liệu nằm trong một tập hợp con lồng nhau sâu. Ví dụ: các quy tắc nêu trên sẽ khớp với một tài liệu nằm tại /cities/SF/landmarks/coit_tower và giá trị của biến document sẽ là SF/landmarks/coit_tower.

Tuy nhiên, lưu ý rằng hành vi của ký tự đại diện đệ quy phụ thuộc vào quy tắc .

Phiên bản 1

Theo mặc định, các quy tắc bảo mật sử dụng phiên bản 1. Trong phiên bản 1, ký tự đại diện đệ quy khớp với một hoặc nhiều mục đường dẫn. Chúng không khớp với đường dẫn trống, vì vậy match /cities/{city}/{document=**} khớp với các tài liệu trong tập hợp con nhưng không có trong tập hợp cities, trong khi match /cities/{document=**} khớp với cả hai tài liệu trong tập hợp cities và các tập hợp con.

Ký tự đại diện đệ quy phải ở cuối câu lệnh so khớp.

Phiên bản 2

Trong phiên bản 2 của quy tắc bảo mật, ký tự đại diện đệ quy khớp với 0 hoặc nhiều mục đường dẫn. match/cities/{city}/{document=**} so khớp các tài liệu trong bất kỳ bộ sưu tập con nào cũng như các tài liệu trong bộ sưu tập cities.

Bạn phải chọn sử dụng phiên bản 2 bằng cách thêm rules_version = '2'; vào đầu quy tắc bảo mật:

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

Bạn có thể có tối đa một ký tự đại diện đệ quy cho mỗi câu lệnh so khớp, nhưng trong phiên bản 2, bạn có thể đặt ký tự đại diện này ở bất kỳ vị trí nào trong câu lệnh so khớp. Ví dụ:

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

Nếu sử dụng truy vấn nhóm thu thập, bạn phải sử dụng phiên bản 2, hãy xem bảo mật các truy vấn nhóm thu thập.

Câu lệnh khớp trùng lặp

Một tài liệu có thể khớp với nhiều câu lệnh match. Trong trường hợp nhiều biểu thức allow khớp với một yêu cầu, quyền truy cập sẽ được cho phép nếu bất kỳ điều kiện nào là 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;
    }
  }
}

Trong ví dụ trên, tất cả các thao tác đọc và ghi vào bộ sưu tập cities sẽ được cho phép vì quy tắc thứ hai luôn là true, mặc dù quy tắc đầu tiên luôn là false.

Giới hạn quy tắc bảo mật

Khi bạn làm việc với các quy tắc bảo mật, hãy lưu ý các giới hạn sau:

Giới hạn Thông tin chi tiết
Số lệnh gọi tối đa là exists(), get()getAfter() trong mỗi yêu cầu
  • 10 đối với yêu cầu một tài liệu và yêu cầu truy vấn.
  • 20 để đọc nhiều tài liệu, giao dịch và ghi hàng loạt. Giới hạn 10 trước đó cũng áp dụng cho mỗi hoạt động.

    Ví dụ: Giả sử bạn tạo một yêu cầu ghi theo lô bằng 3 thao tác ghi và quy tắc bảo mật của bạn dùng 2 tài liệu truy cập các lệnh gọi để xác thực từng lần ghi. Trong trường hợp này, mỗi lệnh ghi sử dụng 2 trong số 10 lệnh gọi truy cập và yêu cầu ghi hàng loạt sử dụng 6 trong số 20 lệnh gọi truy cập.

Nếu vượt quá một trong hai giới hạn này, ứng dụng sẽ gặp lỗi bị từ chối cấp quyền.

Một số lệnh gọi truy cập tài liệu có thể được lưu vào bộ nhớ đệm, và các lệnh gọi được lưu vào bộ nhớ đệm sẽ không được tính vào giới hạn này.

Độ sâu câu lệnh match lồng nhau tối đa 10
Chiều dài đường dẫn tối đa, tính bằng các phân đoạn đường dẫn, được phép trong một tập hợp các câu lệnh match lồng nhau 100
Số lượng biến thu thập đường dẫn tối đa được phép trong một tập hợp câu lệnh match lồng nhau 20
Độ sâu lệnh gọi hàm tối đa 20
Số lượng đối số hàm tối đa 7
Số liên kết biến tối đa let trên mỗi hàm 10
Số lệnh gọi hàm đệ quy hoặc tuần hoàn tối đa 0 &lpar;không được phép&rpar;
Số lượng biểu thức tối đa được đánh giá cho mỗi yêu cầu 1.000
Kích thước tối đa của một bộ quy tắc Quy tắc phải tuân theo hai giới hạn kích thước:
  • giới hạn 256 KB đối với kích thước nguồn văn bản quy tắc được phát hành từ bảng điều khiển Firebase hoặc từ CLI bằng cách sử dụng firebase deploy.
  • giới hạn 250 KB cho kích thước của bộ quy tắc được biên dịch khi Firebase xử lý nguồn và đặt nguồn đó hoạt động trên phụ trợ.

Các bước tiếp theo