نقش و دسترسی کاربران در پنل مدیریت؛ چطور از اول درست طراحی کنیم؟

برای اینکه نقش و دسترسی کاربران از اول درست طراحی بشه، اول فهرست کارهایی رو بنویس که توی پنل انجام می شه. بعد اون ها رو بر اساس وظیفه (نه اسم آدم ها) توی چند نقش دسته بندی کن و به هر نقش فقط کمترین دسترسی لازم رو بده. مهم ترین قدم هم اینه که دسترسی رو سمت سرور چک کنی، نه فقط با قایم کردن دکمه ها.

یکی از پرسش های تکراری که توی پشتیبانی می شنویم این شکلیه: «پنل ما کار می کنه، ولی نمی دونیم چرا یه کارشناس فروش به بخش مالی راه پیدا کرده.» تقریباً همیشه ریشه ی ماجرا همون روز اول، موقع طراحی، کاشته شده. توی این راهنما قدم به قدم جلو می ریم، با مثال یه پنل سازمانی، و آخرش هم از اشتباه هایی می گم که معمولاً چند ماه بعد، موقع تغییرات، خودشون رو نشون می دن.

اول «کارها» رو فهرست کن، نه آدم ها رو

قبل از اینکه کلمه ی «نقش» رو به زبون بیاری، یه جدول ساده بکش: پنل با چه چیزهایی کار می کنه و روی هر کدوم چه کارهایی انجام می شه. فاکتور، مشتری، محصول، گزارش مالی، تنظیمات. روی هر کدوم هم عمل ها: دیدن، ساختن، ویرایش، حذف، تأیید، خروجی گرفتن.

چرا فهرست کارها و نه فهرست آدم ها؟ چون اگه بنویسی «آقای الف همه ی فاکتورها رو می بینه و خانم ب قیمت ها رو عوض می کنه»، طراحیت به آدم ها گره خورده. آدم ها جابه جا می شن، مرخصی می رن، از شرکت می رن. کارها می مونن. فاکتور تا وقتی شرکت هست تأیید می خواد، حالا هر کسی که این کار رو بکنه.

از اینجا یه مثال رو تا آخر مقاله با خودمون جلو می بریم: پنل داخلی یه شرکت متوسط با چهار بخش فروش، مالی، پشتیبانی و مدیریت. جدول اولیه ی این پنل می تونه این شکلی باشه:

ستون آخر رو جدی بگیر. همین الان، قبل از هر طراحی، عمل های خطرناک رو علامت بزن: حذف، خروجی کامل داده، تغییر قیمت، تغییر تنظیمات. بعداً بیشترین دقت و بیشترین لاگ رو همین ها می خوان.

از کار به نقش: نقش و دسترسی کاربران رو بر اساس وظیفه بساز

حالا که فهرست کارها آماده ست، وقت دسته بندیه. اول سه اصطلاح رو جدا کنیم، چون خیلی وقت ها قاطی می شن.

نقش، مجوز و کاربر سه چیز جدا هستن

• مجوز: یه عمل مشخص روی یه منبع مشخص. مثلاً «تأیید فاکتور».
• نقش: مجموعه ای از مجوزها که به یه وظیفه ی واقعی می خوره. مثلاً «مدیر مالی».
• کاربر: آدمی که یک یا چند نقش داره.

دسترسی رو هیچ وقت مستقیم به کاربر نچسبون. اول مجوز، بعد نقش، بعد کاربر. وقتی خانم ب از فروش به مالی می ره، فقط نقشش عوض می شه و لازم نیست سی تا تیک رو یکی یکی جابه جا کنی.

اصل کمترین دسترسی

هر نقش فقط همون قدر دسترسی بگیره که کارش لازم داره. دلیلش ساده ست: دادن دسترسی بیشتر همیشه آسون تره از پس گرفتنش. کسی که یه بار چیزی رو دیده یا یه امکان رو استفاده کرده، با برداشتن دسترسی عادت و انتظارش پاک نمی شه. اگه نقشی بعداً کم داشت، اضافه کردنش یه ثانیه کار داره.

نقش های پیشنهادی برای پنل نمونه

