保護與用戶的Firebase CRUD操作

由於AngularFire文檔較細，以及它與Firebase的默認Web文檔之間的差異，我對如何最好地保護與用戶的創建，讀取，更新和刪除操作有點失望。保護與用戶的Firebase CRUD操作

總之，假設我有一個管理商店的應用程序。用戶可以是商店或老主顧的所有者。業主應該在他們的視野中閱讀和編輯他們自己的商店，顧客應該閱讀所有內容，但不要在他們的視圖中編輯商店。

我擔心的火力地堡文檔如

因此，例如所建議的方法的安全性，我們可以像下面這樣的規則，以允許用戶只要他們儲存他們創造的意見與評論用戶名：

{ 
    "rules": { 
    ".read": true, 
    "$comment": { 
     ".write": "!data.exists() && newData.child('user_id').val() == auth.id" 
    } 
    } 
}

對我來說，這意味着我可以通過簡單地傳入我的受害者的用戶ID破解我的應用程序的數據時，我要發佈爲他們評論。我錯了嗎？

我已經幾次徹底閱讀安全文檔。我想我需要在這裏進一步解釋。通過客戶端暴露的參數進行識別是目前我能找到的唯一方法。

來源

2013-10-18 Adam Grant

在此處顯示的示例中，auth指的是已驗證用戶的令牌數據。這是在auth（）事件期間由Firebase設置的一個特殊變量，因此不是您可以在客戶端進行攻擊的東西。換句話說，如果您將user_id值設置爲您自己的帳戶ID，則只能撰寫評論。

對象auth的內容取決於客戶端的身份驗證方式。例如，SimpleLogin的password提供程序將以下內容放入認證令牌中：provider,email和id;其中任何一個都可以用在安全規則中。

它也可以從服務器sign your own tokens，當然天空是這裏的限制。

但底線是令牌的內部值由可信進程提供，而不是由客戶端提供，因此不能由用戶修改。

來源

2013-10-18 16:09:42 Kato

哦，這是個好消息。所以我可以將auth對象中的這些超長驗證字符串與所討論數據的屬性進行匹配。 –

但是這些令牌是否會因期滿而發生變化？我擔心，如果我將數據連接到這樣一個令牌，那麼一旦令牌更改，它們將被突然鎖定在數據之外。 –

如果Firebase的任何人傾聽，我建議整合諸如Kinvey所擁有的內容，其中每個集合都可以具有四個通用訪問模板之一，或者可以選擇退回到業務邏輯，如Firebase的規則。 –

保護與用戶的Firebase CRUD操作

回答

相關問題