2016-07-24 47 views
0

也许有人可以帮助我更好地理解通过确认/驳斥以下情形解析的ACL机制:在解析安全

  • 用户A创建读/写权限的用户A和B.
  • 对象和补助金
  • 用户B可以获取对象,从ACL中删除A并保存。
  • 因此,A - 对象的创建者 - 不再可以改变,甚至找不到对象。

如果这是正确的,我认为这是一个安全问题。有没有办法阻止客户端对对象的ACL进行更改,以便我可以在Cloud Code中完全管理ACL?

编辑:正如恭喜恭喜指出,处理这个问题的方法之一是禁止任何直接客户端访问,而仅使用云代码(与主密钥压倒一切)来访问数据。我不认为这是一个可行的解决方案,因为这种方法放弃了Parse的大部分好处。 ACL是控制访问权限的重要手段,但是 - 至少在某些使用情况下 - 给予客户覆盖这些设置的权力似乎很危险。

因此,对于我来说,问题依然存在:如果Parse的ACL在理论上允许任何具有写访问权限的用户来操作所有其他用户的访问权限,是否没有人将此视为安全问题?

+0

是的,你可以完全使用云代码,这就是为什么我们有主密钥: - )...使用它时,它将覆盖任何权限... –

+0

感谢您的提示!我相应地更新了这篇文章。 –

+0

还有所有类的安全功能,您可以从右侧的仪表板查看它...您可以设置分析中的角色....您可以随时检查对象的作者是否在ACL中一些afterSave触发器...我没有看到任何安全威胁,只有机会和伟大的框架 –

回答

0

对于其他类似情况:我没有找到解决此问题的方法(至少对我来说这是一个问题,而不是“机会”),所以我最终只使用ACL来控制读取访问权限写访问是私有的),并且运行我自己的服务器端权限系统,其具有用于各种写入访问的Cloud Code功能的批次