Problem „kto co widzi”: dodawanie uprawnień użytkowników do aplikacji zbudowanej z AI

Moment, w którym Twoja aplikacja zbudowana z AI przestaje być tylko dla Ciebie, to moment, w którym uprawnienia stają się prawdziwym problemem. Do tej pory każda strona pokazywała wszystko. Każda lista pokazywała każdy wiersz. Każdy przycisk działał dla wszystkich. To aplikacja jednoosobowa udająca wieloosobową.

A potem dodajesz pierwszego współpracownika, pierwszego klienta albo pierwszego beta-testera — i widzą coś, czego nie powinni widzieć. Może to wynagrodzenie ich kolegi z zespołu. Może to szkic, który nie był gotowy. Może to ustawienia administracyjne, przypadkowo wystawione na widok.

To właśnie problem „kto co widzi” i jest to największa pojedyncza rzecz, którą nietechniczni twórcy robią źle, wdrażając projekt z kreatora aplikacji z AI. Dobra wiadomość: nie musisz zostać ekspertem od bezpieczeństwa, żeby go rozwiązać. Potrzebujesz tylko jasnego sposobu, żeby porozmawiać o tym ze swoim kreatorem AI.

Dlaczego aplikacja zbudowana z AI zaczyna jako zbyt liberalna

Kiedy opisujesz aplikację kreatorowi AI — „chcę CRM, w którym mogę dodawać klientów i notatki” — kreator optymalizuje pod jedno: żeby zadziałało dla osoby, która to opisuje. Domyślna aplikacja brzmi: „każdy zalogowany może widzieć wszystko”. To w porządku dla osobistego narzędzia. To katastrofa w momencie, gdy pojawia się drugi użytkownik.

To nie jest błąd kreatora aplikacji z AI. To naturalny skutek tego, że nie powiedziałeś mu, kto co może widzieć. Kreator nie ma pojęcia, że Twoja lista klientów jest poufna albo że „Notatki” mogą zawierać rzeczy, których nie chcesz pokazywać klientom. Musisz mu to powiedzieć.

Trzy pytania, które trzeba zadać przed dodaniem drugiego użytkownika

Zanim kogokolwiek zaprosisz, zadaj sobie trzy pytania. Zapisz odpowiedzi — w następnym kroku podasz je swojemu kreatorowi AI.

1. Jakie są role?

Nie ludzie — kategorie. Większość aplikacji ma ich gdzieś między dwie a cztery. W portalu dla freelancera: „Ja” i „Klient”. W narzędziu wewnętrznym: „Administrator”, „Menedżer”, „Członek zespołu”. W aplikacji społecznościowej: „Moderator”, „Członek”, „Gość”. Powstrzymaj pokusę, żeby wcześnie przekroczyć cztery role. Każda rola podwaja liczbę reguł, które musisz mieć na oku.

2. Co każda rola może widzieć?

Przejdź w głowie przez każdą stronę swojej aplikacji. Przy każdej zapytaj: czy Klient powinien w ogóle widzieć tę stronę? Czy powinien widzieć wszystkie dane na niej, czy tylko swoje? Czy powinien widzieć stronę, ale z ukrytymi niektórymi polami?

Najprostszy wzorzec: właściciele widzą wszystko; wszyscy pozostali widzą tylko to, do czego dostali wyraźny dostęp. To działa dla 80% aplikacji bez większego dostosowywania.

3. Co każda rola może robić?

To samo ćwiczenie, ale dla przycisków i akcji. Czy Członek może usunąć projekt? Czy Klient może edytować swój profil, ale nie swój plan? Czy Menedżer może zapraszać nowe osoby? Większość nietechnicznych twórców zupełnie pomija ten krok i kończy z aplikacjami, w których dowolny zalogowany użytkownik może usunąć całą bazę danych jednym kliknięciem.

Rozmowa z kreatorem AI o uprawnieniach

Gdy masz odpowiedzi, prompt do Twojego kreatora AI pisze się sam. Wygląda tak:

Zaktualizuj tę aplikację, żeby obsługiwała dwie role: Właściciel i Klient.

Właściciele mogą widzieć wszystkich klientów, wszystkie projekty i wszystkie faktury. Właściciele mogą tworzyć, edytować i usuwać wszystko.

Klienci mogą widzieć tylko swoje projekty i swoje faktury. Nie mogą widzieć listy klientów, strony zespołu ani strony ustawień. Mogą oglądać swoje projekty, ale nie mogą ich edytować. Mogą oglądać i opłacać swoje faktury.

Kiedy Klient jest zalogowany, ukryj w nawigacji odnośniki do Ustawień i Zespołu. Jeśli Klient spróbuje wejść na te strony przez URL, przekieruj go na jego panel.

W tym promptcie liczą się trzy rzeczy:

Bądź konkretny co do strony i akcji. „Klienci mogą widzieć swoje projekty” jest mgliste. „Klienci mogą oglądać, ale nie edytować swoich projektów na stronie /projects” to coś, co kreator AI faktycznie potrafi zaimplementować.
Powiedz, co dzieje się z nawigacją. Ukrycie odnośnika to nie to samo, co zablokowanie strony. Chcesz obu.
Uwzględnij przypadek wpisywania URL-a. Inaczej ciekawski użytkownik może wkleić /admin w pasku przeglądarki i wejść jak do siebie.

