Проблема «хто що бачить»: додавання дозволів користувачів до застосунку на ШІ

Момент, коли ваш застосунок на ШІ перестає бути лише для вас, — це момент, коли дозволи стають реальною проблемою. До того кожна сторінка показує все. Кожен список показує кожен рядок. Кожна кнопка працює для всіх. Це однокористувацький застосунок, що вдає багатокористувацьким.

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

Це проблема «хто що бачить», і це найбільша річ, яку нетехнічні будівники роблять неправильно, випускаючи проєкт із конструктора застосунків на ШІ. Хороша новина: вам не треба ставати експертом із безпеки, щоб її розв’язати. Вам просто треба чіткий спосіб говорити про це зі своїм конструктором на ШІ.

Чому ваш застосунок на ШІ починається дозвільним

Коли ви описуєте застосунок конструктору на ШІ — «я хочу CRM, де я можу додавати клієнтів і нотатки» — конструктор оптимізує під одну річ: змусити це працювати для людини, що описує. Типовий застосунок — це «кожен, хто увійшов, може бачити все». Це нормально для особистого інструмента. Це катастрофа тієї миті, коли з’являється другий користувач.

Це не баг конструктора застосунків на ШІ. Це природний результат того, що ви не сказали йому, кому що дозволено бачити. Конструктор не має уявлення, що ваш список клієнтів чутливий чи що «Нотатки» можуть містити речі, які ви не хочете, щоб клієнти бачили. Ви маєте це сказати.

Три запитання, які треба поставити перед додаванням другого користувача

Перш ніж когось запросити, запитайте себе три речі. Запишіть відповіді — ви передасте їх своєму конструктору на ШІ на наступному кроці.

1. Які ролі?

Не люди — категорії. Більшість застосунків має десь від двох до чотирьох. Для порталу фрилансера: «Я» і «Клієнт». Для внутрішнього інструмента: «Адмін», «Менеджер», «Член команди». Для застосунку спільноти: «Модератор», «Член», «Гість». Опирайтеся бажанню перевищити чотири ролі рано. Кожна роль подвоює правила, які вам треба відстежувати.

2. Для кожної ролі — що вони можуть бачити?

Пройдіться кожною сторінкою свого застосунку подумки. Для кожної запитайте: чи має Клієнт узагалі бачити цю сторінку? Чи має він бачити всі дані на ній, чи лише власні? Чи має він бачити сторінку, але з деякими прихованими полями?

Найпростіший патерн: власники бачать усе; усі інші бачать лише те, до чого їм явно надано доступ. Це працює для 80% застосунків без особливого налаштування.

3. Для кожної ролі — що вони можуть робити?

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

Як говорити зі своїм конструктором на ШІ про дозволи

Щойно у вас є відповіді, промпт до вашого конструктора на ШІ пишеться сам. Він виглядає так:

Онови цей застосунок, щоб підтримувати дві ролі: Власник і Клієнт.

Власники можуть бачити всіх клієнтів, усі проєкти й усі рахунки. Власники можуть створювати, редагувати й видаляти будь-що.

Клієнти можуть бачити лише власні проєкти й власні рахунки. Вони не можуть бачити список клієнтів, сторінку команди чи сторінку налаштувань. Вони можуть переглядати свої проєкти, але не можуть їх редагувати. Вони можуть переглядати й оплачувати власні рахунки.

Коли Клієнт увійшов, ховай навігаційні посилання на Налаштування й Команду. Якщо Клієнт намагається відвідати ці сторінки за URL, перенаправляй його на його дашборд.

Три речі важать у цьому промпті:

Будьте конкретні за сторінкою й дією. «Клієнти можуть бачити свої проєкти» розпливчасто. «Клієнти можуть переглядати, але не редагувати власні проєкти на сторінці /projects» — це те, що конструктор на ШІ справді може реалізувати.
Скажіть, що стається з навігацією. Сховати посилання — не те саме, що заблокувати сторінку. Ви хочете обидва.
Покрийте випадок набирання URL. Інакше цікавий користувач може вставити /admin у рядок браузера й зайти прямо.

Чотири помилки, які я бачу щотижня

Поспостерігавши, як багато будівників випускають свій перший багатокористувацький застосунок, виринають ті самі помилки:

Сховати кнопку — не те саме, що сховати дані. Якщо ви кажете своєму конструктору на ШІ «сховай кнопку видалення для Клієнтів», кнопка зникає з екрана. Але базова операція видалення все ще працює, якщо хтось з’ясує, як її викликати. Виправлення: також скажіть конструктору «відхиляй запити на видалення від акаунтів не-Власників на боці сервера». Якщо конструктор не знає, що означає «бекенд» у вашому застосунку, попросіть його «блокувати дію на боці сервера, а не лише ховати кнопку».

Одна роль для двох робіт. Люди змішують «людей, що платять» із «людьми, що користуються застосунком». Клієнт, що платить вам за роботу, і Клієнт-працівник, що користується дашбордом, який ви збудували для того клієнта, — не та сама роль. Якщо ви їх змішаєте, ви проведете наступний місяць, латаючи разові правила. Дві ролі. Завжди.

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

Довіряти тому, що каже конструктор на ШІ, без перевірки. Конструктори на ШІ скажуть вам упевнено, що дозволи налаштовані. Можливо, так. Можливо, ні. Завжди тестуйте, входячи як не-власник і намагаючись робити погані речі: клікати кнопки видалення, вставляти адмінські URL, редагувати поля, які ви не повинні мати змоги редагувати. Якщо щось працює, що не повинно, попросіть конструктор виправити це конкретно.

Швидкий чекліст перед запрошенням будь-кого

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

Я можу перелічити ролі у своєму застосунку на пальцях однієї руки.
Для кожної ролі я знаю, які сторінки вони мають бачити, а які ні.
Я ввійшов як не-власник і підтвердив, що неправильні сторінки приховані.
Я спробував вставити адмінський URL у браузер як не-власник і отримав блокування.
Я спробував клікнути кнопки видалення чи редагування, що мають бути заборонені, і отримав блокування.
Якщо щось піде не так, у мене є спосіб швидко прибрати доступ користувача.

Якщо будь-який із цих пунктів не проходить, це наступна розмова з вашим конструктором на ШІ — перш ніж надіслати запрошення, а не після.

Один зсув мислення, що допомагає

Побудова дозволів для багатокористувацького застосунку — це здебільшого про те, щоб уявити, що ви — трохи допитлива версія вашого найгірше поведеного користувача. Не зловмисна — просто цікава. Він клікатиме речі. Він вставлятиме URL. Він спробує побачити, що на сторінці «Налаштування», яку він помітив на вашому скриншоті.

Ваша робота — і робота вашого конструктора на ШІ — переконатися, що коли він дивиться, відповідь стабільна: або він може це бачити, бо це його дані, або не може, бо це не його. Жодних країв. Жодних випадково відкритих адмінських сторінок. Жодного «я забув, що ця сторінка існує».

Більшість будівників не думає про дозволи, доки не станеться щось ніякове. Хороша новина: витратити 20 хвилин на роздуми про ролі перед випуском заощаджує вам 20 годин виправлення цього потім плюс лист, який ви не хочете писати клієнту, що побачив неправильну річ.

Будуєте щось із багатокористувацьким боком? Наступного разу, коли сядете зі своїм конструктором застосунків на ШІ, почніть сесію з переліку ролей у вашому застосунку вголос. Це найлегша п’ятихвилинна звичка для напрацювання, і вона зловить більшість найгірших помилок, перш ніж вони стануться.