Форма, которая красиво выглядит, ещё не хранит заявки. Для учебного прототипа можно сначала использовать mock-обработчик. Когда станет понятно, зачем нужна постоянная база или интеграция с CRM, подключайте её отдельным этапом и явно проверяйте, кто может читать и менять данные.
Сначала ответьте на вопросы о данных
- Какие поля нужны, чтобы связаться с человеком? Не собирайте «на всякий случай».
- Кто может прочитать заявку после отправки?
- Кто может её изменить или удалить?
- Как долго данные нужны и как человек может попросить их удалить?
- Как проверить права посетителя без доступа к чужим данным?
Для первых упражнений используйте вымышленные записи. Не загружайте в публичный конструктор переписки клиентов или рабочие пароли.
Если выбрали Supabase
Клиентская форма может обращаться к Data API только в соответствии с выданными ролями и политиками. В актуальном руководстве Supabase отдельно подчёркиваются два слоя: grants разрешают ролью операцию над таблицей, а Row Level Security фильтрует, к каким строкам эта операция применима. Одного включения RLS недостаточно, если широкие grants остались открытыми. Смотрите официальное руководство по RLS и защите Data API.
Для каждой таблицы спроектируйте правила отдельно для SELECT, INSERT, UPDATE, DELETE. Создайте тесты и на разрешённые, и на запрещённые действия. Если это многопользовательская система, тест должен подменять ID и tenant, а не только проверять успешный вход.
Секреты и внешние сервисы
Публичный ключ проекта может быть предназначен для браузерного клиента, но секрет с привилегированным доступом — нет. Секреты должны храниться в серверной среде/secret store; backend проверяет пользователя и передаёт только нужное действие. Секрет нельзя оставлять в HTML, клиентском JavaScript, скриншоте или открытом Git-репозитории.
Интеграцию с CRM добавляйте через маленький адаптер: входные поля, преобразование, ответы, таймауты и обработка ошибок. Не показывайте посетителю технические ответы CRM. Ошибка CRM не должна выглядеть как принятая заявка.
Матрица проверки доступа
| Кто действует | Читать заявку | Создать заявку | Изменить заявку |
|---|---|---|---|
| Не вошедший посетитель | Нет | Только разрешённая публичная форма | Нет |
| Владелец/оператор | Да, свои рабочие записи | Да | Да, по рабочим правилам |
| Другой пользователь | Нет | Только свою | Нет |
Это пример для обсуждения, не готовая политика для любого продукта. Утвердите роли до подключения реальных персональных данных.
Практика
- Заполните карточку данных и доступа.
- Выберите mock, базу или API и напишите, почему этого достаточно для первой версии.
- Для каждого действия перечислите allowed/denied тест.
- Проверьте клиентскую сборку на секреты и не создавайте production-ключи в учебном упражнении.
- Имитируйте недоступность базы/CRM: приложение должно честно сообщить о проблеме и сохранить возможность ручной проверки.
Артефакт: схема полей, матрица доступа, тесты allow/deny и решение о хранении.
Самопроверка
- Есть ли роль, которая может прочитать чужую заявку?
- Может ли клиентский код вызвать privileged API напрямую?
- Можете ли вы объяснить, какие данные и зачем сохраняются?