безопасность parse.com

Как и в случае с любым внутренним сервером, вы должны защищаться от потенциально вредоносных клиентов. Parse имеет несколько уровней безопасности, чтобы помочь вам в этом.

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

Если такой уровень безопасности вас не устраивает, вы можете проксировать доступ к своим данным через Облачные функции. Это похоже на создание виртуального сервера приложений, чтобы обеспечить уровень контроля доступа между вашими клиентами и вашим серверным хранилищем данных.

Я использовал следующий подход в случае, когда мне просто нужно было предоставить небольшое представление пользовательских данных веб-приложению.

а. Создайте вторичный объект, который содержит подмножество полей защищенных объектов.

б. Используя ACL, сделайте защищенный объект доступным только для соответствующего входа в систему.

в. Сделать вторичный объект общедоступным для чтения

д. Напишите триггер, чтобы вторичный объект синхронизировался с обновлениями первичного.

Я также использую облачные функции большую часть времени, но этот метод полезен, когда вам нужна некоторая гибкость, и может быть проще, чем облачные функции, если вторичный объект представляет собой представление нескольких защищенных объектов.

Я сделал следующее.

1. Ограничить чтение/запись для всех классов. Единственный способ получить доступ к данным класса — через облачный код.
2. Убедитесь, что пользователь является зарегистрированным пользователем, используя параметр request.user , и если сеанс пользователя является нулевым и является ли идентификатор объекта законным.
3. Когда пользователь будет проверен, я позволю получить данные с помощью главного ключа.

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

Обычно я использую триггеры beforeSave, чтобы убедиться, что ACL всегда корректны. Так, например, объекты _User — это место, где находится электронная почта для восстановления. Мы не хотим, чтобы другие пользователи могли видеть электронные письма друг друга для восстановления, поэтому все объекты в классе _User должны иметь чтение и запись только для пользователя (с общедоступным чтением false и общедоступной записью false).

Таким образом, только сам пользователь может вмешиваться в свою собственную строку. Другие пользователи даже не заметят, что эта строка существует в вашей базе данных.

Один из способов ограничить это в некоторых ситуациях — использовать облачные функции. Допустим, один пользователь может отправить сообщение другому пользователю. Вы можете реализовать это как новый класс Message с содержимым сообщения и указателями на пользователя, отправившего сообщение, и на пользователя, который получит сообщение.

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

Таким образом, у вас есть две альтернативы: либо вы создаете триггер beforeSave, который проверяет, действительны ли изменения, которые пользователи пытаются внести в эту строку, перед их фиксацией, либо вы устанавливаете ACL сообщения так, чтобы ни у кого не было разрешений на запись, и вы создаете облачные функции, которые проверяют пользователя, а затем изменяют сообщение с помощью главного ключа.

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