Проблема «кто что видит»: добавляем права доступа в приложение, созданное с ИИ

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

Потом вы добавляете первого коллегу, или первого клиента, или первого бета-тестера — и он видит то, что видеть не должен. Может, это зарплата его коллеги. Может, черновик, который был ещё не готов. Может, настройки администратора, случайно выставленные напоказ.

Это и есть проблема «кто что видит», и это самое крупное, что нетехнические разработчики делают неправильно, выпуская проект на ИИ-конструкторе приложений. Хорошая новость: чтобы это решить, не нужно становиться экспертом по безопасности. Нужен лишь понятный способ говорить об этом со своим ИИ-конструктором.

Почему приложение, созданное с ИИ, начинается с открытым доступом

Когда вы описываете приложение ИИ-конструктору — «хочу CRM, где можно добавлять клиентов и заметки» — конструктор оптимизирует под одно: чтобы оно работало для того, кто его описывает. Приложение по умолчанию устроено так: «каждый, кто вошёл, видит всё». Для личного инструмента это нормально. Это катастрофа в тот момент, когда появляется второй пользователь.

Это не баг ИИ-конструктора приложений. Это естественный результат того, что вы не сказали ему, кому что разрешено видеть. Конструктор понятия не имеет, что ваш список клиентов конфиденциален или что «Заметки» могут содержать то, что вы не хотите показывать клиентам. Вам нужно это сказать.

Три вопроса, которые стоит задать перед добавлением второго пользователя

Прежде чем кого-либо приглашать, спросите себя о трёх вещах. Запишите ответы — вы передадите их своему ИИ-конструктору на следующем шаге.

1. Какие есть роли?

Не люди — а категории. У большинства приложений их где-то от двух до четырёх. Для портала фрилансера: «Я» и «Клиент». Для внутреннего инструмента: «Администратор», «Менеджер», «Сотрудник». Для приложения сообщества: «Модератор», «Участник», «Гость». Сдержите порыв заводить больше четырёх ролей на раннем этапе. Каждая роль удваивает количество правил, которые вам придётся держать в голове.

2. Что каждая роль может видеть?

Мысленно пройдитесь по каждой странице приложения. Про каждую спросите: должен ли Клиент вообще видеть эту страницу? Должен ли он видеть все данные на ней или только свои? Должен ли он видеть страницу, но с какими-то скрытыми полями?

Самый простой шаблон: владельцы видят всё; все остальные видят только то, к чему им явно дали доступ. Это работает для 80% приложений почти без донастройки.

3. Что каждая роль может делать?

То же упражнение, но для кнопок и действий. Может ли Участник удалить проект? Может ли Клиент редактировать свой профиль, но не свой тариф? Может ли Менеджер приглашать новых людей? Большинство нетехнических разработчиков полностью забывают этот шаг и в итоге получают приложения, где любой вошедший пользователь может удалить всю базу данных одним нажатием кнопки.

Как говорить со своим ИИ-конструктором о правах доступа

Как только у вас есть ответы, запрос к ИИ-конструктору пишется сам собой. Выглядит он так:

Обнови это приложение, чтобы поддерживать две роли: Владелец и Клиент.

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

Клиенты могут видеть только свои проекты и свои счета. Они не могут видеть список клиентов, страницу команды и страницу настроек. Они могут просматривать свои проекты, но не редактировать их. Они могут просматривать и оплачивать свои счета.

Когда Клиент вошёл в систему, скрой ссылки навигации на Настройки и Команду. Если Клиент попытается зайти на эти страницы по URL, перенаправь его на его дашборд.

В этом запросе важны три вещи:

Будьте конкретны по страницам и действиям. «Клиенты могут видеть свои проекты» — расплывчато. «Клиенты могут просматривать, но не редактировать свои собственные проекты на странице /projects» — это то, что ИИ-конструктор действительно может реализовать.
Скажите, что происходит с навигацией. Скрыть ссылку — не то же самое, что заблокировать страницу. Вам нужно и то и другое.
Покройте случай с вводом URL. Иначе любопытный пользователь может вставить /admin в адресную строку браузера и спокойно зайти.

Четыре ошибки, которые я вижу каждую неделю

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

Скрыть кнопку — не значит скрыть данные. Если вы скажете своему ИИ-конструктору «скрой кнопку удаления для Клиентов», кнопка исчезнет с экрана. Но сама операция удаления всё ещё работает, если кто-то догадается, как её вызвать. Решение: скажите конструктору ещё и «отклоняй запросы на удаление от аккаунтов, не являющихся Владельцем, на бэкенде». Если конструктор не понимает, что значит «бэкенд» в вашем приложении, попросите его «заблокировать действие на стороне сервера, а не просто скрыть кнопку».

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

Разрешать пользователям приглашать пользователей с первого дня. Заманчиво сразу добавить «Пригласить коллегу». Не надо. Для первых 10 пользователей приглашайте их сами, вручную, из админ-панели, которую видите только вы. Самостоятельные приглашения — это целая категория правил доступа (кто кого может пригласить? какую роль получают приглашённые? могут ли они приглашать других?). Подождите, пока это вам реально понадобится.

Доверять словам ИИ-конструктора без проверки. ИИ-конструкторы будут уверенно говорить вам, что права доступа настроены. Может, и так. А может, и нет. Всегда проверяйте: войдите как пользователь не-владелец и попробуйте сделать что-нибудь нехорошее — нажать кнопки удаления, вставить админские URL, отредактировать поля, которые вам не положено редактировать. Если работает что-то, что не должно, — попросите конструктор исправить это конкретно.

Короткий чек-лист перед тем, как кого-то приглашать

Прежде чем отправить то первое приглашение второму пользователю, пройдитесь по этому:

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

Если какой-то из этих пунктов не проходит — это и есть следующий разговор с вашим ИИ-конструктором, до того как отправить приглашение, а не после.

Один сдвиг в мышлении, который помогает

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

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

Большинство разработчиков не думают о правах доступа, пока не случится что-нибудь неловкое. Хорошая новость: 20 минут, потраченные на размышления о ролях до выпуска, избавят вас от 20 часов на исправление этого потом, плюс от письма, которое вам очень не хочется писать клиенту, увидевшему что-то не то.

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