Interfejsy według roli i dostępu

1) Zasady

1. Bezpieczeństwo = zadanie UX. Użytkownik musi jasno zrozumieć, co może i nie może zrobić bez „szarych obszarów”.
2. Minimalne niezbędne prawa. Od wyświetlania po działania, wszystko ogranicza się do zadań ról.
3. Sygnał zamiast zakazu. Jeśli nie ma dostępu, wyjaśniamy dlaczego i jak się dostać (prośba, aplikacja, szkolenie).
4. Powielanie na serwerze. Strażnicy UI nigdy nie wymieniają czeków serwera.
5. Przejrzysty audyt. Każde wrażliwe działanie pozostawia czytelny znak.

2) Modele kontroli dostępu

RBAC (Role-Based): Stałe role: Gracz, Wsparcie, Finanse, Ryzyko/Zgodność, Menedżer Affiliate, Moderator, Administrator.
ABAC (Atrybut-Based): polityka oparta na atrybutach (jurysdykcja, marka, strefa czasowa, poziom VIP, zespół, zmiana).
ReBAC (Relationship-Based): dostęp według relacji (gracz, posiadacz biletu, partner manager).
SoD (Segregacja Obowiązków) - rozdzielenie zadań krytycznych (utworzonych, zatwierdzonych).

Praktyka: RBAC jako podstawa, ABAC dla drobnego dostrajania (marka/region), SoD dla finansów/limitów, ReBAC - punkt (portfele kuratoryjne).

3) Mapa funkcji według roli (przykład iGaming)

Sekcja	Gracz	Wsparcie	Finansowanie	Zgodność/ryzyko	Podmioty zależne	Administrator
Profil/limity	(własność)	R/W (na żądanie)	R	R/W (z ograniczeniami) R	R
Płatności (depozyty/wypłaty)	(własność)	R	R/W (delegowanie)	R/W (zamrożenie/wstrzymanie)	R	R
CMC/dokumenty	(własność)	R (częściowo maskowanie) R (maska) R/W (werdykt)	—	R
Zakłady/Historia	(własność)	R	R	R	—	R
Promocje/premie	R/W (opłata)	—	R	R/W (partnerzy)	R
Użytkownicy	—	R (bilety)	—	R	R (partnerzy)	R/W
R - czytaj, W - napisz. Maskowanie - według polityki danych (PII/PAN/KYC).

4) Wzory UX dla praw i ról

4. 1 Nawigacja i widoczność

Ukryj niedostępne sekcje przed nawigacją (redukcja szumów), ale pokaż informacyjne „puste” karty, jeśli pomaga to zrozumieć możliwości.
Tymczasowo niedostępne - „Lock” z wskazówką: powód, wymagania, CTA „Request access”.

4. 2 Państwa działania

Wyłączony + podpowiedź: "Rola finansowa wymagana. Prosimy o dostęp.
Tryb tylko do odczytu: pola „pod szkłem”, wyraźny znacznik „Tylko do odczytu”.
Eskalacja - Kliknij przycisk Prześlij do zatwierdzenia zamiast aplikacji.

4. 3 Maskowanie i edycja

PII (e-mail, telefon, adres) - 'user @', '+ 380 90' dla innych osób.
PAN/IBAN - tylko żetony/ostatnie 4.
Pokaż pełny przycisk radia - posiadanie roli tylko/przez zdarzenie audytu.

5) Architektura pozwolenia w UI

Kontekst zasad dotyczących klienta: pamięć podręczna uprawnień (TTL short) + subskrypcja aktualizacji.
Straż drogowa: niedostępne trasy → 403-stronicowe z wyjaśnieniem i CTA.
Osłony komponentów: „Can ({action: 'approve _ within', resource: 'payout'})”.
Ficheflags: rzeczy eksperymentalne/sezonowe - odrębne od praw.

Snippet (React):

tsx type Permission = string; // 'payout.approve', 'kyc.view_masked'
type Policy = { has:(p:Permission)=>boolean };
const PolicyCtx = React.createContext<Policy>({ has:()=>false });
export const Can: React.FC<{perm:Permission, children:React.ReactNode, fallback?:React.ReactNode}>
= ({perm, children, fallback=null}) => {
const { has } = React.useContext(PolicyCtx);
return has(perm)? <>{children}</>: <>{fallback}</>;
};

