Firebase 即時資料庫安全性規則會決定誰具有讀取和寫入權限 資料庫、資料結構和存在的索引。這些規則 而且一律會自動執行。每次閱讀 且只有在規則允許時,才會完成寫入要求。根據預設 您的規則不允許任何人存取資料庫。這麼做是為了保護您的 讓您有更多時間自訂規則或設定 驗證。
即時資料庫安全性規則的語法與 JavaScript 類似,且可分為以下四種類型:
規則類型 | |
---|---|
.read | 說明使用者是否可以讀取資料,以及何時允許讀取資料。 |
.write | 說明是否允許寫入資料,以及何時可以寫入資料。 |
.validate | 定義格式正確的值會呈現的樣子 (無論是否有錯誤) 含有子屬性和資料類型 |
.indexOn | 指定要索引的子項,以便排序和查詢。 |
「Realtime Database」安全性總覽
Firebase Realtime Database 提供一整套工具,可用於管理應用程式的安全性。這些工具可讓您輕鬆驗證使用者、強制執行使用者權限,以及驗證輸入內容。
以 Firebase 為基礎的應用程式,所執行的用戶端程式碼比整合許多其他的應用程式還多 技術堆疊。因此,我們處理安全性的方式 和慣用語言不同
驗證
保護應用程式安全的第一步通常是識別使用者。這項程序稱為「驗證」。您可以使用 Firebase 驗證 這樣才能讓使用者登入您的應用程式Firebase 驗證 內建支援常見驗證方法,例如 Google 和 Facebook、電子郵件和密碼登入、匿名登入等多種功能。
使用者身分是重要的安全性概念。每位使用者都有不同的 有時候也會有不同的能力例如,在聊天中 每個訊息都會與建立該應用程式的使用者相關聯。位使用者 也可以刪除自己的訊息,但無法刪除其他人張貼的訊息 使用者。
授權
辨識使用者只是確保安全性,瞭解他們的背景後
因此,您需要採取一種方法來控管
對資料庫資料的存取權。您可以透過即時資料庫安全性規則控管個別使用者的存取權。例如,這裡是一組
允許所有人讀取 /foo/
路徑,但不允許
一是寫入該物件:
{ "rules": { "foo": { ".read": true, ".write": false } } }
.read
和 .write
規則會層層套用,因此這個規則集會授予對路徑 /foo/
和任何更深路徑 (例如 /foo/bar/baz
) 中的所有資料的讀取權限。請注意,.read
和
資料庫中的 .write
規則範圍會覆寫更深層的規則,因此
本例仍會授予「/foo/bar/baz
」的讀取權限
即使 /foo/bar/baz
路徑中的規則評估為 false 也一樣。
即時資料庫安全性規則包括
內建變數
以及功能
參照其他路徑、伺服器端時間戳記、驗證資訊
等等。以下舉例說明的規則將寫入權限授予
向「/users/<uid>/
」進行驗證的使用者,其中 <uid>為
透過 Firebase Authentication 取得的使用者 ID。
{ "rules": { "users": { "$uid": { ".write": "$uid === auth.uid" } } } }
驗證資料
Firebase Realtime Database 是無結構定義。這樣一來,
在應用程式準備發布時
以便保持一致規則語言包含 .validate
規則,讓您可以使用相同的運算式來套用驗證邏輯
適用於 .read
和 .write
規則唯一的差別是
「驗證規則不會串聯」,因此所有相關
驗證規則必須評估為 true,才能允許寫入。
這些規則會強制規定寫入 /foo/
的資料必須是長度少於 100 個字元的字串:
{ "rules": { "foo": { ".validate": "newData.isString() && newData.val().length < 100" } } }
驗證規則可以使用所有相同的內建函式和
做為 .read
和 .write
規則您可以使用這些資料建立驗證規則,讓系統瞭解資料庫中其他位置的資料、使用者身分、伺服器時間等等。
定義資料庫索引
Firebase Realtime Database 可讓您排序及查詢資料。小型資料專用 資料庫大小,資料庫支援臨時查詢,因此索引通常不會 開發期間所需的資源不過,在推出應用程式之前,請務必為所有查詢指定索引,確保這些查詢在應用程式擴充時仍能正常運作。
您可以使用 .indexOn
規則指定索引。我們來看個例子
索引宣告,會為一組
恐龍:
{ "rules": { "dinosaurs": { ".indexOn": ["height", "length"] } } }