Interfețe după rol și acces

1) Principii

1. Securitate = UX sarcină. Utilizatorul trebuie să înțeleagă în mod clar ce poate și ce nu poate face fără „zone gri”.
2. Drepturi minime necesare. De la afișare la acțiuni, totul este limitat la sarcini de rol.
3. Semnal în loc de ban. Dacă nu există acces, vă explicăm de ce și cum să obțineți (cerere, cerere, instruire).
4. Duplicare pe server. Gărzile UI nu înlocuiesc niciodată cecurile serverului.
5. Audit transparent. Fiecare acțiune sensibilă lasă un semn ușor de citit.

2) Modele de control al accesului

RBAC (Role-Based): roluri fixe: Jucător, Suport, Finanțe, Risc/Conformitate, Manager Afiliat, Moderator, Admin.
ABAC (Atribute-Based): politica bazată pe atribute (jurisdicție, marcă, fus orar, nivel VIP, echipă, schimbare).
ReBAC (Relation-Based): acces prin relație (handler jucător, titular de bilet, manager partener).
SoD (Segregarea taxelor) - separarea sarcinilor critice (create ≠ aprobate).

Practică: RBAC ca bază, ABAC pentru reglaj fin (brand/regiune), SoD pentru finanțe/limite, ReBAC - punct (portofolii curate).

3) Funcția hartă după rol (exemplu iGaming)

4) Modele UX pentru drepturi și roluri

4. 1 Navigare și vizibilitate

Ascundeți secțiuni inaccesibile din navigație (reducerea zgomotului), dar afișați carduri informaționale „goale” dacă acest lucru ajută la înțelegerea posibilităților.
Pentru temporar indisponibil - „Blocare” cu un indiciu: motiv, cerințe, CTA „Cerere de acces”.

4. 2 Stări de acțiune

Dezactivat + tooltip: "Rolul financiar necesar. Cerere de acces.
Mod read-only: câmpurile „sub sticlă”, un marker explicit „Read-only”.
Escaladare - Faceţi clic pe Trimitere pentru aprobare în loc să aplicaţi.

4. 3 Mascare și editare

PII (e-mail, telefon, adresa) - „user @”., „+ 380 90” pentru înregistrările altor persoane.
PAN/IBAN - numai jetoane/ultimele 4.
Afișați butonul radio complet - deținerea rolului numai/prin eveniment de audit.

5) Arhitectura permisiunii în UI

Contextul de politică privind clientul: permisiunea cache (scurt TTL) + abonament la actualizări.
Gărzi de traseu: rutele inaccesibile → 403 pagini cu explicație și CTA.
Component guards: 'Can ({action:' approve _ within ', resource:' payout '})'.
Ficheflags: lucruri experimentale/sezoniere - separate de drepturi.

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) Server> Client

Orice acțiune este confirmată de server printr-un token cu semne (rol, atribute).
Politicile sunt centralizate (PDP/OPA/Cedar/Zanzibar-like), UI primește doar soluția.
Toate operațiunile critice - confirmare cu doi factori + audit.

7) Zonele de mascare și de date roșii

• PII: nume, e-mail, telefon, adresa, data nașterii.
• Finanțe: portofele PAN/IBAN/cripto, sume, limite, solduri bonus.
• Documente: pașapoarte/ID/selfie (KYC).
• Gaming: Istoria pariurilor/câștiguri/modele.

• Deținerea integrală a rolului/înregistrării.
• Mascat - sprijin, finanțe (nu proprietar).
• Agregate - Analytics (fără ID-uri).

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) Aprobări și fluxuri SoD

Patru ochi: iniţiatorul ≠ aprobatorul.
Rute multietajate (de exemplu, sume> X → linia a doua).
Valabilitatea aplicațiilor, SLA, escaladarea.
Revista: cine a creat, cine a schimbat, cine a aprobat, când și de unde.

Exemple: confirmarea retragerii, modificarea limitelor jucătorilor, verdictul KYC, eliminarea pavilionului de sancțiune.

9) Specificul iGaming

