Interfaces par rôle et accès

1) Principes

1. Sécurité = tâche UX. L'utilisateur doit comprendre clairement ce qu'il peut et ne peut pas faire, sans les « zones grises ».
2. Un minimum de droits nécessaires. De l'affichage aux actions - tout est limité aux tâches du rôle.
3. Un signal au lieu d'une interdiction. S'il n'y a pas d'accès, expliquez pourquoi et comment obtenir (demande, demande, formation).
4. Duplication sur le serveur. Les gardes UI ne remplacent jamais les vérifications de serveur.
5. Audit transparent. Chaque action sensible laisse une trace lisible.

2) Modèles de contrôle d'accès

RBAC (Role-Based) : Rôles fixes : Joueur, Sapport, Finances, Risque/Conformité, Gestionnaire d'affiliation, Modérateur, Admin.
ABAC (Attribute-Based) : politique basée sur les attributs (juridiction, marque, fuseau horaire, niveau VIP, équipe, changement).
ReBAC (Relationship-Based) : accès par relation (superviseur du joueur, propriétaire du tiquet, gestionnaire du partenaire).
SoD (Segregation of Duties) : division des tâches critiques (créé ≠ approuvé).

Pratique : RBAC en tant que base, ABAC pour la finesse (marque/région), SoD pour les finances/limites, ReBAC - point (portfolios supervisés).

3) Carte des fonctions par rôle (exemple iGaming)

4) Modèles UX pour les droits et les rôles

4. 1 Navigation et visibilité

Cachez les sections inaccessibles de la navigation (réduction du bruit), mais montrez les cartes « vides » d'information si cela vous aide à comprendre les possibilités.
Pour temporairement inaccessible - « Château » avec un conseil : raison, exigences, CTA « Demander l'accès ».

4. 2 États d'action

Disabled + tooltip : "Il faut un rôle Finance. Demander l'accès".
Mode de lecture uniquement : champs « sous le verre », marqueur explicite « Lecture seule ».
Escalade : bouton Envoyer pour approbation au lieu d'Appliquer.

4. 3 Masquage et édition

PII (courriel, téléphone, adresse) - 'user @.', '+ 380 90' pour les enregistrements des autres.
PAN/IBAN - seulement les tokens/les 4 derniers.
Le bouton « Afficher complètement » est uniquement pour le rôle propriétaire/par événement avec l'audit.

5) Architecture des autorisations dans l'IU

Contexte de politique sur le client : cache d'autorisation (TTL court) + abonnement aux mises à jour.
Garde-route : Roots inaccessibles → 403-page avec explication et CTA.
Garde des composants : 'Can ({action :' approve _ withdrawal ', resource :' payout '})'.
Ficheflagi : choses expérimentales/saisonnières - séparées des droits.

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

Toute action est confirmée par le serveur par un jeton avec des marques (rôle, attributs).
Les politiques sont centralisées (PDP/OPA/Cedar/Zanzibar-similaires), l'IU n'obtient que la solution.
Toutes les opérations critiques - confirmation à deux facteurs + audit.

7) Masquage et zones de données rouges

• PII : nom, courriel, téléphone, adresse, date de naissance.
• Finances : PAN/IBAN/cryptocoques, montants, limites, soldes bonus.
• Documents : passeports/ID/selfie (KYC).
• Jeu : historique des paris/gains/schémas.

• Complet - propriétaire du rôle/propriétaire de l'enregistrement.
• Masqué - sapport, finances (pas propriétaire).
• Agrégé - analyse (sans identifiants).

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) Flux d'allégations (Approvals) et SoD

Quatre yeux : l'initiateur ≠ l'approbateur.
Itinéraires en plusieurs étapes (par exemple, montants> X → ligne 2).
Durée des demandes, SLA, escalade.
Magazine : qui a créé, qui a changé, qui a approuvé, quand et d'où.

Exemples : confirmation de retrait, modification des limites du joueur, verdict de KYC, retrait du drapeau de sanction.

9) Spécificité iGaming

