Правило Current User Only в Bubble.io — это настройка приватности, при которой запись в базе данных доступна исключительно тому пользователю, который её создал. Если оставить тип данных без такого правила, любой посетитель приложения потенциально сможет получить чужие записи через поиск или прямой запрос к API — это одна из самых частых причин утечек данных в no-code-проектах.
Проблема в том, что Bubble по умолчанию не скрывает данные: ограничения на уровне интерфейса (скрытые группы, условия видимости) не защищают информацию, потому что данные всё равно загружаются в браузер. Реальную защиту обеспечивают только Privacy Rules, и именно здесь применяется концепция «только текущий пользователь».
Что означает Current User Only
Выражение Current User в Bubble обозначает пользователя, который в данный момент авторизован в приложении. Когда в правиле приватности указано условие вида Created By = Current User, платформа на уровне сервера отфильтровывает записи: клиент получает только те объекты, где поле Created By совпадает с идентификатором текущего пользователя.
Важно понимать разницу между двумя подходами:
- 🔒 Privacy Rules — фильтрация на сервере, данные физически не отправляются в браузер;
- 👁 Условия видимости элементов — данные загружаются, но скрываются визуально, их можно увидеть в инструментах разработчика;
- 🔍 Ограничения в поиске — фильтр внутри запроса, который забывчивый разработчик может не продублировать везде;
- 🌐 Публичный доступ — отсутствие правил вообще, записи доступны всем, включая неавторизованных посетителей.
Где настраивается правило
Настройка выполняется в редакторе Bubble на вкладке Data → Privacy. Там для каждого типа данных создаются роли и правила. Типичная конфигурация для приватных записей выглядит так: создаётся роль с условием When This <ТипДанных>'s Created By is Current User, и для неё разрешаются действия View all fields, Find this in searches, View attached files.
Для всех остальных пользователей (роль Everyone else) эти галочки снимаются. В результате чужая запись просто не существует для постороннего клиента — ни в поиске, ни в повторяющихся группах, ни через API.
☑️ Проверка настройки приватности
Типичные ошибки при настройке
Самая распространённая ошибка — забыть, что правила приватности не применяются к данным, которые уже загружены на страницу через элементы, настроенные до логина. Ещё одна частая проблема: разработчик тестирует приложение под аккаунтом администратора, для которого действуют расширенные права, и не видит утечку, очевидную для обычного пользователя.
⚠️ Внимание: если в приложении включён Data API и не заданы Privacy Rules, записи могут быть доступны по прямому запросу к endpoint. Перед публикацией приложения проверьте, какие типы данных экспонируются через API, и убедитесь, что для них настроены правила.
Также стоит учитывать: поле Created By заполняется автоматически только если запись создаёт авторизованный пользователь. Записи, созданные через backend workflow без привязки к пользователю, могут не попасть под правило — для них нужно явно сохранять ссылку на владельца в отдельное поле.
Сравнение подходов к ограничению доступа
Выбор способа зависит от структуры приложения. Ниже — сравнение основных вариантов:
| Способ | Уровень защиты | Когда применять |
|---|---|---|
| Created By = Current User | Серверный, надёжный | Личные записи: заметки, заказы, профили |
| Поле-владелец (кастомное) | Серверный, гибкий | Когда создатель и владелец — разные люди |
| Роли (Admin, Manager) | Серверный, групповой | Командные приложения с иерархией |
| Скрытие элементов на странице | Только визуальное | Улучшение UX, не для защиты данных |
Как видно, визуальное скрытие не является защитой — это лишь косметическая мера, которую нельзя использовать как единственный барьер для конфиденциальных данных.
Как проверить, что правило работает
Проверка выполняется в несколько шагов. Сначала создайте двух тестовых пользователей и добавьте записи от имени каждого. Затем авторизуйтесь под первым и убедитесь, что поиск возвращает только его данные. После этого выйдите из аккаунта полностью и повторите запрос — для неавторизованного посетителя выдача должна быть пустой.
Дополнительно откройте инструменты разработчика браузера и посмотрите сетевые запросы: в ответах сервера не должно быть чужих записей даже в «сыром» виде. Если данные присутствуют в ответе, но скрыты на странице — правило приватности настроено неверно или отсутствует.
Особые случаи: файлы и связанные данные
Отдельного внимания заслуживают загруженные файлы. В Bubble файл, прикреплённый к записи, защищается опцией Attach this file to a thing при загрузке — тогда доступ к файлу наследует правила приватности родительской записи. Если файл загружен без привязки, его прямая ссылка может остаться доступной всем, у кого она есть.
⚠️ Внимание: прямые ссылки на файлы, загруженные без привязки к приватной записи, не защищены правилом Current User Only. Проверьте настройки загрузки файлов, если в приложении хранятся документы или личные изображения.
Связанные типы данных тоже требуют внимания: если запись «Заказ» приватна, но связанный «Платёж» имеет открытые правила, информация всё равно может утечь через смежный тип. Правила нужно настраивать для каждого типа данных отдельно.
Что делать с записями, созданными до настройки правил
Privacy Rules применяются ко всем записям типа, включая старые — миграция не требуется. Но если у старых записей пустое поле Created By (например, они импортированы), они не попадут под правило «Created By is Current User» и станут недоступны владельцам. В таком случае нужно заполнить поле владельца для существующих записей через backend workflow.
Рекомендации по архитектуре приватности
Продумывать правила лучше до наполнения базы данными. Практический порядок действий такой: определите, какие типы данных являются личными, для каждого создайте правило с условием на текущего пользователя, затем добавьте роли для администраторов или менеджеров, если они нужны. После этого протестируйте каждый тип под разными аккаунтами.
- 🛡 Начинайте с запретительной модели: по умолчанию всё закрыто, доступ открывается явно;
- 👤 Для каждого личного типа данных используйте условие на Current User;
- 🧪 Тестируйте приватность отдельным тестовым пользователем без прав администратора;
- 📎 Проверяйте привязку файлов к записям при загрузке;
- 🔄 Перепроверяйте правила после добавления новых типов данных и API-endpoint.
Часто задаваемые вопросы
Защищает ли скрытие группы на странице данные внутри неё?
Нет. Скрытые элементы лишь не отображаются, но данные всё равно загружаются в браузер и видны в сетевых запросах. Защиту обеспечивают только Privacy Rules на вкладке Data → Privacy.
Работает ли правило Current User Only для неавторизованных посетителей?
Для неавторизованного посетителя Current User не существует, поэтому условие Created By is Current User не выполняется, и записи ему недоступны — при условии, что для роли Everyone else сняты разрешения.
Что делать, если запись создаётся через backend workflow?
Backend workflow не всегда привязывает запись к пользователю автоматически. Передайте пользователя в workflow параметром и сохраните его в поле владельца, а правило приватности настройте на это поле.
Нужно ли настраивать правила для каждого типа данных отдельно?
Да. Правила приватности в Bubble задаются на уровне типа данных и не наследуются между связанными типами. Каждый тип, содержащий чувствительную информацию, требует собственной конфигурации.
Влияют ли Privacy Rules на производительность поиска?
Фильтрация выполняется на сервере и обычно не создаёт заметной нагрузки при типичных объёмах данных. Правильно настроенные правила могут даже сократить объём передаваемых данных, так как клиент получает только разрешённые записи.