CMS: обзор прав доступа к коллекции

Управление правами доступа дают вам контроль над тем, кто из посетителей получит доступ к данным в коллекциях и какие действия они смогут совершать.

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

Права доступа устанавливаются отдельно для каждой коллекции. Вы настраиваете разрешения, которые определяют, какие действия разрешены для каждой из ролей. Например, вы можете предоставить Зарегистрированным пользователям сайта разрешение на создание новых элементов в коллекции комментариев, при этом выдать разрешение создавать элементы в другой коллекции только Администраторам сайта.

При выборе пресетов прав доступа к коллекции обратите внимание на права доступа, выставленные по умолчанию.

Модель прав доступа к коллекции содержит несколько пресетов, которые автоматически устанавливают разрешения для самых распространенных сценариев. Например, параметр Публичный должен использоваться только для неконфиденциальной информации, такой как коллекции, не содержащие данных пользователей. Это связано с тем, что разрешение на чтение такой коллекции будет присвоено роли Все, а остальные действия будут доступны только роли Администратор:

Другой пример — пресет Отправка формы, который устанавливает следующие права доступа:

При использовании Собственных настроек убедитесь, что заданные вами права доступа соответствуют бизнес-логике и требованиям конфиденциальности данных в коллекции. Коллекции с информацией о клиентах или лидах должны обрабатываться иначе, чем коллекции, связанные с товарами

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

Поддерживаются следующие типы прав доступа.

Роли автоматически назначаются пользователям в зависимости от их активности и статуса на сайте. Вы можете редактировать и удалять только те роли, которы были созданы вами.

В настоящее время Собственные роли не поддерживаются моделью прав доступа. Однако пользователи Velo могут реализовать собственную роль в коллекции, установив тип прав доступа к коллекции "Администратор" и используя код для вызова данных из бэкенда с параметром SuppressAuth. Вызов данных должен быть выполнен после того, как новая пользовательская роль пройдет валидацию функциональностью API wix-users в коде.

Администратор всегда имеет права на совершение любых возможных действий.

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

Когда вы просматриваете свой сайт, вы делаете это в роли Администратора. Чтобы взаимодействовать с сайтом как пользователь с другой ролью, сначала опубликуйте сайт, а затем либо войдите в аккаунт как другой пользователь (роль Зарегистрированный пользователь сайта), либо не авторизуйтесь вообще (роль Все). Помните: если на вашем сайте включен режим песочницы, ваш действующий сайт работает с актуальными коллекциями, а не с коллекциями песочницы, которые вы видите в CMS или в режиме предварительного просмотра.

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

При взаимодействии с коллекциями с помощью Data API (информация на англ. языке) в определенных случаях можно обойти существующую модель прав доступа. Опциональный аргумент WixDataOptions можно отправить при вызове функции API с установленным значением true для свойства SuppressAuth. Это приведет к тому, что функция запустится без проверки текущего пользователя на наличие необходимых разрешений. Вы можете обойти проверку прав доступа только при вызове API из бэкенд-кода. Вызовы API на стороне клиента всегда будут запускать проверки прав доступа, независимо от того, какие параметры передаются.

Коллекция может содержать комментарии, а также адрес электронной почты автора комментария. Посетители должны иметь возможность просматривать комментарии, при этом только у администратора должен быть доступ к просмотру почтовых адресов. В таком случае необходимо выставить права на чтение для коллекции комментариев для «Администратора». Отмена авторизации позволит разрешить посетителям просматривать комментарии без предоставления права «читать» коллекцию комментариев.

Это можно сделать, написав веб-модуль в файле jsw в бэкенде, который будет вызывать коллекцию комментариев со свойством SuppressAuth, с установленным значением true, а затем отфильтровывать ответ и возвращать только желаемые поля (комментарии) клиенту, чтобы посетитель сайта мог просмотреть их без доступа к другим полям коллекции. В первую очередь — без адресов электронной почты.

Другой пример использования SuppressAuth — это когда вы хотите выдать [собственной роли (конкретному пользователю сайта или группе пользователей) доступ к коллекции, взаимодействие с которой ограничено правами доступа уровня Администратора.

Во втором примере веб-модуль должен проверить личность (информация на англ. языке) или роль участника сайта до запроса данных. В первом примере веб-модуль должен отфильтровать результаты до того как вернет данные клиенту.