• مدیر ارشد: همه چیز رو می بینه و کاربرها و تنظیمات رو مدیریت می کنه. تعداد این نقش رو عمداً کم نگه دار.
• مدیر مالی: فاکتورها رو تأیید می کنه و گزارش مالی رو می بینه و خروجی می گیره، ولی تنظیمات سیستم رو عوض نمی کنه.
• کارشناس فروش: مشتری و فاکتور می سازه و ویرایش می کنه، قیمت رو می بینه ولی عوض نمی کنه، گزارش مالی رو نمی بینه.
• پشتیبان: مشتری و فاکتورها رو برای پاسخ دادن می بینه، چیزی حذف یا تأیید نمی کنه.
• ناظر: فقط مشاهده. برای حسابرس، مشاور یا مدیری که فقط می خواد وضعیت رو ببینه.

یه تشبیه بهت کمک می کنه: ساختمان اداری رو با کارت ورود تصور کن. کارت هر نفر فقط در طبقه و اتاق های لازمش رو باز می کنه و هیچ کس به این دلیل که «بالاخره بعداً لازم می شه» دسته کلید اصلی ساختمان رو نداره. نقش ها همون کارت ها هستن و مجوزها همون درهایی که باز می کنن.

یه هشدار هم بگم. نقش های خیلی ریز، مثل «کارشناس فروش تهران، شیفت صبح»، خیلی زود از کنترل خارج می شن. اگه تنها چیزی که فرق می کنه محدوده ی داده ست، اون رو از خود نقش جدا کن. این موضوع رو توی بخش ۵ باز می کنیم.

ماتریس دسترسی بکش و با آدم های واقعی امتحانش کن

تا اینجا همه چیز توی ذهن و روی کاغذه. قدم بعدی اینه که اون رو به یه ماتریس تبدیل کنی: نقش ها توی ستون ها، مجوزها توی ردیف ها و هر خونه یا باز یا بسته. اینجا کارِ طراحی نیست، کارِ بازبینیه.

اسم مجوزها رو از همون اول یکدست بنویس. یه الگوی ساده مثل «منبع.عمل» کافیه:

invoice.read
invoice.create
invoice.approve
customer.export
price.update
settings.manage

این قرارداد دو فایده داره. یکی اینکه توی کد و مستندات همه یه زبون حرف می زنن. دوم اینکه وقتی بخش جدیدی به پنل اضافه می شه، از قبل می دونی مجوزهاش چه شکلی باشه.

بعد ماتریس رو جلوی سرپرست هر بخش بذار و بپرس: «این آدم ها برای کار روزانه شون به چیزی نیاز دارن که توی این ستون نیست؟» معمولاً ۱ یا ۲ مورد پیدا می شه که فقط در عمل معلوم می شه، مثلاً پشتیبان که باید بتونه وضعیت پرداخت یه سفارش رو ببینه. بهتره همین الان بفهمی، نه بعد از اینکه پنل راه افتاد و همه دارن با «ادمین» کار می کنن. این بدترین اتفاقه: وقتی نقش ها اذیت کنن، آدم ها به جای اینکه از تو بخوان، یه حساب مدیر مشترک درست می کنن.

دسترسی رو سمت سرور چک کن، نه فقط با پنهان کردن دکمه

این قدم رو از همه مهم تر می دونم و پرتکرارترین خطاییه که توی بررسی پنل ها می بینیم. وقتی نقش کارشناس فروش وارد می شه و دکمه ی «تأیید فاکتور» رو نمی بینه، یعنی رابط کاربری درست کار می کنه. ولی امنیت هنوز برقرار نشده. اگه سرور درخواست «تأیید فاکتور» رو بدون پرسیدن بپذیره، هر کسی که آدرس API رو بدونه (یا فقط با ابزار توسعه ی مرورگر ببینه) می تونه اون رو مستقیم بفرسته.

قاعده ی ساده ش اینه: رابط کاربری دسترسی رو نشون می ده، سرور دسترسی رو اجرا می کنه. هر endpoint باید خودش مجوز لازم رو بپرسه:

app.post("/invoices/:id/approve", requirePermission("invoice.approve"), approveInvoice);

چند نکته ی عملی:

