Interfacce per ruolo e accessibilità

1) Principi

1. Protezione = attività UX. L'utente deve capire chiaramente cosa può e non può fare senza «zone grigie».
2. Diritti minimi necessari. Dalla visualizzazione alle azioni, tutto è limitato alle attività del ruolo.
3. Un segnale invece di un divieto. Se non c'è accesso, spiegheremo perché e come ottenere (richiesta, richiesta, formazione).
4. Duplicazione sul server. Le guardie UI non sostituiscono mai i controlli sul server.
5. Controllo trasparente. Ogni azione sensibile lascia un segno leggibile.

2) Modelli di controllo d'accesso

RBAC (Rolle-Based) - Ruoli fissi: Giocatore, Sapport, Finanza, Rischio/Complaens, Affiliato Manager, Moderatore, Addin.
ABAC (Attrute-Based) - Criterio basato su attributi (giurisdizione, marchio, fuso orario, livello VIP, comando, cambio).
ReBAC (Relationship-Based) - Accesso alle relazioni (gestore del giocatore, proprietario del ticket, manager del partner).
SoD (Segregation of Duties) - Separa le attività critiche (ha creato il ≠).

Prassi: RBAC come base, ABAC per la configurazione sottile (marchio/regione), SoD per la finanza/limiti, ReBAC-puntuale (portafogli supervisionati).

3) Mappa delle funzioni per ruolo (esempio iGaming)

4) pattern UX per diritti e ruoli

4. 1 Navigazione e visibilità

Nascondere le partizioni non disponibili dalla navigazione (riduzione del rumore), ma visualizzare le schede «vuote» delle informazioni se questo consente di comprendere le funzionalità.
Per temporaneamente inaccessibile - Serratura con suggerimento: motivo, requisiti, CTA Richiedi accesso.

4. 2 Stati attività

Disabled + tooltip: "È necessario il ruolo Finanza. Richiedi l'accesso".
Modalità read-only: campi sotto il vetro, indicatore esplicito Solo lettura.
Escalation: il pulsante Invia per l'approvazione invece di Applica.

4. 3 Maschera e modifica

PII (email, telefono, indirizzo) è «user @», «+ 380 90» per le voci degli altri.
PAN/BAN - solo token/ultimi 4.
Il pulsante di scelta Mostra completamente è solo per il ruolo proprietario/per l'evento con l'udienza.

5) Architettura delle autorizzazioni in UI

Contesto policy su client: crash di autorizzazioni (TTL breve) + sottoscrizione di aggiornamenti.
Scorse rotte non disponibili: pagina 403 con spiegazione e CTA.
Guardie dei componenti: 'Can ({action:' approve _ withdrawal ', resource:' payout '})'.
Le cose sperimentali/stagionali sono separate dai diritti.

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

Ogni azione viene confermata da un server di token marcato (ruolo, attributi).
I criteri sono centralizzati (PDP/OPA/Cedar/Zanzibar-simili) e la UI ottiene solo una soluzione.
Tutte le operazioni critiche sono conferma a due fattori + verifica.

7) Masking e aree dati rosse

• Nome, email, telefono, indirizzo, data di nascita.
• Finanza: PAN/BAN/crittomellette, importi, limiti, bilanci bonus.
• Documenti passaporti/ID/selfie (KYC).
• Giochi: storia di scommesse/vincite/pattern.

• Completo - proprietario del ruolo/proprietario della registrazione.
• Mascherato - zapport, finanza (non proprietario).
• Aggregato - Analista (senza ID).

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) Flussi di approvazione (Approvals) e SoD

Quattro occhi, l'iniziatore è un sostenitore.
Percorsi multipli (ad esempio, importi> X → linea 2).
La scadenza delle iscrizioni, la SLA, l'escalation.
Chi ha creato, chi ha cambiato, chi ha approvato, quando e da dove.

Esempi: conferma dell'output, modifica dei limiti del giocatore, verdetto KYC, rimozione del flag.

9) Specificità del iGaming

