Parse PHP SDK полностью игнорирует изменение MasterKey

Question

Итак, чтобы сохранить безопасность, мы решили сменить главный ключ нашего Parse Server.

Наш iOS продолжал работать, потому что ему требовался только идентификатор приложения, но на удивление наши скрипты PHP также работали, хотя они были инициализированы WRONG MasterKey.

1. Разделяет ли Parse PHP SDK полное изменение основного ключа?
2. Как мы можем предотвратить старые сценарии php, у которых есть ключ приложения для доступа к нашим данным и «чтению» данных?

Согласно документации:

ParseClient::initialize('YOUR_APP_ID', '', 'YOUR_MASTER_KEY'); 
ParseClient::setServerURL('http://YOUR_PARSE_SERVER:1337/parse'); 

Answer 1

Мое предложение к вам будет следующим.

Использовать 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) 

EDIT/QUOTE:

Если вы посмотрите в ParseClient::initialize мастер-ключ хранится в статическом вар $masterKey. Это используется в ParseClient::_getRequestHeaders (когда главный ключ использование требуется), чтобы обеспечить X-Parse-Master-Key с основным ключом в качестве значения.

Главный ключ определенно используется, но это зависит от запроса. Если $useMasterKey является ложным для данного запроса в ParseClient::_request (значение по умолчанию также ложно), главный ключ не будет добавлен в заголовки запроса. В таком случае главный ключ не будет использоваться, но это ожидаемое поведение.

Answer 2

1.) Да, parse php sdk не делает никакой проверки на главном ключе. Проверка выполняется на стороне сервера анализа, который вы используете. По сути, главный ключ существует, чтобы разрешить переопределение ACL, как указано в sdk docs. Он отправляется на сервер при отправке запроса, который запрашивает использование главного ключа.

В принципе, если вы делаете какие-либо запросы, которые необходимо переопределить ACL, и вы укажете использовать мастер-ключ, тогда будет отправлен главный ключ. В других случаях главный ключ не отправляется. Вы можете проверить это, написав быстрый код, который отправит мастер-ключ, например $object->save(true). В этом случае ваш главный ключ должен сбой, если он не соответствует загруженному на сервере.

2.) Вы действительно не можете помешать кому-то выяснить свой Идентификатор приложения. Безопасность, которую вы ищете, не так много на стороне клиента, как на сервере. Вы должны быть уверены, что настроили ACL объектов и классов, чтобы ограничить доступ ко всем объектам (и классам), которые вы не хотите читать (или записывать) произвольными лицами. Роли - довольно хороший способ применить это к широкому набору объектов, например ограничить доступ к роли администратора.Если вы заблокируете свои данные, это потребует, чтобы кто-то нарушил существующую учетную запись с доступом к этим данным, вместо того, чтобы просто использовать ваш идентификатор приложения.

При этом вы всегда должны опасаться того, кто может захватить ваш главный ключ, поскольку он позволит им обойти все эти ACL, которые вы настроили (держите его в безопасности!).

Надеюсь, это поможет прояснить роль главного ключа для вас, ребята.