• ۴۰۱ و ۴۰۳ رو قاطی نکن. ۴۰۱ یعنی «معلوم نیست کی هستی»، ۴۰۳ یعنی «می دونم کی هستی ولی اجازه نداری». این تفاوت موقع عیب یابی کلی وقت صرفه جویی می کنه.
• مجوز رو به نقش گره نزن، به اسمش نه. در کد، به جای if (role === "admin") از can("invoice.approve") استفاده کن. دلیلش رو توی بخش اشتباه های رایج می بینی.
• سطح رکورد رو هم فراموش نکن. گاهی داشتن مجوز «دیدن فاکتور» کافی نیست و باید بپرسی این فاکتور مال این کاربر هست یا نه.
• اگه API هم داری، شیوه ی شناسایی کاربر و ارسال نقش ها اهمیت پیدا می کنه. توی احراز هویت API؛ کلید API یا توکن JWT کدام را انتخاب کنیم؟ تفاوت این دو رو توضیح دادیم.

محدوده ی داده رو از نقش جدا کن

فرض کن شرکت نمونه ما دو شعبه داره، تهران و شیراز. کارشناس فروش تهران نباید مشتری های شیراز رو ویرایش کنه. راه اشتباه (و وسوسه انگیز) اینه که دو نقش بسازی: «کارشناس فروش تهران» و «کارشناس فروش شیراز». با اضافه شدن شعبه ی سوم، تیم جدید یا ترکیب شعبه ها، تعداد نقش ها منفجر می شه.

راه تمیزتر: نقش بگه چه کاری می تونی بکنی و محدوده بگه روی کدوم داده. یعنی هر دو کارشناس نقش «کارشناس فروش» دارن و جداگانه یه ویژگی «شعبه» دارن که فیلتر داده رو تعیین می کنه. چند محدوده ی رایج:

• فقط رکوردهایی که خودم ساختم.
• رکوردهای تیم یا شعبه ی من.
• همه ی رکوردها.

استثنا: اگه تفاوت دو گروه فقط در داده نیست و عمل هاشون هم فرق داره، دو نقش جدا منطقی تره. معیار اینه: اگه فقط «کدوم داده» عوض می شه، محدوده؛ اگه «چه کاری» عوض می شه، نقش.

اگه پنلت رو داری از نو می سازی و می خوای این معماری قبل از شروع کدنویسی یه بار با یه نفر دیگه مرور بشه، مشاوره و معماری برای همین جور تصمیم هاست. هزینه ی اصلاح این بخش بعد از راه افتادن پنل خیلی بیشتر از هزینه ی فکر کردن قبل از اونه.

تغییرهای بعدی: جایی که طراحی خوب امتحان پس می ده

طراحی روز اول معمولاً تمیزه. مشکل از ماه های بعد شروع می شه: یه ماژول جدید، یه همکار تازه، یه استثنا که «فقط این یه بار». این ها اشتباه هایی هستن که بیشتر از همه می بینیم.

اشتباه های رایج

• ساختن نقش جدید با کپی و دستکاری. هر کپی یه نسخه ی مستقل می شه و چند ماه بعد هیچ کس نمی دونه چرا «مدیر مالی ۲» با «مدیر مالی» فرق داره. اول ببین نقش فعلی رو می شه اصلاح کرد یا نه.
• چک کردن اسم نقش توی کد. اگه کد پر از role === "admin" باشه، هر بار که بخوای نقش تازه ای اضافه کنی باید کل پروژه رو بگردی. مجوز رو چک کن، نه اسم نقش رو.
• دسترسی «موقت» که هیچ وقت برداشته نمی شه. یه همکار برای دو روز دسترسی مدیر می گیره و ماه ها بعد هنوز داره. اگه دسترسی موقته، تاریخ انقضا براش بذار.
• ماژول جدید با دسترسی پیش فرض باز. مجوزهای بخش تازه باید پیش فرض بسته باشن و فقط به نقش هایی که لازم دارن داده بشن.
• حساب همکار رفته که هنوز فعاله. فهرست «ترک کار» رو با تیم منابع انسانی هماهنگ کن. حساب باید همون روز غیرفعال بشه.
• اعمال دیرهنگام تغییر نقش. اگه دسترسی کسی رو کم کردی ولی توکن یا نشست قدیمیش تا ساعت ها معتبره، عملاً هنوز دسترسی داره. مدت اعتبار نشست رو با حساسیت پنل متناسب کن و بعد از تغییر نقش، نشست های فعال رو بی اعتبار کن.
• حساب مدیر مشترک. وقتی چند نفر با یه حساب کار می کنن، دیگه معلوم نیست کی چه کاری کرده.

