GH GambleHub

رابط های نقش و دسترسی

1) اصول

1. امنیت = وظیفه UX. کاربر باید به وضوح درک آنچه که او می تواند و نمی تواند بدون «مناطق خاکستری» انجام دهد.
2. حداقل حقوق لازم از نمایش به اقدامات، همه چیز محدود به وظایف نقش است.
3. سیگنال به جای ممنوعیت اگر دسترسی وجود نداشته باشد، ما توضیح می دهیم که چرا و چگونه (درخواست، درخواست، آموزش) دریافت کنید.
4. تکثیر در سرور نگهبانان UI هرگز جایگزین چک های سرور نمی شوند.
5. حسابرسی شفاف هر اقدام حساس یک علامت قابل خواندن را ترک می کند.


2) مدل های کنترل دسترسی

RBAC (مبتنی بر نقش): نقش های ثابت: بازیکن، پشتیبانی، امور مالی، ریسک/انطباق، مدیر وابسته، مدیر، مدیر.
ABAC (Attribute-Based): سیاست مبتنی بر ویژگی (صلاحیت، نام تجاری، منطقه زمانی، سطح VIP، تیم، تغییر).
ReBAC (مبتنی بر رابطه): دسترسی از طریق رابطه (گرداننده بازیکن، دارنده بلیط، مدیر شریک).
SoD (تفکیک وظایف) - تفکیک وظایف مهم (ایجاد ≠ تایید شده).

تمرین: RBAC به عنوان پایه، ABAC برای تنظیم خوب (نام تجاری/منطقه)، SoD برای امور مالی/محدودیت ها، ReBAC - نقطه (اوراق بهادار سرپرستی).


3) نقشه تابع توسط نقش (به عنوان مثال iGaming)

بخش هاپخش کنندهپشتیبانی از سایتامور مالیانطباق/ریسکشرکت های وابستهمدیر عامل
مشخصات/محدودیت ها(خود)R/W (در صورت درخواست)تحقیق و توسعهR/W (محدود) Rتحقیق و توسعه
پرداخت (سپرده/برداشت)(خود)تحقیق و توسعهR/W (ارسال)R/W (یخ/نگه دارید)تحقیق و توسعهتحقیق و توسعه
CMC/اسناد(خود)R (بخشی از ماسک) R (ماسک) R/W (حکم)تحقیق و توسعه
شرط بندی/تاریخچه(خود)تحقیق و توسعهتحقیق و توسعهتحقیق و توسعهتحقیق و توسعه
تبلیغات/پاداشR/W (شارژ)تحقیق و توسعهR/W (همکاران)تحقیق و توسعه
کاربران ماR (بلیط)تحقیق و توسعهR (همکاران)R/W
R - خواندن، W - نوشتن. پوشش - توسط سیاست داده (PII/PAN/KYC).

4) الگوهای UX برای حقوق و نقش ها

4. 1 ناوبری و دید

پنهان کردن بخش های غیر قابل دسترس از ناوبری (کاهش سر و صدا)، اما نشان می دهد کارت های اطلاعاتی «خالی» اگر این کمک می کند تا به درک امکانات.
برای موقت در دسترس نیست - «قفل» با یک اشاره: دلیل، الزامات، CTA «درخواست دسترسی».

4. ۲ کشورهای عمل

غیرفعال + نکته ابزار: "نقش مالی مورد نیاز است. درخواست دسترسی

حالت فقط خواندنی: فیلدهای «زیر شیشه»، نشانگر صریح «فقط خواندنی».
Escalation: روی Submit for Approval به جای Apply کلیک کنید.

4. 3 پوشش و ویرایش

PII (ایمیل، تلفن، آدرس) - 'user @.'، '+ 380 90' برای سوابق افراد دیگر.
PAN/IBAN - فقط نشانه ها/آخرین 4.
نمایش دکمه رادیویی کامل - داشتن نقش تنها/توسط رویداد حسابرسی.


5) معماری مجوز در UI

زمینه سیاست در مشتری: مجوز حافظه پنهان (TTL کوتاه) + اشتراک به روز رسانی.
نگهبانان مسیر: مسیرهای غیرقابل دسترس → صفحه 403 با توضیح و CTA.
محافظ کامپوننت: can ({action: 'approval _ within', resource: 'payout'}).
Ficheflags: چیزهای تجربی/فصلی - جدا از حقوق.

قطعه (واکنش):
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-like)، UI تنها راه حل را می گیرد.
تمام عملیات بحرانی - تایید دو عامل + حسابرسی.


7) پوشش و مناطق داده قرمز

دسته بندی داده ها:
  • PII: نام، ایمیل، تلفن، آدرس، تاریخ تولد.
  • امور مالی: کیف پول PAN/IBAN/رمزنگاری, مقدار, محدودیت, تعادل پاداش.
  • اسناد: گذرنامه/شناسه/سلفی (KYC).
  • بازی: تاریخ شرط بندی/برنده/الگوهای.
سیاست نمایش:
  • کامل - صاحب نقش/صاحب رکورد.
  • ماسک - پشتیبانی، مالی (نه مالک).
  • جمع آوری - تجزیه و تحلیل (بدون شناسه).
جزء پوشش:
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) مصوبات و جریان SoD

چهار چشم: آغازگر ≠ تأیید کننده.
مسیرهای چند مرحله ای (به عنوان مثال، مقادیر> X → خط دوم).
اعتبار برنامه ها، SLA، تشدید.
مجله: چه کسی ایجاد کرد، چه کسی تغییر کرد، چه کسی تأیید کرد، چه زمانی و از کجا.