6) Serwer> Klient

Każde działanie jest potwierdzane przez serwer za pomocą tokenu ze znakami (rola, atrybuty).
Zasady są scentralizowane (PDP/OPA/Cedar/Zanzibar-like), interfejs użytkownika otrzymuje tylko rozwiązanie.
Wszystkie operacje krytyczne - potwierdzenie dwuskładnikowe + audyt.

7) Strefy maskujące i czerwone

Kategorie danych:

PII: imię i nazwisko, e-mail, telefon, adres, data urodzenia.
Finanse: portfele PAN/IBAN/krypto, kwoty, limity, salda bonusowe.
Dokumenty: paszporty/identyfikatory/selfie (KYC).
Gry: Historia zakładów/wygrane/wzory.

Zasady wyświetlania:

Pełnoprawny właściciel roli/płyty.
Maskowany - wsparcie, finanse (nie właściciel).
Zagregowane - Analityka (bez identyfikatorów).

Element maskujący:

tsx function Redact({text, perm}:{text:string, perm:Permission}){
const { has } = React.useContext(PolicyCtx);
return <span>{has(perm)? text: text.replace(/.(?=.{4})/g,'•')}</span>;
}

8) Zatwierdzenia i przepływy SoD

Cztery oczy. Inicjator.
Trasy wielostopniowe (na przykład kwoty> X → druga linia).
Ważność wniosków, SLA, eskalacja.
Magazyn: kto stworzył, kto się zmienił, kto zatwierdził, kiedy i skąd.

Przykłady: potwierdzenie wypłaty, zmiana limitów gracza, werdykt KYC, usunięcie flagi sankcji.

9) Specyfika iGaming

Ograniczenia i samodzielne wyłączenie: zmiana tylko za pomocą SoD i obowiązkowego powiadomienia użytkownika.
KYC/AML: dostęp do dokumentów - wąska rola; podgląd miniatur, pełny rozmiar - przez oddzielną akcję z dziennikiem.
Sankcje/flagi RAP: widoczne dla zespołu ds. ryzyka; wsparcie - tylko status „need verification”.
Płatności/Produkty: Post/Reject - Tylko rola rachunkowości finansowej; kwoty powyżej progu - podwójne potwierdzenie.
Dzienniki zakładów: Wsparcie czyta, ale nie edytuje; korekty - odrębna funkcja z dochodzeniem.

10) Lokalizacja, A11y, RTL

Teksty „bez dostępu” są zlokalizowane i zawierają ważne ścieżki (aplikacja/szkolenie).
Kontrola ostrości: nie przenoś użytkownika na „pustą” stronę bez wyjaśnienia.
Tryb RTL jest obsługiwany dla ról w odpowiednich regionach.
A11y: 'aria-disabled' + wyjaśnienie, dostępność eskalacji klawiatury.

11) Warunki i błędy

403 (Niekwalifikowalny): Przyjazna strona z kontekstem ról i CTA „Request Access”.
404 (bez zasobów): nie ujawniają istnienia ukrytych obiektów.
413/422 (zbyt wiele/walidacja): nie wyciekać szczegółów polityki, sformułować neutralnie.
Wartości graniczne/zamki: Wyjaśnić stan zegara/odblokowania.

12) Metryka

Dostęp Denied Rate: wskaźnik awarii według roli/ekranu (zły sygnał IA lub polityka).
Homologacja SLA: mediana czasu homologacji według przepływu (moc wyjściowa, wartości graniczne, KYC).
Maska ujawnić zdarzenia: PII „ujawnić” tempo (spodziewane małe i uzasadnione).
Błąd w rozdzielczości: czas od 403 do przyznanego dostępu.
Least-Privilege Drift: role o zbędnych prawach (wykrywalność przy użyciu).

13) Anty-wzory

Ukryj błędy pod „nic się nie stało”.
Pokaż puste przyciski bez wyjaśnienia.
Zamaskować właściciela własnymi danymi.
Polegaj na strażnikach interfejsu użytkownika bez zasad serwera.
Wymieszać ficheflagi z dostępami (różne zadania).
Podaruj „tryb Boga” dla wygody.

