角色和可用性接口
1）原则
1.安全=UX任务。用户必须清楚地了解自己可以在没有"灰色区域"的情况下做什么，也无法做什么。
2.最低要求的权利。从显示到动作-一切都受角色任务的限制。
3.信号代替禁令。如果没有访问-我们解释为什么以及如何获取（请求、申请、培训）。
4.服务器上的复制。UI后卫永远不会取代服务器检查。
5.透明审计。每个敏感动作都会留下可读的痕迹。
2）访问控制模型
RBAC（基于角色）：固定角色：球员，萨波特，财务，风险/合规性，附属经理，主持人，Admin。
ABAC（基于属性的）：基于属性的策略（管辖权，品牌，时区，VIP级别，命令，更改）。
ReBAC（关系基础）：关系访问（玩家策展人，tiket所有者，合作伙伴经理）。
SoD （Segregation of Duties）：共享关键任务（创建≠批准）。
实践：RBAC作为基础，ABAC用于微调（品牌/地区），SoD用于财务/限额，ReBAC-点点（可监督投资组合）。
3）按角色绘制功能图（iGaming示例）
4）权利和角色的UX模式
4.1导航和可见性
从导航中隐藏无法访问的部分（减少噪音）,但显示信息"空白"卡,如果这有助于了解可能性。
对于暂时无法访问的-带有提示的"锁"：原因，要求，CTA"请求访问"。
4.2行动状态
Disabled+tooltip： "需要财务角色。请求访问。"
只读模式："玻璃下"字段,显式标记"仅读"。
升级："提交批准"按钮而不是"应用"按钮。
4.3蒙版和编辑
PII（电子邮件，电话，地址）-"user@"，"+380 90"用于其他人的记录。
PAN/IBAN-仅令牌/最新4。
"完全显示"单选按钮仅适用于具有审核功能的角色/事件。
5） UI中的权限体系结构
客户端上的策略上下文：权限小键（TTL短）+更新订阅。
路线卫士：路线不可用→ 403页解释和CTA。
组件守卫："can（{action：'approve_withdrawal'，资源：'payout'}）"。
Ficheflagi：实验/季节性的东西-与权利分开。
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）服务器>客户端
任何操作均由服务器通过带有标签（角色，属性）的令牌确认。
策略集中（PDP/OPA/Cedar/Zanzibar等），UI仅获得解决方案。
所有关键操作都是双因素确认+审核。
7）掩码和红色数据区域
数据类别：- PII：姓名，电子邮件，电话，地址，出生日期。
- 财务：PAN/IBAN/密码钱包，金额，限额，奖金余额。
- 文件：护照/ID/自拍照（KYC）。
- 游戏：投注/获胜/模式的历史记录。
- 完整-拥有角色/记录所有者。
- 蒙面-萨波特，金融（非所有者）。
- 聚合-分析（没有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）声明流（Approvals）和SoD
四只眼睛：发起人≠批准者。
多步路线（例如，总和>X →第二行）。
申请到期，SLA，升级。
杂志：是谁创建的，谁修改了，谁批准了，何时何地。
例如：确认退出，更改玩家限制，KYC判决，取消制裁标志。
9） iGaming的细节
限制和自我体验：仅使用SoD和强制用户通知进行更改。
KYC/AML：访问文档-狭义角色；预览一个缩略图,通过一个单独的动作与一个日志。
制裁/RER旗帜：风险团队可见；sapport-只有"需要验证"状态。
付款/结论："进行/拒绝"-仅作为财务角色；超过阈值的金额是双重确认。
投注日志：sapport阅读但不编辑；调整是一个单独的功能与调查。
10）本地化,A11y, RTL
"无法访问"文本是本地化的，并包含当前路径（申请/培训）。
焦点管理：不要在没有解释的情况下将用户迁移到"空白"页面。
RTL模式为各自地区的角色提供支持。
A11y： 'aria-disabled'+解释,键盘可升级。
11）状态和错误
403（无权）：具有角色上下文和CTA"请求访问"的友好页面。
404（无资源）：不透露隐藏对象的存在。
413/422（过多/验证）：不泄露政策细节，中立表述。
速率限制/锁定：解释计时器/解锁条件。
12）度量标准
Access Denied Rate：按角色/屏幕划分的故障百分比（不良的IA或策略信号）。
Approval SLA：按线程划分的批准时间中点（输出，限制，KYC）。
Mask Reveal Events：PII的"披露"频率（预计较小且合理）。
错误解决：从403到已签发的访问时间。
Least-Privilege Drift：具有多余权限的角色（使用细节）。
13）反模式
在"什么都没发生"下隐藏错误。
显示空白按钮,无需解释。
伪装所有者自己的数据。
依靠没有服务器策略的UI后卫。
将ficheflagi与可用性混合（不同的任务）。
为了方便起见，给sapport一个"god-mode"。
14）设计系统令牌（示例）
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
路线Gward：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支票清单
导航和IA
- 无法访问的部分不会在菜单上发出噪音。
- CTA有清晰的页面/无访问卡。
行动和警卫
- 无权按钮-"disabled"+tooltip/文本。
- 路由器受到保护；直接URL → 403和解释。
- 服务器确认每个操作。
数据
- PII/PAN/KYC伪装成政策。
- "披露"的逻辑写作和咆哮。
- 导出/报告对应于角色（分析聚合）。
SoD/Approvals
- 发起人不能批准其申请。
- 阈值金额→多步路线。
A11u/本地化
- "无法访问"是本地化的；键盘导航工作正常。
- 对比/焦环对应于AA。
可靠性
- 具有短TTL许可证的Kesh；改变角色时致残。
- PDP → UI的下降在"默认安全"模式下运行。
17）设计系统中的文档
Компоненты: `GuardedRoute`, `Can`, `NoAccessCard`, `ApprovalBanner`, `Redact`.
策略：角色/活动矩阵，SoD规则，掩蔽级别。
流程：访问请求，角色培训/认证，每周N次权限审核。
Do/Do n't galler："没有理由的空白按钮"、"伪装所有者"、"没有服务器检查的UI" vs"解释的限制和CTA"。
简短的摘要
角色界面是一个清晰的信息体系结构+严格的政策+友好的解释。仅显示所需信息,掩盖敏感数据,保护警卫的路线和行动,在审计中捕捉每个关键事件,并在影响金钱和合规性的地方分担责任。在iGaming中，它不仅降低了风险，而且使团队的工作更快，更安静。