Limiti e auto-esclusione: modifica solo con notifica utente obbligatoria e SoD.
KYC/AML - Accesso ai documenti - ruolo ristretto; anteprima delle miniature, full-time, per azione separata con il tubo.
Flag di sanzione/RER: è visibile il comando di rischio; Lo zappone è solo uno stato di prova.
Pagamenti/conclusioni: «effettuare/rifiutare» - solo il ruolo della Finanza; l'importo superiore alla soglia è una doppia conferma.
Riviste di scommesse: zapport legge ma non modifica; gli aggiustamenti sono una funzione separata con un'indagine.

10) Localizzazione, A11y, RTL

I testi «senza accesso» sono localizzati e contengono percorsi validi (richiesta/formazione).
Gestione dell'attivazione: non trasferire l'utente a una pagina vuota senza spiegazioni.
La modalità RTL è supportata per i ruoli nelle regioni interessate.
A11y: «aria-disabled» + spiegazione, disponibilità della tastiera di ingrandimento.

11) Stati e errori

403 (nessun diritto): pagina amichevole con contesto ruolo e CTA Richiesta accesso.
404 (nessuna risorsa) - Non rivelare l'esistenza di oggetti nascosti.
413/422 (troppo/convalida): non filtrare i dettagli della politica, formulare in modo neutro.
Rate-limits/blocco - Spieghi timer/condizione di sblocco.

12) Metriche

Access Denied Rate - Percentuale di guasti per ruolo/schermata (segnale di errore IA o criterio).
Approval SLA - Tempo medio di approvazione per flusso (output, limiti, KYC).
Mask Reveal Events: frequenza di «scoperte» PII (prevedibilmente ridotta e ragionevole).
Errore-to-Resolution: tempo compreso tra 403 e accesso concesso.
Least-Privilege Drivt - Ruoli con diritti ridondanti (Dettaglio di utilizzo).

13) Anti-pattern

Nascondere gli errori con «non è successo niente».
Mostra i pulsanti vuoti senza spiegazioni.
Mascherare il proprietario dei suoi dati.
Affidarsi a guard UI senza regole server.
Mescolare i ficcioflagi con le disponibilità (diverse attività).
Dare lo zappone «god-mode» per comodità.

14) Token di progettazione (esempio)

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) Snippet 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 assegni QA

Navigazione e IA

• Le partizioni non disponibili non fanno rumore nel menu.
• Ci sono pagine/schede di accesso comprensibili con CTA.

Azioni e guardie

• I pulsanti non autorizzati sono «disabled» + tooltip/testo.
• Le rotte sono protette; URL diretto 403 con spiegazione.
• Il server conferma ogni azione.

Dati

• PII/PAN/KYC sono mascherati per criterio.
• I loghi di rivelazione sono scritti e gelosi.
• L'esportazione/report corrisponde al ruolo (aggregazioni per gli analisti).

SoD/Approvals

• L'iniziatore non può approvare la richiesta.
• Le soglie contengono percorsi multipli.

A11u/Localizzazione

• Nessun accesso localizzato; la navigazione tastiera funziona.
• Gli anelli di contrasto/fuoco corrispondono a AA.

Affidabilità

• Autorizzazioni con TTL breve; invalidità al cambio di ruolo.
• Il calo del PDP dell'UI funziona in modalità default-sicuro.

17) Documentazione in progettazione

Компоненты: `GuardedRoute`, `Can`, `NoAccessCard`, `ApprovalBanner`, `Redact`.
Criteri: matrice di ruoli/azioni, regole SoD, livelli di occultamento.
Processo: richiesta di accesso, formazione/certificazione dei ruoli, revisione dei diritti ogni N settimane.
Do/Don't-gallery: «pulsanti vuoti senza motivo», «occultamento al proprietario», «UI senza controllo server» vs «vincoli spiegati e CTA».

Breve riepilogo

Interfacce di ruolo: architettura delle informazioni comprensibile, regole rigorose e spiegazioni amichevoli. Mostrate solo ciò che desiderate, mascherate i dati sensibili, proteggete le rotte e le azioni delle guardie, registrate ogni evento critico in un controllo e condividete le vostre responsabilità laddove ciò influisce sul denaro e sulla compilazione. Nel iGaming non solo riduce i rischi, ma rende il lavoro dei team più veloce e più tranquillo.