Firebase RealTime Database 的 Rules ( 安全規則 ) 可以讓資料庫具有多一層的安全保護，規則除了可以指定哪些資料可以讀取或寫入，也可以搭配 auth 根據使用者進行規範，這篇教學將會介紹如何設定 RealTime Database Rules 安全規則。
RealTime Database Rules 使用類似 JSON 格式的寫法，透過 .read、.write 和 .validate 定義是否可以存取和寫入。
| 類型 | 說明 |
|---|---|
| .read | 是否允許讀取資料，布林值判斷為 ture 可以讀取，false 不可讀取。 |
| .write | 是否允許寫入資料，布林值判斷為 ture 可以寫入，false 不可寫入。 |
| .validate | 判斷值、屬性、子屬性...等的正確格式。 |
如果是剛建立的專案，會使用「禁止讀取寫入」的設定，最外層是 rules 屬性，表示整份資料庫的規則，內容就會包含讀寫或資料夾相關的規則，因為 .read 和 .write 都是 false，所以不論任何人都無法存取或寫入。
如果將 .read 和 .write 設為 true，表示任何人都可以寫入或讀取資料。
此外，如果使用下面的寫法，會讓「有註冊」的用戶 ( 具備 uid ) 才能夠讀取、寫入或刪除資料。
{
"rules": {
".read": "auth.uid != null",
".write": "auth.uid != null"
}
}
Firebase 的規則採用「淺層判斷至深層」的做法，只要是存取資料，規則的 true 與 false 一律由淺層 ( root 根節點 ) 開始判斷，舉例來說，使用規則模擬工具執行下列規則，a 節點的層級雖然寫了 false 阻擋寫入，但 root 節點卻允許寫入，就造成 a 節點仍然可以寫入資料的情形 ( 淺層的規則會覆蓋深層的規則 )。
{
"rules": {
".read": true,
".write":true,
"a": {
".read": false,
".write": false
}
}
}
如果不希望淺層的規則影響到淺層，可以「相關規則設定留空」( 不要指定 true 或 false )，如果不寫讀寫的規則，會變成預設值 false，false 不會影響深層，如此一來就會自動採用深層的設定，舉例來說，下方的規則指定了 a 節點不可讀取和寫入，b 節點則可以讀取和寫入，除了 b 節點之外，其他節點一率無法存取。
簡單來說，起始為 0，遇到 false 就加 0，遇到 true 就加 1，如果最後結果大於 0 就表示可以寫入或讀取。
{
"rules": {
"a": {
".read": false,
".write": false
},
"b":{
".read": true,
".write": true
}
}
}
a 節點無法存取。
b 節點可以存取。
c 節點無法存取。
例如上面的例子，一開始如果是 true，不論哪層寫了 false，最後得到的值都一定大於 0，表示一定可以寫入或讀取，反之如果一開始是 0，遇到 true 加 1，在 a 節點就可以寫入或讀取，而其他節點因為沒有加 1 所以仍保持 0，就不能讀取或寫入了。
{
"rules": {
".read":false,
".write":false,
"a": {
".read": true,
".write": true
}
}
}
a 節點可以存取。
b 節點無法存取。
「淺層判斷至深層」的原則只適用於單純撰寫 .read 和 .write 規則，如果是規則中包含了 .validate，只會影響自己的層級，不受「淺層判斷至深層」的原則限制，例如下方的規則，在 root 節點會「驗證新資料一定要包含 a 節點」，所以如果儲存的資料包含 a 節點，就可以通過驗證，但在 a 的層級卻會被「驗證新資料一定要是數字格式」所阻擋，導致資料一定得是 a 節點下的數字資料才能儲存的狀況。
{
"rules": {
".read":true,
".write":true,
".validate": "newData.hasChildren(['a'])",
"a": {
".read": false,
".write": false,
".validate": "newData.isNumber()"
}
}
}
如果資料是數字可以存取。
如果資料是文字無法存取。
在安全規則裡，除了單純的撰寫節點名稱，還有以下幾種預設的變數，由於每個變數都有其特定用法，在「節點」的命名上，必須要避開這些名稱。
| 變數 | 說明 | .read | .write | .validate |
|---|---|---|---|---|
| now | 建立節點的時間 | - | - | O |
| root | 讀取或寫入資料之前，存在資料庫的根節點 | O | O | - |
| newData | 寫入資料之後會存在的資料，包含新的資料和原本的資料 | - | O | O |
| data | 讀取或寫入資料之前，存在資料庫的資料 | O | O | O |
| $變數 | 通用變數符號，表示在某個節點內的所有節點 | O | O | O |
| auth | 身份驗證使用的變數 | O | O | - |
now
now 表示「資料庫寫入的時間」，單位採用毫秒計算 ( 也就是從 1970 年 1 月 1 日到現在的毫秒數 )，下列的規則指定使用者寫入的資料，必須包含 time 的節點，節點內容為放置時的毫秒數，數值一定要在 now 之後。
{
"rules": {
".read":false,
".write":true,
".validate":"newData.child('time').val()<now"
}
}
root
root 表示「根節點」，通常會搭配類似 .child 的指令來輔助判斷，下列的規則如果資料庫內有 a 節點，且 a 節點內的 aa 節點的值為 ok，才能夠讀取資料，透過這個方法也可以達到保護資料庫的效果。
{
"rules": {
".read":"root.child('a').child('aa').val() == 'ok'",
".write":true
}
}
如果節點 a/aa 的值是 ok，則可以存取。
如果節點 a/aa 的值不是 ok，則不可以存取。
newData
newData 表示「新資料」，新資料的判斷只適用 .write 和 .vaildate，下方的規則，會限制新的資料一定得包含 a 和 b 節點才能寫入。
{
"rules": {
".read":true,
".write":"newData.hasChildren(['a','b'])"
}
}
如果資料中有 a 和 b 兩個節點，可以存取。
如果資料中只有 a 但沒有 b 節點，則不可以存取。
data
data 表示「已經存在的資料」，可以用在 .read、.write 和 .vaildate，下方的規則，會判斷目前資料庫中 a 節點是否存在 lock 為 true 的資料，如果有，則無法寫入，如果沒有就可以寫入。
{
"rules": {
".read":true,
"a":{
".write":"data.child('lock').val() != true"
}
}
}
如果 a 裡沒有 lock 為 true 的節點，可以存取 。
如果 a 裡有 lock 為 true 的節點，不可以存取 。
$變數
「$變數」的意思是「通用變數符號」，也就是不論該層節點如何命名，使用「$變數」就代表該層所有的節點名稱，舉例來說，下方的規則雖然是$a，但表示得並不是 a 節點，而是在 root 下一層的「所有節點」都能寫入或讀取資料。
{
"rules": {
".read": false,
".write": false,
"$a": {
".read": true,
".write": true
}
}
}
auth
auth 用於「搭配 firebase 專案的註冊帳號功能」，透過判斷註冊的帳號、uid...等相關資訊，決定是否可以讀取或寫入資料，下方的規則，會判斷帳號的 uid 是否等於節點的名稱或者 uid 是否存在，如果不等於則不會寫入，如果 uid 相等則會寫入，如果 uid 不存在則會新建一個名稱為 uid 的節點。
因為第一層是
.write，若判斷為 true 則後方不論.write規則為何都可以寫入，所以第二層使用.validate就能避免「淺層判斷至深層」( 請參考本篇文章上面的說明 )。
{
"rules": {
".write":"auth.uid != null",
"$user": {
".read": true,
".validate":"$user === auth.uid"
}
}
}
如果沒有 uid ，在第一層就會被排除。
如果某個 uid 的節點名稱不等於使用者的 uid 時，這個節點不能寫入資料。
如果資料庫中已經有 uid 的節點，當節點名稱等於使用者的 uid 時，這個節點就可以寫入資料。
透過使用者 auth 的規則，可以定義較為妥善的資料保護方法，但針對「匿名」的使用者，大致上可以定義以下的保護條件：
- 不能讀取整個資料庫，只能讀取某個節點 ( 表示知道名稱才能讀取 )。
- 不能刪除資料，只能不斷添加資料。
根據這兩個條件，定義以下的規則，在 root 層禁止讀取和寫入，在之後的每個節點都可以讀取，不過如果該節點有資料，則無法寫入。
{
"rules": {
".read": false,
".write": false,
"$data": {
".read": true,
".write": "!data.exists()",
}
}
}
假設資料庫中已經有了下方的這些資料：
test: {
a: 123
b: 456
c: 789
}
透過模擬可以發現，若要讀取整份 data 會被拒絕。
單獨讀取 a 節點的資料是被允許的。
若要寫入資料到 a 節點，因為 a 節點已經有資料，所以無法寫入。
不過如果是全新的節點，就可以寫入資料 ( 等同於使用 push 的功能 )
Firebase RealTime Database 的規則其實相當簡單，只是要熟悉其邏輯和運作方式，透過規則就能保護資料庫，也就能做出更彈性的應用了。
大家好，我是 OXXO，是個即將邁入中年的斜槓青年，我有個超過一千篇教學的 STEAM 教育學習網，有興趣可以參考下方連結呦～ ^_^
iThome鐵人賽
看影片追技術