Клиентский портал в Baserow: заявки, документы и доступ только к своим данным

MAATRIX · 17 октября 2026 · 8 мин чтения

«Пришлите, пожалуйста, актуальный статус» — письмо короткое, но ответ на него занимает время. Нужно найти заявку, уточнить этап, отыскать последний файл и убедиться, что в прикреплённой версии нет внутренних комментариев. Когда клиентов становится больше, менеджер постепенно превращается в интерфейс к таблице.

Клиентский портал даёт человеку возможность самому посмотреть свои заявки и доступные документы. В Baserow для этого есть Application Builder. Он помогает собрать страницы поверх таблиц, но главная работа происходит до выбора цвета кнопки: нужно правильно связать клиента с данными и проверить эту связь на сервере.

Построим учебный портал сервисной компании. У каждого заказчика есть список обращений, карточка отдельной заявки и документы. Сотрудники ведут данные в Baserow, клиент входит в отдельное приложение. Доступ к редактору базы ему не нужен.

Проверьте редакцию до начала разработки

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

Для пилота составьте список обязательных возможностей: индивидуальный вход, выборка своих строк, просмотр карточки, выдача файлов и отзыв доступа. Если какой-то пункт зависит от платной редакции, включите лицензию в бюджет сразу. Цена сервера — только часть стоимости такого портала.

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

Схема таблиц, которая не требует гадать по имени

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

Для учебной модели понадобятся четыре таблицы:

Связывайте строки полями отношений, а не одинаковым текстом в двух колонках. Если заявку связали с клиентом через название, опечатка превращается в проблему доступа. Поле «внутренний комментарий» храните отдельно от текста, который разрешено показывать заказчику.

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

Настраиваем вход через User Source

В настройках приложения откройте раздел пользователей и добавьте User Source. Выберите интеграцию с нужной базой, таблицу пользователей и поля, которые соответствуют имени и адресу электронной почты. Для входа по паролю нужен специальный тип поля Password и предусмотренный системой способ создания учётной записи.

Не храните пароли обычным текстом в колонке. Baserow описывает настройку и обработку паролей в руководстве User Sources. Проверьте текущий порядок создания пользователя через форму регистрации или административный инструмент вашей версии.

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

Добавьте страницу входа и элемент Login, подключённый к этому источнику. Укажите страницу, на которую человек попадает после входа. Для закрытых страниц настройте перенаправление неавторизованного посетителя. Проверьте выход из аккаунта и повторный вход в приватном окне.

Фильтр должен работать до отправки данных браузеру

На странице «Мои заявки» создайте источник данных, который возвращает только строки текущего клиента. Логика условия: владелец заявки связан с клиентом вошедшего пользователя. Значение берётся из доверенного контекста User Source, а не из произвольного параметра адресной строки.

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

Для карточки заявки добавьте второй критерий: запрошенный ID. Получается два условия одновременно — нужный номер и принадлежность текущему клиенту. Если оставить только номер из URL, соседняя заявка может оказаться доступной после простой замены цифры.

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

Документы требуют собственной проверки

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

Перед размещением договоров или других чувствительных материалов выясните, как ваша версия Baserow выдаёт файлы и какие механизмы ограничивают их скачивание. Проведите простой тест: скопируйте адрес файла, выйдите из аккаунта и откройте адрес в другом браузере. Затем повторите проверку под другим клиентом.

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

Разделяйте исходный документ и клиентскую версию. У менеджера могут быть заметки, которые заказчику не предназначены. Поле «разрешён клиенту» удобно для рабочего процесса, но само по себе не заменяет правило доступа к файлу.

Проверяем портал двумя заказчиками

Создайте учебные компании «Север» и «Юг», по пользователю для каждой, несколько заявок и разные документы. Эти названия — только тестовые данные. Войдите как первый клиент и составьте список того, что видно в интерфейсе и сетевых ответах браузера.

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

Затем отзовите доступ первого пользователя и проверьте поведение уже открытой сессии. Не ограничивайтесь тем, что новый вход запрещён: важны существующие сеансы и время их прекращения. Зафиксируйте фактическое поведение установленной версии и предусмотрите процедуру срочного отзыва.

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

Если клиенту нужно изменить контактные сведения

Самая безопасная первая версия портала разрешает только просмотр. Когда появится запрос на редактирование, начните с одного действия: отправить заявку на изменение контакта. Сотрудник проверяет её и обновляет основную запись. Так вы отделите удобную форму от решения о том, кому теперь принадлежат права доступа.

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

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

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

Где разместить и как обслуживать

Для небольшого пилота можно начать с MAATRIX Heka Standard с 4 vCPU и 8 GB памяти. Baserow, база, фоновые процессы и файлы требуют ресурсов даже тогда, когда приложение выглядит как несколько простых форм. Окончательный размер выбирайте после проверки своих таблиц, поисковых запросов и вложений.

Используйте поддерживаемую Linux-систему и официальный способ установки. Начальная подготовка разобрана в статье об установке Baserow. Служебные порты базы не публикуйте, административный интерфейс ограничьте, клиентскому приложению назначьте отдельный домен с HTTPS.

Сохраняйте базу, файловые данные и конфигурацию. Проверяйте восстановление на отдельном сервере с тестовыми пользователями. Перед обновлением повторяйте проверки «Север против Юга»: изменение продукта иногда затрагивает именно формулы, интеграции или настройки доступа.

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