Limites et auto-exclusion : changement uniquement avec SoD et notification obligatoire à l'utilisateur.
KYC/AML : l'accès aux documents est un rôle étroit ; prévisualisation des miniatures, pleine mesure - par action séparée avec la loge.
Les sanktsionnye/rer-drapeaux : sont visibles au risque-équipe; Sapport - seul le statut « besoin de vérification ».
Paiements/conclusions : « effectuer/rejeter » - uniquement le rôle des Finances ; les montants supérieurs au seuil sont une double confirmation.
Journaux de paris : Sappport lit mais ne édite pas ; les ajustements sont une fonction distincte avec l'enquête.

10) Localisation, A11y, RTL

Les textes « pas d'accès » sont localisés et contiennent les voies d'accès en vigueur (demande/formation).
Contrôle de mise au point : ne pas déplacer l'utilisateur vers une page « vide » sans explication.
Le mode RTL est pris en charge pour les rôles dans les régions concernées.
A11y : 'aria-disabled' + explication, accessibilité clavier de l'escalade.

11) États et erreurs

403 (aucun droit) : page amicale avec le contexte du rôle et le CTA « Demander l'accès ».
404 (aucune ressource) : ne pas révéler l'existence d'objets cachés.
413/422 (trop/validation) : ne pas fusionner les détails de la politique, formuler de manière neutre.
Taux-limites/verrous : expliquez la minuterie/condition de déverrouillage.

12) Métriques

Taux de refus d'accès : proportion de défaillances par rôle/écran (signal de mauvaise IA ou politique).
Approval SLA : temps médian d'approbation par flux (sortie, limites, KYC).
Mask Reveal Events : Fréquence des « divulgations » de PII (peu attendue et justifiée).
Error-to-Resolution : temps entre 403 et l'accès émis.
Least-Privilège Drift : rôles redondants (détail d'utilisation).

13) Anti-modèles

Cacher les erreurs sous « rien ne s'est passé ».
Afficher les boutons vides sans explication.
Masquer au propriétaire ses propres données.
Comptez sur les gardiens de l'IU sans politiques de serveur.
Mélanger les ficheflags avec les accès (tâches différentes).
Donner le sappart « mode dieu » pour plus de commodité.

14) Tokens de système de conception (exemple)

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) Snappets 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) Liste de vérification QA

Navigation et IA

• Les sections inaccessibles ne font pas de bruit dans le menu.
• Il y a des pages/cartes « non accessibles » compréhensibles avec la LTC.

Actions et gardes

• Les boutons sans droits sont 'disabled' + tooltip/texte.
• Les routes sont protégées ; URL directe → 403 avec explication.
• Le serveur confirme chaque action.

Données

• Les PII/PAN/KYC sont masqués par la politique.
• Les logs des « révélations » sont écrits et revus.
• Les exportations/rapports correspondent au rôle (agrégats pour l'analyse).

SoD/Approvals

• Le promoteur ne peut approuver sa demande.
• Montants seuils → itinéraires à étapes multiples.

A11u/Localisation

• « Aucun accès » est localisé ; la navigation au clavier fonctionne.
• Les anneaux de contraste/focus correspondent à AA.

Fiabilité

• Cache d'autorisation avec une TTL courte ; invalidité en cas de changement de rôle.
• Chute de PDP → UI fonctionne en mode « défaut-sûr ».

17) Documentation dans le système de conception

Компоненты: `GuardedRoute`, `Can`, `NoAccessCard`, `ApprovalBanner`, `Redact`.
Stratégies : matrice des rôles/actions, règles SoD, niveaux de masquage.
Processus : demande d'accès, formation/certification des rôles, révision des droits une fois toutes les N semaines.
Do/Don't-gallery : « boutons vides sans raison », « masquage au propriétaire », « UI sans vérificateurs de serveur » vs « restrictions expliquées et CTA ».

Résumé succinct

Les interfaces de rôle sont une architecture d'information compréhensible + des politiques strictes + des explications amicales. Montrez seulement le bon, masquez les données sensibles, protégez les itinéraires et les actions des gardes, enregistrez chaque événement critique dans l'audit et partagez les responsabilités là où cela affecte l'argent et la conformité. Dans iGaming, non seulement cela réduit les risques, mais aussi rend le travail des équipes plus rapide et plus calme.