Firebase的「規則不是過濾器」約束的解決方法

我想要一個安全規則，允許任何人獲取用戶列表並讀取其名稱，但只允許登錄的用戶查看自己的電子郵件。Firebase的「規則不是過濾器」約束的解決方法

下面是一個例子的數據結構：

"User" : { 
     "abc123" : { 
      "name" : "Bob", 
      "email" : "[email protected]" 
     } 
    }

一個天真的方式，以安全規則可能是做到以下幾點：

"User" : { 
    "$user" : { 
     "name" : { 
      ".read" : true 
     }, 
     "email" : { 
      ".read」 : "auth.uid === $user" 
     } 
    } 
}

但是因爲在用戶層面沒有讀取的規則，請求閱讀清單將被拒絕。但在用戶級別添加讀取規則將覆蓋電子郵件規則，並使每個子節點都可讀（請參閱Firebase安全指南中的Rules Cascade）。

安全指南確實指出，Rules Are Not Filters，但沒有提供關於如何處理它的很多指導。

我應該把我的User實體分成PrivateUser和PublicUser嗎？

來源

2016-01-21 Zac

這確實是這樣做的一個常見方式。一般來說，在NoSQL中建模數據時，需要對數據進行建模，以確定如何在應用程序中使用它。看到這篇文章更好的建議：https：//highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/ –

謝謝弗蘭克，我沒有任何有關NoSQL數據庫的經驗。我天真的做法是，「好吧，我需要一個用戶對象，並且用戶擁有這些屬性，其中一些屬性是私有的」。那麼你是說，一個更好的思維過程將首先考慮訪問，然後對完全公開或完全私有的對象進行建模？ – Zac

對於來自SQL背景的人來說，嘗試將其關係模型建模爲分層系統（如Firebase）非常普遍。它只是不起作用。閱讀文章，你會更好地裝備應付。還建議您閱讀Firebase網站：https：//www.firebase.com/blog/2013-04-12-denormalizing-is-normal.html，https://www.firebase.com/docs/web/guide /structuring-data.html。這看起來也不錯：https：//www.airpair.com/firebase/posts/structuring-your-firebase-data，以及我們Google羣組的最近一篇文章：https：//groups.google.com/forum/#!topic /火力通話/ 1p4O4Pc2w6k –

讓任何人獲得用戶列表並閱讀他們的名字。並允許登錄用戶查看他們自己的電子郵件。

Zac說：先想一下訪問，然後到要麼是完全公開的或完全私人的對象進行建模。

類型1：

{"rules":{ 
    "user_publicly":{"$user:{ 
    ".read":true, 
    "name":{} 
    }}, 
    "user_privately":{"$user:{ 
    ".read":"auth != null && $user == auth.uid", 
    "email":{} 
    }} 
}}

類型2：

{"rules":{ 
    "user":{"$user:{ 
    "public":{ 
     ".read":true, 
     "name":{} 
    }, 
    "private":{ 
     ".read":"auth != null && $user == auth.uid", 
     "email":{} 
    } 
    }} 
}}

來源

2016-07-16 18:29:36 Nik