Interfaces de papel e acessibilidade

1) Princípios

1. Segurança = Tarefa UX. O usuário deve entender claramente o que pode e não pode fazer sem «zonas cinzentas».
2. Os direitos mínimos necessários. Desde a exibição até as ações - tudo está restrito às tarefas do papel.
3. Sinal em vez de proibição. Se não tiver acesso, explicamos o porquê e como obter (solicitação, solicitação, treinamento).
4. Duplicação no servidor. Os guardas UI nunca substituem as verificações de servidores.
5. Auditoria transparente. Cada ação sensível deixa uma marca legível.

2) Modelos de controle de acesso

RBAC (Role-Based): Jogadores, Sapport, Finanças, Risco/Complaens, Assessor, Moderador, Admin.
ABAC (Attute-Based): política baseada em atributos (jurisdição, marca, fuso horário, nível VIP, comando, mudança).
ReBAC (Relationship-Based): acesso por relacionamento (supervisor de jogador, dono de tíquete, gerente de parceiro).
(Segregation of Duties): divisão de tarefas críticas (criou e aprovou).

Prática: RBAC como base, ABAC para configuração fina (marca/região), SoD para finanças/limites, ReBAC por pontos (carteiras supervisionadas).

3) Mapa de funções por papel (exemplo iGaming)

4) Pattern UX para direitos e papéis

4. 1 Navegação e visibilidade

Esconda as seções de navegação inacessíveis (redução de ruído), mas mostre os cartões de informação «em branco» se isso ajudar a entender as possibilidades.
Para temporariamente inacessível - «Cadeado», com a dica: razão, requisitos, CTA «Solicitar acesso».

4. 2 Estados de ação

Disabled + tooltip: "Precisa do papel Finanças. Pedir acesso".
Modo read-only: campos «debaixo do vidro», marcador explícito «Somente leitura».
Escalar: botão Enviar para aprovação em vez de Aplicar.

4. 3 Camuflagem e edição

PII (email, telefone, endereço) - 'user @', '+ 380 90' para registros de outros.
PAN/IBAN - Apenas os tokens/últimos 4.
O botão Mostrar completo é apenas para o dono do papel/evento de áudio.

5) Arquitetura de permissões em UI

Contexto de policy no cliente: kesh de permissões (TTL curto) + subscrição de atualizações.
Roteiros não acessíveis → página 403 com explicação e CTA.
Guardas de componentes: 'Can (' action: 'approve _ withdrawal', resource: 'payout') '.
Ficheflagi: coisas experimentais/sazonais - separadamente do direito.

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) Servidor> Cliente

Qualquer ação é confirmada por um servidor de token com marcas (rol, atributos).
As políticas são centralizadas (PDP/OPA/Cedar/Zanzibar-similares) e a UI recebe apenas uma solução.
Todas as operações críticas são confirmação de dois efeitos + auditoria.

7) Camuflagem e zonas de dados vermelhas

• PII: nome, email, telefone, endereço, data de nascimento.
• Finanças: PAN/IBAN/criptomoedas, somas, limites, balanços de bónus.
• Documentos: passaportes/ID/selfie (KYC).
• Jogos: histórico de apostas/ganhos/pattern.

• Completa - dona do papel/dono da gravação.
• Camuflado - safort, finanças (não dono).
• Agregado - Analista (sem 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) Fluxos de afirmação (Approvals) e SoD

Quatro olhos, um iniciador ≠ afirma.
Rotas múltiplas (por exemplo, somas> X → linha 2).
Data de validade, SLA, escalação.
Revista: Quem criou, quem mudou, quem aprovou, quando e de onde.

Exemplos: confirmação de saída, alteração dos limites do jogador, veredicto KYC, retirada da bandeira de sanções.

9) Especificidades iGaming

