Firebase爲用戶設置角色

我在Firebase中遇到了用戶擁有角色的情況。根據已經在另一個「模式」中定義的一些配置文件，用戶可以刪除，更新，創建，刪除和更新等等...許多組合。Firebase爲用戶設置角色

例：

Users/: 
    user_1: 
     create: "ok" 
     delete: "no" 
     update: "ok" 
    user_2: 
     create: "no" 
     ... etc ...

如何在火力管理這個曾經」 .WRITE的許可不接受動態條件？我發現博爾特有一些別名（創建（），更新（） ，刪除（））到然而，你只有創建OR更新或刪除。一旦一個定義，你不能改變。

謝謝

來源

2017-05-09 Mario

也許嘗試做每個用戶的Linux chmod樣式字段和創建權限的方式？這樣，您只有一個字段，並在權限中定義所有組合。 –

爲了準確，Bolt是一個實驗性的安全性和規則編譯器，並且處於Beta版。 – Mario

Hi @PrestonGarno。是的，這是有效的。恢復角色是可能的，但符合代表角色的條件是我沒有意識到如何去做的部分。你可以恢復說777或765等角色，但是你不能根據這個改變firebase的.write規則。 – Mario

我找到了一個解決方案...沒有理想，如果是最好的...但是，解決我的問題。無論如何，寫條件都有點痛苦。

，然後在你的火力點規則：

CUD手段Ç reate ü PDATE d elete。你也可以使用chmod數字（777，765等）。

現在，我需要了解如何編寫條件-ud，--D等 :)

來源

2017-05-09 12:21:39 Mario

這可以工作，但也可能會變得混亂。看看我的解決方案，讓我知道你的想法。我更願意採用每個「主」節點權限結構的路由，因爲它看起來更加靈活。請記住 - 不要害怕有一堆條目 - 似乎違反直覺，但數據庫設置爲分散在各地，但易於維護/組織 –

好了，所以我會假設你的數據的結構類似下面。這個答案是我自己的主觀方法，我將如何動態管理訪問數據庫不同部分的用戶。

注意 ::我使用的chmod代表READ-WRITE-DELETE，而不是READ-WRITE-EXECUTE（即6 =讀取+寫入但不是刪除，7 =完全CRUD特權）。此示例數據庫分爲三部分，並模擬社交媒體應用程序。。此外，對於「世界」（第3位的默認很可能將只有經過身份驗證的用戶這是一個很簡單的例子：

root/ 
| 
|-- user/     <-main node that contains profile info 
|  \uid    <-node name - one for each user with sub-nodes containing profile info 
|  \user    
|   |-<UID>  <-shows who has "user" privileges (1st digit) 
|  \group 
|   |-<UID>  <-shows who has "group" privileges (1st digit) 
| \permissions = 744 <-universal "user" entry rule 
| 
|-- trending/    <-node that contains global, read only info 
|  \user    <-No one will be here for "trending" 
|  \group 
|  \feed-data 
|   \<POST_UUIDS> <-Data here 
|  \permissions = 444 <-Everyone can read the global feed 
| 
|-- messaging/ 
|  \<chat-uuid-number-1>    
|   \user    
|    |-<User1> 
|    |-<User2> 
|   \group 
|   \messages node 
|  \<chat-uuid-number-2>    
|   \user    
|    |-<User8> 
|    |-<User5> 
|   \messages-node 
| 
|  \permissions = 600 <-Only 2 users can read&send messages in their node 
| 
|-- chatrooms/    <-each node contains a list of UID, and list of messages 
|  \<room-uuid-number> 
|  \user    
|   |-<Admin1> 
|   |-<Admin2...> 
|  \group 
|   |-<uid1> 
|   |-<uid2> 
|   |-<uid3...infinity> 
|  \permissions = 760 <-Only admins have user privilege, users in chat can send and receive in the chat though

所以這是一個有點denormalized數據庫結構，如JSON數據庫顯然應該在這裏閱讀：https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html每個分支除了它所關心的東西外，並不包含非常多的信息現在，如果你有統一的「繼承」類型結構，那麼你可以使用相對目錄路徑來檢查相對於目錄用戶試圖訪問並隔離驗證規則的一個位置 - 然後所有的子節點都將被覆蓋，只要它們具有統一的基本權限結構！

所以只要你的新數據永遠不會進入根目錄或其下的任何主節點/目錄（你可以編寫規則來確保這一點），你可以使用data.parent（）來獲得你的條目的父母，然後再次調用parent（）以進入主目錄（例如，聊天室），那麼你檢查每個連續的數字對用戶/組/世界列表的權限值，並匹配：

".write": "data.parent().parent().child('permissions').val().beginsWith('6') && data.parent().child('users').child($uid).exists"

這（僞）檢查的權限代碼的第一個數字，然後檢查節點的「用戶」子目錄查看當前用戶是否具有該特定子節點的用戶權限。在此之後添加一個條件OR來檢查是否存在group寫入權限並且用戶存在於組中。等等...所有從根目錄！只要確保你防止在'/'或'//'下寫入（首先使用'& &'寫入這些條件，以便在嘗試獲取根父級之前檢查失敗，等等），並且它應該可以正常工作。

這不是一個絕對的結構，但我把我的數據庫設置爲'淺'數據庫，同時限制每個條目像「消息」這樣的主目錄下有一個權限代碼並檢查用戶的UID數據庫讀/寫，它爲我節省了大量的痛苦。雖然我上次使用它的時間大約是5個月前，但我不確定事情是否現在變得更簡單或者簡單的工具/庫。希望這有助於！

來源

2017-05-09 12:39:10

非常感謝您的回答！我會仔細看看。無論如何，我只是推出了一個解決方案（到現在爲止）爲我工作。 – Mario

@Mario沒有問題，希望你找出任何方式。如果這對您有用，請不要忘記標記正確:)祝您好運。 –

@Mario有一件事我忘了說清楚：'permission'節點位於「/ messages/permissions」（直接在主節點下）*定義每個單個消息對話的規則*。然後'user'和'group'節點以*每個聊天*爲基礎存在，所以它會是/ messages//users和/ messages//group ，所以每消息聊天1個。我認爲我的根本規則是不正確的，這就是爲什麼我要澄清 –

Firebase爲用戶設置角色

回答

相關問題