Cztery błędy, które widzę co tydzień

Po obserwowaniu wielu twórców wdrażających pierwszą wieloosobową aplikację, w kółko pojawiają się te same błędy:

Ukrycie przycisku to nie ukrycie danych. Jeśli powiesz kreatorowi AI „ukryj przycisk usuwania dla Klientów”, przycisk zniknie z ekranu. Ale stojąca za nim operacja usuwania nadal działa, jeśli ktoś wymyśli, jak ją wywołać. Rozwiązanie: powiedz też kreatorowi „odrzucaj żądania usunięcia od kont innych niż Właściciel po stronie backendu”. Jeśli kreator nie wie, co w Twojej aplikacji znaczy „backend”, poproś, żeby „zablokował akcję po stronie serwera, nie tylko ukrył przycisk”.

Jedna rola do dwóch zadań. Ludzie mylą „tych, którzy płacą” z „tymi, którzy używają aplikacji”. Klient, który płaci Ci za pracę, i pracownik klienta korzystający z panelu, który dla tego klienta zbudowałeś, to nie ta sama rola. Jeśli je zmieszasz, spędzisz kolejny miesiąc na łataniu jednorazowych reguł. Dwie role. Zawsze.

Pozwalanie użytkownikom zapraszać użytkowników od pierwszego dnia. Kuszące jest dodanie „Zaproś współpracownika” od razu. Nie rób tego. Przy pierwszych 10 użytkownikach zapraszaj ich sam, ręcznie, z panelu administracyjnego, który widzisz tylko Ty. Samoobsługowe zaproszenia to cała kategoria reguł uprawnień (kto może zapraszać kogo? jaką rolę dostają zaproszeni? czy mogą zapraszać innych?). Poczekaj, aż naprawdę będziesz tego potrzebować.

Ufanie temu, co mówi kreator AI, bez sprawdzenia. Kreatory AI powiedzą Ci pewnie, że uprawnienia są ustawione. Może i są. A może nie. Zawsze testuj, logując się jako osoba niebędąca właścicielem i próbując robić złe rzeczy: klikaj przyciski usuwania, wklejaj URL-e administracyjne, edytuj pola, których nie powinieneś móc edytować. Jeśli zadziała coś, co nie powinno, poproś kreatora, żeby konkretnie to naprawił.

Szybka lista kontrolna, zanim kogokolwiek zaprosisz

Zanim wyślesz to pierwsze zaproszenie do drugiego użytkownika, przejdź przez to:

Potrafię wymienić role w mojej aplikacji na palcach jednej ręki.
Dla każdej roli wiem, które strony powinna widzieć, a których nie.
Zalogowałem się jako osoba niebędąca właścicielem i potwierdziłem, że niewłaściwe strony są ukryte.
Spróbowałem wkleić w przeglądarce URL administracyjny jako osoba niebędąca właścicielem i zostałem zablokowany.
Spróbowałem kliknąć przyciski usuwania lub edycji, które powinny być niedostępne, i zostałem zablokowany.
Jeśli coś pójdzie nie tak, mam sposób, żeby szybko odebrać użytkownikowi dostęp.

Jeśli któryś z tych punktów nie przechodzi, to właśnie kolejna rozmowa z Twoim kreatorem AI — zanim wyślesz zaproszenie, nie po.

Jedna zmiana nastawienia, która pomaga

Budowanie uprawnień dla aplikacji wieloosobowej polega głównie na wyobrażeniu sobie, że jesteś nieco wścibską wersją swojego najgorzej zachowującego się użytkownika. Nie złośliwą — po prostu ciekawą. Będą klikać różne rzeczy. Będą wklejać URL-e. Będą próbować zobaczyć, co jest na stronie „Ustawienia”, którą zauważyli na Twoim zrzucie ekranu.

Twoim zadaniem — i zadaniem Twojego kreatora AI — jest sprawić, żeby gdy spojrzą, odpowiedź była spójna: albo mogą to zobaczyć, bo to ich dane, albo nie mogą tego zobaczyć, bo to nie ich. Żadnych krawędzi. Żadnych przypadkowo wystawionych stron administracyjnych. Żadnego „zapomniałem, że ta strona istnieje”.

Większość twórców nie myśli o uprawnieniach, dopóki nie wydarzy się coś żenującego. Dobra wiadomość: poświęcenie 20 minut na przemyślenie ról przed wdrożeniem oszczędza Ci 20 godzin naprawiania tego później, plus maila, którego nie chcesz pisać do klienta, który zobaczył coś nie tego.

Budujesz coś z elementem wieloosobowym? Następnym razem, gdy siądziesz do swojego kreatora aplikacji z AI, zacznij sesję od wymienienia na głos ról w Twojej aplikacji. To najłatwiejszy pięciominutowy nawyk do wyrobienia i wyłapie większość najgorszych błędów, zanim się wydarzą.