在解析安全

也許有人可以幫助我更好地理解通過確認/駁斥以下情形解析的ACL機制：在解析安全

用戶A創建讀/寫權限的用戶A和B.
用戶B可以獲取對象，從ACL中刪除A並保存。
因此，A - 對象的創建者 - 不再可以改變，甚至找不到對象。

如果這是正確的，我認爲這是一個安全問題。有沒有辦法阻止客戶端對對象的ACL進行更改，以便我可以在Cloud Code中完全管理ACL？

編輯：正如恭喜恭喜指出，處理這個問題的方法之一是禁止任何直接客戶端訪問，而僅使用雲代碼（與主密鑰壓倒一切）來訪問數據。我不認爲這是一個可行的解決方案，因爲這種方法放棄了Parse的大部分好處。 ACL是控制訪問權限的重要手段，但是 - 至少在某些使用情況下 - 給予客戶覆蓋這些設置的權力似乎很危險。

因此，對於我來說，問題依然存在：如果Parse的ACL在理論上允許任何具有寫訪問權限的用戶來操作所有其他用戶的訪問權限，是否沒有人將此視爲安全問題？

來源

2016-07-24 dr_barto

是的，你可以完全使用雲代碼，這就是爲什麼我們有主密鑰： - ）...使用它時，它將覆蓋任何權限... –

感謝您的提示！我相應地更新了這篇文章。 –

還有所有類的安全功能，您可以從右側的儀表板查看它...您可以設置分析中的角色....您可以隨時檢查對象的作者是否在ACL中一些afterSave觸發器...我沒有看到任何安全威脅，只有機會和偉大的框架 –

對於其他類似情況：我沒有找到解決此問題的方法（至少對我來說這是一個問題，而不是「機會」），所以我最終只使用ACL來控制讀取訪問權限寫訪問是私有的），並且運行我自己的服務器端權限系統，其具有用於各種寫入訪問的Cloud Code功能的批次。

來源

2016-08-22 08:18:52

回答

相關問題