مثالها: تأیید خروج، تغییر در محدودیت بازیکن، حکم KYC، حذف پرچم تحریم.


9) ویژگی های iGaming

محدودیت ها و خود حذفی: تغییر تنها با SoD و اطلاع رسانی کاربر اجباری است.
KYC/AML: دسترسی به سند - نقش باریک ؛ پیش نمایش از ریز عکسها، اندازه کامل - توسط یک عمل جداگانه با ورود به سیستم.
تحریم ها/پرچم های RAP: قابل مشاهده برای تیم ریسک ؛ پشتیبانی - فقط وضعیت «نیاز به تأیید».
پرداخت/خروجی: ارسال/رد - تنها نقش حسابداری مالی ؛ مقادیر بالاتر از آستانه - تایید دو برابر.
سیاهههای مربوط به شرط بندی: پشتیبانی می خواند اما ویرایش نمی کند ؛ تنظیمات - یک تابع جداگانه با تحقیقات.


10) محلی سازی، A11y، RTL

متون «بدون دسترسی» محلی هستند و حاوی مسیرهای معتبر (برنامه/آموزش) هستند.
کنترل تمرکز: کاربر را به یک صفحه خالی بدون توضیح انتقال ندهید.
حالت RTL برای نقش ها در مناطق مربوطه پشتیبانی می شود.
A11y: 'aria-disabled' + توضیح، در دسترس بودن تشدید صفحه کلید.


11) شرایط و خطاها

403 (غیرقابل قبول): صفحه دوستانه با زمینه نقش و «درخواست دسترسی» CTA.
404 (بدون منبع): وجود اشیاء پنهان را نشان نمی دهد.
413/422 (بیش از حد/اعتبار سنجی): جزئیات سیاست را فاش نکنید، بی طرف فرمول بندی کنید.
محدودیت نرخ/قفل: وضعیت تایمر/باز کردن را توضیح دهید.


12) معیارها

نرخ دسترسی رد شده: نرخ شکست توسط نقش/صفحه نمایش (IA بد یا سیگنال سیاست).
SLA تایید: زمان تایید متوسط توسط جریان (خروجی، محدودیت، KYC).
رویدادهای آشکار ماسک: نرخ «آشکار» PII (انتظار می رود کوچک و موجه).
خطا به وضوح: زمان از 403 به دسترسی اعطا شده است.
رانش حداقل امتیاز: نقش با حقوق کار برکنار شده (detectability by use).


13) ضد الگوهای

نمایش دکمه های خالی بدون توضیح

پنهان کردن اشتباهات در زیر «هیچ چیز اتفاق افتاده است».
ماسک مالک با اطلاعات خود را.
به نگهبانان UI بدون سیاست های سرور اعتماد کنید.
مخلوط ficheflags با دسترسی (وظایف مختلف).
به خاطر راحتی، «حالت خدا» را پشتیبانی کنید.


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) رابط کاربری قطعه

نگهبان مسیر:
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 روشن وجود دارد.

اقدامات و نگهبانان

  • دکمه های بدون حقوق - 'غیر فعال' + راهنمای ابزار/متن.
  • روتها محافظت می شود ؛ URL مستقیم → 403 با یک توضیح.
  • سرور هر عمل را تایید می کند.

داده ها

  • PII/PAN/KYC توسط سیاست پوشانده شده است.
  • سیاهههای مربوط به «افشا» نوشته شده و بررسی می شود.
  • صادرات/گزارش ها به نقش (aggregates برای تجزیه و تحلیل) مطابقت دارد.

SoD/مصوبات

  • آغازگر نمی تواند درخواست خود را تأیید کند.
  • مقادیر آستانه مسیرهای چند مرحله ای.

А11у/Localization

  • «بدون دسترسی» محلی شده است ؛ ناوبری صفحه کلید کار می کند.
  • حلقه های کنتراست/تمرکز مربوط به AA است.

قابلیت اطمینان

  • کش مجوز با TTL کوتاه ؛ ناتوانی در تغییر نقش ها
  • قطره PDP → UI در حالت پیش فرض امن است.

17) مستندسازی در سیستم طراحی

Компоненты: 'GuardedRoute', 'Can', 'NoAccessCard', 'ApprovalBanner', 'Redact'.
سیاست ها: ماتریس نقش/عمل، قوانین SoD، سطوح پوشش.
فرآیند: درخواست دسترسی، آموزش/صدور گواهینامه از نقش ها، تجدید نظر در حقوق یک بار در هر N هفته.
Do/Don 't gallery: «دکمه های خالی بدون هیچ دلیلی»، «پنهان کردن مالک»، «UI بدون بررسی سرور» در مقابل «محدودیت های توضیح داده شده و CTA».


خلاصه ای کوتاه

رابط های نقش معماری اطلاعات روشن + سیاست های سختگیرانه + توضیحات دوستانه است. فقط آنچه را که نیاز دارید نشان دهید، اطلاعات حساس را بپوشانید، مسیرها و اقدامات را با نگهبانان محافظت کنید، هر رویداد بحرانی را در حسابرسی ثبت کنید و مسئولیت هایی را که در آن بر پول و انطباق تاثیر می گذارد، به اشتراک بگذارید. در iGaming، این نه تنها خطرات را کاهش می دهد، بلکه باعث می شود تیم ها سریع تر و آرام تر شوند.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.