تو این مقاله میخوام راجب این صحبت کنم که role base access control چقد ساده میتونه تو فرانت‌اند کنترل بشه.
با یه مثال میخوام قضیه رو توضیح بدم و flow کلی rbac رو بگم
تو حالت خیلی عادی و دیدگاه impretive یه همچین چیزی داریم:
تو عکس بالا اگه عمیق تر بهش فک کنیم و بیاییم ببینیم آیا این if و else نوشتن فقط به همین کامپوننت خلاصه میشه؟یا نه؟ و موضوع خیلی مهمی که وجود داره اینه که ممکنه المان های خیلی کوچیک هم role base بخوان نمایش داده بشن، اونموقع برای هر المان یه همچین چیزی باید بنویسیم به تعداد role ها.
تو rbac قطعا هر role یکسری permission هایی داره. منظورم اینه یک role مثل admin میتونه مثلا یک محصول تو پنل اضافه کنه ولی یوزر عادی نمیتونه. پس قاعدتا نباید این feature برای یوزر عادی نشون داده بشه. یه قراردادی تو نحوه نوشتن permission ها وجود داره که اون به این شکله:
[feature]:[action]
تو مثال بالا admin در واقع میتونه product:create داشته باشه و یا اصطلاحا میتونه perform کنه ولی یوزر عادی نمیتونه. پس میایم یک obj استاتیک (ممکنه بسته به نیاز داینامیک باشه و از سمت سرور بیاد)مینویسیم به این شکل:
حالا اینکار چه فایده‌ای داره؟ فایدش اینه که با اینکار میتونیم بگیم هر المان داخل صفحه یه access level ای داره و به جای اینکه بیاییم مستقیما عملیات شرط گذاری رو برا المان ها بنویسیم میاییم میگیم اگر فلان یوزر با فلان role همچین permission ای داشت حالا این رو رندر کن. در واقع یه همچین ساختاری:
شاید بگید الان چه فرقی کرد! زشت تر شد که! درسته ولی ما با این میتونیم یه لایه abstract ای بیاریم روی کار و این وظیفه چک کردن رو بدیم به یه کامپوننت دیگه! از طرفی سپردن permission ها به المان های صفحه باعث میشه بتونیم به هر المان چندین permission بدیم و چک کنیم برای نمایش این المان user حتما باید permission هاشو داشته باشه. خیلی خفن طور میاییم و کامپوننت Can رو معرفی میکنیم:
اون TPermission چیز خاصی نیست و صرفا یه تایپیه که کل permission هارو تو خودش داره.
این کامپوننته can یه پراپ perform میگیره که یه آرایه‌ای از permission هاست. که میگه این user ای که تو اپ هست باید تمام permission هایی که این کامپوننت برای رندر شدن داره رو باید داشته باشه.مثلا اگر آرایه perform به صورت ["product:create","product:remove"] بود، باید user هم چنین permission هایی داشته باشه حالا اینکار چک کردن رو تابعی به اسم check که تو can هم استفاده شده، میکنه:
حالا میتونیم اینطور استفادشون کنیم:
و داشتن یه کاستوم هوک هم کمک میکنه المان های کوچیک زیاد درگیر can نشن:
و طریقه استفادش هم :
بسیار عالی. این api رو من خیلی کلی توضیح دادم و خب بسته به نیاز پروژه میتونه داینامیک تر بشه مثلا میتونیم permission های داینامیک اضافه کنیم تو اون ابجکت role.مثلا یک user فقط میتونه پست های خودش رو ادیت بکنه نه پستای بقیه رو بنابراین پست ها باید داینامیک مدیریت بشن.
و خب خوبی این روش اینه از شر مزاحمت های اون if else ها تو همه کامپوننت ها راحت میشیم و از طرفی یه لاجیک خیلی ساده و منعطف داریم که میتونه توانایی های خودشو تو code base های بزرگ نشون بده.
خیلی ممنون. خوشحال میشم نظراتتونو بگید :)
