因此,为了保证安全,我们决定更改Parse Server的主密钥。
我们的iOS继续工作,因为它只需要应用程序ID,这是预期的,但令人惊讶的是我们的PHP脚本也保持运行,即使它们是使用WRONG MasterKey初始化的。
根据文件:
ParseClient::initialize('YOUR_APP_ID', '', 'YOUR_MASTER_KEY');
ParseClient::setServerURL('http://YOUR_PARSE_SERVER:1337/parse');
答案 0 :(得分:0)
我对你的建议如下。
使用RestKey
作为PHP
作为您的第二个参数,然后IOS您可以使用clientKey
作为您的第二个参数。
确保将restKey
和clientKey
添加到构造服务器端。
我的swift3例子也是如此!
let configuration = ParseClientConfiguration {
$0.applicationId = PARSE_APP_KEY
$0.clientKey = PARSE_CLIENT_KEY
$0.server = PARSE_URL
$0.isLocalDatastoreEnabled = true
}
Parse.initialize(with: configuration)
编辑/报价:
如果您查看ParseClient::initialize
,则主密钥存储在静态var $masterKey.
中。ParseClient::_getRequestHeaders
中使用此密钥(请求使用主密钥时)以提供X-Parse-Master-Key
1}}标头,主密钥为值。
主密钥肯定是使用的,但它取决于请求。如果$useMasterKey
中的给定请求ParseClient::_request
为false(默认值为false),则不会将主密钥添加到请求标头中。在这种情况下,不会使用主密钥,但这是预期的行为。
答案 1 :(得分:0)
1。)是的,解析php sdk没有对主密钥进行任何验证。验证发生在您正在运行的Parse Server一侧。实质上,主密钥存在以允许覆盖sdk docs中提到的ACL。当发送请求使用主密钥的请求时,它将被提交给服务器。
基本上,如果您发出任何需要覆盖ACL的请求,并且您指示使用主密钥,那么将发送主密钥。在其他情况下,不会发送主密钥 。您可以通过编写一些将发送主密钥的快速代码来测试这一点,例如$object->save(true)
。在这种情况下,如果主密钥与服务器中加载的密钥不匹配,则 将失败。
2。)你真的无法防止有人弄清楚你的App Id。您正在寻找的安全性并不像客户端那样在服务器端。您应该确保设置对象和类ACL,以限制对您不希望被任意个体读取(或写入)的所有对象(和类)的访问。角色是将其应用于广泛对象的一种相当好的方式,例如限制对Admin角色的访问。如果您锁定数据,则需要有人破坏现有帐户以访问该给定数据,而不是仅使用您的应用ID。
话虽如此,你应该总是警惕可能设法获取主密钥的人,因为这样可以绕过你设置的所有ACL(保持安全!)。
我希望这有助于澄清主人的角色。