Limites e auto-exclusão: alteração somente com a notificação SoD e obrigatória do usuário.
KYC/AML: Acesso aos documentos - papel estreito; O pré-teste de miniaturas, a totalidade, por ação separada com o login.
Bandeiras de sanção/RER: A equipe de risco é visível; O Zapport só precisa de um teste.
Pagamentos/conclusões: «realizar/rejeitar» - apenas o papel Finanças; somas acima do limite - dupla confirmação.
Revistas de apostas: Zapport lê, mas não edita; os ajustes são uma função separada com investigação.

10) Localização, A11y, RENAULT

Os textos «sem acesso» são localizados e contêm caminhos válidos (solicitação/treinamento).
Controle de foco: não transferir o usuário para uma página «vazia» sem explicações.
O modo se mantém para papéis nas respectivas regiões.
A11y: 'aria-disabled' + explicação, disponibilidade do teclado de escalação.

11) Estados e erros

403 (sem permissão): página amigável com contexto de papel e CTA «Pedir acesso».
404 (sem recurso): não revelar a existência de objetos ocultos.
413/422 (demasiado/validação): não fundir os detalhes da política, formule de forma neutra.
Rate-limits/bloqueio: explique o tempo/condição de desbloqueio.

12) Métricas

Access Denied Rate: proporção de falhas de papel/ecrã (sinal de mau IA ou política).
Approval SLA: Mediana do tempo de aprovação por fluxo (saída, limites, KYC).
Mask Reveal Events: Taxa de «divulgação» PII (esperada pequena e razoável).
Error-to-Resolution: tempo entre 403 e acesso emitido.
Least-Privilege Drift: papéis com excesso de permissões (detecção de uso).

13) Anti-pattern

Esconder o erro de «nada aconteceu».
Mostrar botões vazios sem explicação.
Disfarçar o dono dos seus próprios dados.
Contar com guardas UI sem políticos de servidores.
Misture os fichicheflags com acessíveis (diferentes tarefas).
Dar a saforta «god-modo» por conveniência.

14) Sistema de design de tokens (exemplo)

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

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) QA-folha de cheque

Navegação e IA

• As seções não disponíveis não fazem barulho no menu.
• Há páginas compreensíveis/cartões «sem acesso» com CTA.

Ações e guardas

• Botões sem permissão - 'disabled' + tooltip/texto.
• Rotas protegidas; URL direto → 403 com explicação.
• O servidor confirma cada ação.

Dados

• PII/PAN/KYC são camuflados por política.
• Os logs de «divulgação» são escritos e revoltados.
• Exportação/relatórios correspondem ao papel (agregados para analistas).

SoD/Approvals

• O iniciador não pode aprovar sua candidatura.
• Os limites → rotas múltiplas.

A11u/Localização

• «Sem acesso» foi localizado; a navegação por teclado funciona.
• Contraste/anéis de foco correspondem a AA.

Confiabilidade

• Permissões com TTL curto; deficiência na mudança de papel.
• A queda do PDP → UI funciona em «default seguro».

17) Documentação em design

Компоненты: `GuardedRoute`, `Can`, `NoAccessCard`, `ApprovalBanner`, `Redact`.
Políticas: matriz de papéis/ações, regras SoD, níveis de camuflagem.
Processo: solicitação de acesso, treinamento/certificação de papéis, revisão de permissões a cada N semanas.
Do/Don 't galeria: «botões vazios sem razão», «disfarçar o proprietário», «UI sem verificação de servidor» vs «restrições explicadas e CTA».

Resumo breve

Interfaces de rolo são uma arquitetura de informação compreensível, mais políticas rigorosas, mais explicações amigáveis. Mostre apenas o que deseja, disfarce os dados sensíveis, proteja as rotas e as ações dos guardas, identifique cada evento crítico na auditoria e divida as responsabilidades onde isso afeta o dinheiro e a complacência. No iGaming, não só reduz os riscos, mas também torna o trabalho das equipes mais rápido e mais tranquilo.