Catch up on everthing we announced at this year's Firebase Summit. Learn more

Cấu trúc Quy tắc bảo mật Cloud Firestore

Quy tắc bảo mật Cloud Firestore cho phép bạn kiểm soát quyền truy cập vào tài liệu và bộ sưu tập 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 các quy tắc phù hợp với bất kỳ thứ gì, từ tất cả các lần ghi vào toàn bộ cơ sở dữ liệu đến các hoạt động 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 các quy tắc bảo mật. Kết hợp cú pháp này với điều kiện quy tắc bảo mật để tạo rulesets hoàn tất.

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

Quy tắc bảo mật Cloud Firestore luôn bắt đầu bằng khai báo sau:

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

Các service cloud.firestore khai phạm vi các quy tắc với Cloud FireStore, ngăn ngừa xung đột giữa Security Rules Mây FireStore và các quy tắc cho các sản phẩm khác như Cloud Storage.

Các match /databases/{database}/documents quy định cụ thể tuyên bố rằng những quy tắc phải phù hợp với bất kỳ cơ sở dữ liệu đám mây FireStore trong dự án. Hiện nay mỗi dự án chỉ có một cơ sở dữ liệu duy nhất có tên (default) .

Các quy tắc đọc / ghi cơ bản

Nguyên tắc cơ bản bao gồm một match tuyên bố cách xác định một đường dẫn tài liệu và allow biểu hiện chi tiết khi đọc dữ liệu quy định được phép:

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ác câu lệnh khớp phải trỏ đến tài liệu, không phải bộ sưu tập. Một tuyên bố trận đấu 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 bất kỳ tài liệu trong đường dẫn nhất định, như trong match /cities/{city} .

Trong ví dụ trên, báo cáo kết quả trận đấu sử dụng {city} cú pháp wildcard. Đây có nghĩa là các quy tắc áp dụng cho tài liệu nào ở các cities thu thập, chẳng hạn như /cities/SF hoặc /cities/NYC . Khi allow biểu thức trong báo cáo kết quả trận đấu được đánh giá, các city biến sẽ giải quyết để tên tài liệu thành phố như SF hay NYC .

Hoạt động chi tiết

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

Một read quy tắc có thể được chia thành getlist , trong khi một write quy tắc có thể được chia thành create , update , và delete :

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 bộ sưu tập tài liệu và mỗi tài liệu có thể mở rộng hệ thống phân cấp thông qua các bộ sưu tập con. Điều quan trọng là phải 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 các tình huống mà mỗi tài liệu trong cities bộ sưu tập có chứa một landmarks subcollection. Quy tắc an ninh chỉ áp dụng tại đường dẫn phù hợp, do đó kiểm soát truy cập xác định trên cities thu không áp dụng cho các landmarks subcollection. 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àm tổ match tuyên bố, con đường của khu vực nội match tuyên bố luôn là liên quan đến con đường bên ngoài match tuyên bố. Do đó, các bộ quy tắc sau là 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>;
    }
  }
}

Các ký tự đại diện đệ quy

Nếu bạn muốn quy tắc để áp dụng đối với một hệ thống phân cấp tùy tiện sâu, sử dụng cú pháp đệ quy wildcard, {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 ký tự đại diện sẽ chứa toàn bộ đoạn đường dẫn phù hợp, ngay cả khi tài liệu nằm trong một bộ sưu tập con lồng nhau sâu. Ví dụ, các quy tắc nêu trên sẽ phù hợp với một tài liệu đặt tại /cities/SF/landmarks/coit_tower , và giá trị của các document biến sẽ SF/landmarks/coit_tower .

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

Phiên bản 1

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

Các 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, các ký tự đại diện đệ quy khớp với không hoặc nhiều mục đường dẫn. match/cities/{city}/{document=**} phù hợp với các văn bản trong bất kỳ bộ sưu tập con cũng như các tài liệu trong cities sưu tập.

Bạn phải chọn tham gia vào phiên bản 2 bằng cách thêm rules_version = '2'; ở đầu các quy tắc bảo mật của bạn:

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ó nhiều nhất 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ỳ đâu 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 bạn sử dụng các truy vấn nhóm bộ sưu tập , bạn phải sử dụng phiên bản 2, thấy bảo truy vấn nhóm bộ sưu tập .

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

Có thể cho một tài liệu để phù hợp với nhiều hơn một match tuyên bố. Trong trường hợp nhiều allow biểu thức phù hợp với yêu cầu, việc tiếp cận được cho phép nếu một trong các điều kiện 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 và viết cho cities thu thập sẽ được phép vì sự cai trị thứ hai luôn luôn là true , mặc dù các quy tắc đầu tiên là luôn luôn 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ượng tối đa exists() , get() , và getAfter() gọi theo yêu cầu
  • 10 cho các yêu cầu một tài liệu và các yêu cầu truy vấn.
  • 20 cho nhiều lần đọc, giao dịch và ghi hàng loạt. Giới hạn trước đó là 10 cũng được áp dụng cho mỗi hoạt động.

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

Vượt quá một trong hai giới hạn dẫn đến lỗi bị từ chối cấp phép.

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

Lồng nhau tối đa match chiều sâu tuyên bố 10
Chiều dài đường truyền tối đa, trong các đoạn đường, cho phép trong một bộ lồng nhau match báo cáo 100
Số lượng tối đa các biến chụp đường cho phép trong một bộ lồng nhau match báo cáo 20
Độ sâu cuộc gọi chức năng tối đa 20
Số đối số hàm tối đa 7
Số lượng tối đa let bindings biến mỗi chức năng 10
Số lượng lệnh gọi hàm đệ quy hoặc tuần hoàn tối đa 0 (không được phép)
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 Bộ quy tắc phải tuân theo hai giới hạn kích thước:
  • một giới hạn 256 KB vào kích thước của các nguồn văn bản ruleset xuất bản từ các căn cứ hỏa lực console hoặc từ CLI bằng firebase deploy .
  • giới hạn 250 KB về kích thước của bộ quy tắc đã biên dịch là kết quả khi Firebase xử lý nguồn và làm cho nó hoạt động trên back-end.

Bước tiếp theo