角色和可用性接口

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示例）

章節	玩家	薩波特	財務	合規性/風險	附屬機構	阿德明
配置文件/限制	（他的）	R/W（應要求）	R	R/W（*）R	R
付款（存款/結算）	（他的）	R	R/W（舉行）	R/W (freeze/hold)	R	R
CUS/文件	（他的）	R（部分面具。）R（maskir。）R/W（判決）	—	R
投註/歷史	（他的）	R	R	R	—	R
促銷/獎金	R/W（累積）	—	R	R/W（合作夥伴）	R
用戶	—	R（按滴答聲）	—	R	R（合作夥伴）	R/W
R是讀數，W是條目。掩蔽是通過數據策略（PII/PAN/KYC）進行的。

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：實驗/季節性的東西-與權利分開。

Snippet（React）：

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

CTA的「無法訪問」卡：

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中，它不僅降低了風險，而且使團隊的工作更快，更安靜。

角色和可用性接口

導航和IA

行動和警衛

數據

SoD/Approvals

可靠性

Компоненты: `GuardedRoute`, `Can`, `NoAccessCard`, `ApprovalBanner`, `Redact`.

簡短的摘要

與我們聯繫

快速聯繫

影片即將更新

我們目前正忙於各項專案