لاگ و بازبینی دوره ای

دو عادت کوچیک خیلی کمک می کنه. اول، لاگ تغییرها: هر بار که نقش یا مجوزی عوض شد، ثبت کن چه کسی، چه چیزی و کی رو عوض کرده. عمل های خطرناکی که اول فهرست کردی (حذف، خروجی گرفتن، تغییر قیمت) هم همین کار رو بخوان. دوم، هر چند ماه یه بار فهرست کاربران فعال و نقش هاشون رو با سرپرست هر بخش مرور کن. کافیه ده دقیقه وقت بذاری و بپرسی «این آدم ها هنوز همین کار رو می کنن؟».

برای حساب هایی که نقش مدیر یا مالی دارن، ورود دو مرحله ای (مثلاً با پیامک یا برنامه ی تولید کد) یه لایه ی ارزون و مؤثره. خروجی گرفتن از داده ی مشتری ها (شماره موبایل، فاکتور، تراکنش) هم باید جزو عمل های حساس حساب بشه، چون وقتی فایل از پنل بیرون رفت، دیگه هیچ نقشی کنترلش نمی کنه.

اگه API پنل رو برای اپ موبایل یا سیستم دیگه ای هم باز می کنی، نقش ها و مجوزها رو توی مستند هم بنویس تا تیم های دیگه بدونن هر endpoint چه سطح دسترسی می خواد. مستندسازی API با OpenAPI؛ از فایل اولیه تا مستند قابل استفاده نشون می ده این کار رو چطور می شه ساختارمند انجام داد.

سوالات متداول

بهتره نقش های آماده ی فریم ورک رو استفاده کنیم یا خودمون بنویسیم؟

شروع با نقش های آماده بد نیست، به شرطی که اسم و محدوده ی هر کدوم با کار واقعی سازمانت جور باشه. اغلب نقش های پیش فرض خیلی کلی هستن (مثل «ادمین» و «کاربر») و فقط برای شروع کافین. وقتی چند نقش واقعی نیاز شد، از روی ماتریس دسترسی خودت نقش های اختصاصی بساز.

چند نقش برای یه پنل کافیه؟

عدد ثابتی وجود نداره. معیارش اینه که هر نقش با یه وظیفه ی واقعی توی سازمان جور باشه. اگه نقش هایی داری که هیچ کس دقیق نمی دونه برای چی ساخته شدن، یا فقط به خاطر تفاوت در محدوده ی داده جدا شدن، احتمالاً بیش از حد ریز شدی.

اگه یه نفر دو کار مختلف داشته باشه چی؟

لازم نیست نقش ترکیبی بسازی. به کاربر دو نقش بده و دسترسی نهایی رو اجتماع مجوزهای هر دو نقش در نظر بگیر. فقط حواست باشه ترکیب نقش ها یه «مدیر ارشد پنهان» نسازه، مثلاً کسی که هم ثبت و هم تأیید فاکتور رو داره و عملاً کنترل متقابل رو دور می زنه.

بعد از تغییر نقش یه کاربر، دسترسی جدید کی اعمال می شه؟

بستگی داره سیستم نقش ها رو کجا نگه می داره. اگه نقش ها توی توکن یا نشست ذخیره شدن، تا انقضا یا ورود دوباره ممکنه دسترسی قدیمی بمونه. بهتره سرور بعد از تغییر نقش، نشست های فعال اون کاربر رو بی اعتبار کنه یا نقش ها رو هر بار از پایگاه داده بخونه.

یه چک لیست کوچیک برای امروز

اگه فقط می خوای کار عملی انجام بدی، همین چهار قدم رو بردار: کارهای پنل رو فهرست و عمل های خطرناک رو علامت بزن؛ مجوزها رو با قرارداد «منبع.عمل» اسم گذاری کن؛ چند نقش بر اساس وظیفه بساز و محدوده ی داده رو جدا نگه دار؛ و مطمئن شو هر endpoint خودش مجوز رو چک می کنه. بعد از اون، هر بار که کسی گفت «یه استثنا بده»، اول ببین استثناء رو می شه با نقش یا محدوده حل کرد یا نه. با این عادت، نقش و دسترسی کاربران هر چقدر هم پنل بزرگ بشه، قابل فهم و قابل کنترل می مونه.