14) Żetony systemu projektowania (przykład)

json
{
"access": {
"badge": { "viewer":"#607D8B", "editor":"#4CAF50", "approver":"#FF9800", "admin":"#9C27B0" },
"lockColor": "#9E9E9E",
"maskChar": "•"
},
"states": {
"noAccess": { "bg":"var(--bg-elev)", "border":"var(--border)", "icon":"#9E9E9E" },
"approval": { "pending":"#FFC107", "approved":"#4CAF50", "rejected":"#F44336" }
},
"a11y": { "ariaDisabled": true, "explainDenial": true }
}

15) Snippets UI

Straż drogowa:

tsx import { Navigate, Outlet } from 'react-router-dom';
function GuardedRoute({perm}:{perm:Permission}){
const { has } = React.useContext(PolicyCtx);
if (has(perm)) return <Outlet/>;
return <Navigate to={`/403?perm=${encodeURIComponent(perm)}`} replace/>;
}

Brak karty dostępu z CTA:

html
<article class="no-access">
<h3>Недостаточно прав</h3>
<p>Доступ к разделу «Выплаты» доступен ролям: Финансы/Админ.</p>
<button class="btn" data-open-request>Запросить доступ</button>
</article>

Dziennik audytu (skrócony):

json
{
"ts": "2025-11-03T18:45:12Z",
"actor": "u_5412",
"action": "payout.approve",
"target": "withdraw#w_91822",
"ip": "194...12",
"result": "success"
}

16) Lista kontrolna QA

Nawigacja i IA

Niedostępne sekcje nie powodują hałasu w menu.
Istnieją wyraźne strony/karty „bez dostępu” z CTA.

Działania i straże

Przyciski bez praw - „wyłączony” + podpowiedź/tekst.
Chronione korzenie; bezpośredni adres URL → 403 z wyjaśnieniem.
Serwer potwierdza każdą akcję.

Dane

PII/PAN/KYC są maskowane przez politykę.
Dzienniki „ujawnień” są pisane i przeglądane.
Eksport/sprawozdania odpowiadają roli (agregaty do analizy).

SoD/Zatwierdzenia

Inicjator nie może zatwierdzić swojego wniosku.
Kwoty progowe → trasy wielostopniowe.

А11у/Localization

„Brak dostępu” jest zlokalizowany; nawigacja klawiatury działa.
Pierścienie kontrastu/ostrości odpowiadają AA.

Niezawodność

Pamięć podręczna pozwolenia z krótkim TTL; niepełnosprawność podczas zmiany ról.
PDP drop → interfejs użytkownika jest w trybie domyślnie bezpiecznym.

17) Dokumentacja w systemie projektowym

Кобонента: „GuardedRoute”, „Can”, „NoZ Card”, „ Banner”, „Redact”.
Zasady: macierz roli/działania, zasady SoD, poziomy maskowania.
Proces: żądanie dostępu, szkolenie/certyfikacja ról, weryfikacja praw raz na tydzień N.
Do/Don gallery: „puste przyciski bez powodu”, „przebranie do właściciela”, „UI bez kontroli serwera” vs „wyjaśnione ograniczenia i CTA”.

Krótkie podsumowanie

Interfejsy ról to jasna architektura informacji + ścisła polityka + przyjazne wyjaśnienia. Pokaż tylko to, czego potrzebujesz, maskować wrażliwe dane, chronić trasy i działania ze strażnikami, rejestrować każde krytyczne zdarzenie w audycie i podzielić się obowiązkami, gdzie wpływa na pieniądze i zgodność. W iGaming, to nie tylko zmniejsza ryzyko, ale również sprawia, że zespoły szybciej i spokojniej.

Interfejsy według roli i dostępu

Nawigacja i IA

Działania i straże

Dane

SoD/Zatwierdzenia

Niezawodność

Krótkie podsumowanie

Skontaktuj się z nami

Szybki kontakt

Wideo zostanie wkrótce zaktualizowane

Obecnie jesteśmy bardzo zajęci projektami