Limite și auto-excludere: se modifică numai cu SoD și notificarea obligatorie a utilizatorului.
KYC/AML: acces la documente - rol restrâns; previzualizarea miniaturilor, dimensiunea completă - printr-o acțiune separată cu jurnalul.
Sancțiuni/steaguri RAP: vizibile pentru echipa de risc; suport - numai statutul „nevoie de verificare”.
Plăți/Ieșiri: Post/Respingere - Numai rol de Contabilitate Financiară; sume peste prag - dublă confirmare.
Jurnale de pariuri: Suportul citește, dar nu editează; ajustări - o funcție separată cu investigație.

10) Localizare, A11y, RTL

Textele „fără acces” sunt localizate și conțin căi valide (aplicație/training).
Controlul focalizării: nu transferați utilizatorul într-o pagină „goală” fără explicații.
Modul RTL este acceptat pentru roluri în regiunile respective.
A11y: 'aria-dezactivat' + explicație, disponibilitate de escaladare a tastaturii.

11) Condiții și erori

403 (Ineligibil): Pagina prietenoasă cu contextul rolurilor și CTA "Request Access'.
404 (nici o resursă): nu dezvăluie existența obiectelor ascunse.
413/422 (prea mult/validare): nu scurgeți detalii de politică, formulați neutru.
Rate-limite/încuietori: Explicați starea cronometrului/deblocării.

12) Măsurători

Rata de acces refuzat: rata de eșec de rol/ecran (IA rău sau semnal de politică).
Aprobarea SLA: timpul median de aprobare prin debit (ieșire, limite, KYC).
Masca dezvăluie evenimente: PII „dezvăluie” rata (de așteptat mici și justificate).
Eroare la rezoluție: timpul de la 403 la accesul acordat.
Cel mai puțin privilegiat Drift: roluri cu drepturi redundante (detectabilitate prin utilizare).

13) Anti-modele

Ascunde erorile sub „nu s-a întâmplat nimic”.
Afișați butoanele goale fără explicații.
Masca proprietarul cu propriile date.
Bazați-vă pe gărzi UI fără politici de server.
Se amestecă ficheflags cu accesele (sarcini diferite).
Acordați sprijinul „modul zeu” de dragul comodității.

14) Proiectarea tokenurilor sistemului (exemplu)

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) Fragmente UI

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/>;
}

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

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

16) Lista de verificare QA

Navigare și IA

• Secțiunile indisponibile nu fac zgomot în meniu.
• Există clare „nici un acces” pagini/carduri cu CTA.

Acțiuni și gărzi

• Butoane fără drepturi - 'dezactivat' + tooltip/text.
• Rutele protejate; URL-ul direct → 403 cu o explicație.
• Serverul confirmă fiecare acțiune.

Date

• PII/PAN/KYC sunt mascate de politică.
• Jurnalele de „dezvăluiri” sunt scrise și revizuite.
• Exportul/Rapoartele corespund rolului (agregate pentru analiză).

SoD/Aprobări

• Inițiatorul nu poate aproba cererea sa.
• Cantități de prag → rute multietajate.

А11у/Localization

• „Nici un acces” este localizat; lucrări de navigare tastatură.

Inelele de contrast/focalizare corespund AA.

Fiabilitate

• Permisiunea cache cu scurt TTL; handicap atunci când se schimbă rolurile.
• PDP drop → UI este în mod implicit-safe.

17) Documentația în sistemul de proiectare

Компоненты: 'GuardedRoute', 'Can', 'NoAccessCard',' ApprovedBanner ',' Redact '.
Politici: matrice de rol/acțiune, reguli SoD, niveluri de mascare.
Proces: cerere de acces, instruire/certificare a rolurilor, revizuirea drepturilor o dată la fiecare N săptămâni.
Do/Don' t gallery: „butoane goale fără nici un motiv”, „deghizare la proprietar”, „UI fără verificarea serverului” vs „restricții explicate și CTA”.

Scurt rezumat

Interfețele de rol sunt arhitectura informațională clară + politici stricte + explicații prietenoase. Afișați numai ceea ce aveți nevoie, mascați datele sensibile, protejați rutele și acțiunile cu gardienii, înregistrați fiecare eveniment critic în audit și partajați responsabilitățile în cazul în care afectează banii și conformitatea. În iGaming, acest lucru nu numai că reduce riscurile, ci și face echipele mai rapide și mai calme.