Reputation: 600
So in order to keep things secure we decided to change the master key of our Parse Server.
Our iOS kept working because it only requires the app id, that was expected but surprisingly our PHP scripts kept running as well, even though they were initialized with the WRONG MasterKey.
According to the docs:
ParseClient::initialize('YOUR_APP_ID', '', 'YOUR_MASTER_KEY');
ParseClient::setServerURL('http://YOUR_PARSE_SERVER:1337/parse');
Upvotes: 0
Views: 344
Reputation: 1430
My suggestion to you would be the following.
Use RestKey
for PHP
as your second argument and then IOS you can just use clientKey
as your second argument.
Just ensure that you add both restKey
and clientKey
to your construct server side.
my working swift3 example too!
let configuration = ParseClientConfiguration {
$0.applicationId = PARSE_APP_KEY
$0.clientKey = PARSE_CLIENT_KEY
$0.server = PARSE_URL
$0.isLocalDatastoreEnabled = true
}
Parse.initialize(with: configuration)
EDIT /QUOTE:
If you take a look in ParseClient::initialize
the master key is stored in the static var $masterKey.
This is used in ParseClient::_getRequestHeaders
(when master key use is requested) to provide the X-Parse-Master-Key
header with the master key as the value.
The master key is definitely used, but it depends on the request. If $useMasterKey
is false for a given request in ParseClient::_request
(the default value is false as well) the master key will not be added to the request headers. In such a case the master key will not be used, but this is expected behavior.
Upvotes: 0
Reputation: 86
1.) Yes, the parse php sdk doesn't do any validation on the master key. The validation occurs on the side of the Parse Server you're running. Essentially the master key exists to allow overriding of ACLs as mentioned in the sdk docs. It is submitted to the server when a request is sent that asks for use of the master key.
Basically, if you make any requests that need to override ACLs and you indicate to use the master key, then the master key will be sent. In other cases the master key is not sent. You can test this out by writing up some quick code that will send the master key, like $object->save(true)
. In this case your master key should fail if it does not match what is loaded in the server.
2.) You really can't prevent someone from figuring out your App Id. The security you're looking for is not as much on the client's end as it is on the server's. You should be making sure to setup object and class ACLs to restrict access to all objects (and classes) that you do not want to be read (or written to) by arbitrary individuals. Roles are a fairly good way of applying this to a broad set of objects, like restricting access to an Admin role. If you lock your data down it would require someone to compromise an existing account with access to that given data, rather than just use your App Id.
That being said you should always be wary of someone who might manage to grab your master key, as it would allow them to bypass all of those ACLs you setup (keep it safe!).
I hope this helps to clarify the role of the master key for you guys.
Upvotes: 0