‏پیاده‌سازی RBAC در لاراول بدون پکیج خارجی

وقتی یه اپلیکیشن کوچیکه، یه ستون is_admin کافیه. ولی وقتی نیاز داری billing manager فقط فاکتور ببینه، ادمین تیم فقط داخل تیم خودش کاربر دعوت کنه، و auditor همه چیز بخونه ولی چیزی تغییر نده، اون ساختار ساده دیگه جواب نمی‌ده. اینجاست که RBAC (Role-Based Access Control) به کار میاد.

RBAC یه مدل دسترسی‌ه که توش کاربران نقش می‌گیرن، نقش‌ها دسترسی دارن، و سیستم به‌جای چک کردن عنوان شغلی، می‌پرسه «این کاربر اجازه انجام این کار رو داره؟» مهم‌ترین مزیتش اینه که نقش‌ها پایدارترن از کاربرها؛ آدم‌ها تیم عوض می‌کنن، ارتقا می‌گیرن یا می‌رن، ولی نقش‌ها معمولاً ثابت می‌مونن.

مقاله تأکید می‌کنه که RBAC واقعی یعنی کدت با permission صحبت کنه، نه اسم نقش. یعنی به‌جای $user->isAdmin() || $user->isOwner()، بنویسی:

$user->can('deploy', $project);

این رویکرد هم خواناتره، هم وقتی قرار باشه چند نقش مختلف یه permission مشترک داشته باشن، فقط mapping نقش-دسترسی رو آپدیت می‌کنی نه همه کنترلرها رو.

برای طراحی سیستم، مقاله پیشنهاد می‌کنه اول permission‌ها رو تعریف کنی، بعد نقش‌ها رو. Permission‌ها توی یه PHP Enum تعریف می‌شن، مثل project.deploy یا billing.manage، و هر نقش یه RoleDefinition با سطح عددی (level) و لیست دسترسی‌هاش داره. نقش owner با level 100 همه دسترسی‌ها رو داره، و نقش viewer با level 10 فقط می‌تونه چیزها رو ببینه.

مدل نهایی تیم‌محوره: یه کاربر می‌تونه توی تیم A ادمین باشه و توی تیم B فقط viewer. دسترسی مؤثر هر کاربر، اجتماع دسترسی‌های تمام نقش‌هایی‌ه که توی اون تیم داره. علاوه بر این، محدودیت‌های جداسازی وظایف (Separation of Duty) هم پشتیبانی می‌شن — مثلاً auditor و billing-manager نمی‌تونن همزمان به یه نفر در یه تیم اختصاص داده بشن.

نکات کلیدی:

• RBAC یعنی دسترسی از طریق نقش، نه مستقیم روی کاربر
• کدت باید با permission صحبت کنه، نه اسم نقش
• نقش‌ها باید scoped به context باشن (مثلاً تیم)، نه global
• اول permission‌ها رو طراحی کن، بعد نقش‌ها رو بساز
• محدودیت‌های Separation of Duty برای سیستم‌های واقعی ضروری‌ان
• کش کردن resolution دسترسی‌ها برای performance اهمیت داره