وقتی برای اولین بار وارد دنیای DRF میشی، اولش کلی ذوق داری که تونستی داده ها رو به json تبدیل کنی و با postman درخواست بفرستی و جواب بگیری. همه چیز عالیه :‌ لیست کاربران میاد، مقالات ساخته میشه و ... . اما یک نکته ی خیلی مهمی اینجا هست، تصور کن دیتابیس مثل خونه ی تو هست، الان که API ساختی در واقع در خونه رو باز گزاشتی آیا دوست داری هر کسی از خیابون رد میشه بیاد تو؟ وسایل رو جابجا کنه یا حتی مثلا تلویزیون رو برداره ببره؟ نه، اینجاست که بحث امنیت و مدیریت سطوح دسترسی پیش میاد، تو نیاز داری بدونی کسی که داره در میزنه کیه؟‌ آیا اجازه داره وارد اتاق خواب بشه یا فقط باید توی پذیرایی بشینه. در جنگو رست فریمورک ما این نگهبان های هوشمند رو به اسم Permissions میشناسیم. توی این مقاله میخایم به زبان ساده بفهمیم این Permission ها دقیقا چیکار میکنن و  چه انواع مختلفی دارن؟ 

تفاوت احراز هویت (Authentication) و سطح دسترسی (Permission)

1.احراز هویت (Authentication) : "یعنی تو کی هستی؟" ، کاربر یوزرنیم و پسورد میده و سیستم میگه : "آها شناختمت تو علی هستی".

۲.سطوح دسترسی (Permission) : یعنی "اجازه داری این کار رو انجام بدی؟" حالا که فهمیدم تو علی هستی، آیا اجازه داری این پست رو حذف کنی؟

مثال ساده: وقتی میری بانک، کارت ملی نشون میدی تا بفهمن تو کی هستی (Authentication). اما حتی اگر بشناسنت، اجازه نمیدن بری توی گاو صندوق اصلی بانک پول برداری (Permission)، فقط اجازه داری به حساب خودت دسترسی داشته باشی.

جنگو رست چطور دسترسی ها را چک می کند؟

جنگو رست چطور دسترسی ها را چک می کند؟

در معماری جنگو رست قبل از اینکه درخواست به ویو برسه باید از سد Permission عبور کنه. اگر اجازه دسترسی داشته باشه، کد اجرا میشه در غیر این صورت ارور Forbidden 403 و  Unauthorized 401 برگردونده میشه.

شما میتونید این تنظیمات رو به دو صورت اعمال کنید: 

۱,Global (سراسری): توی settings.py بگی کل سایت برای همه قفله مگر اینکه لاگین کنن.

2.Per View (برای هر ویو): بگی فلان ویو برای همه آزاده، ولی فلان ویو فقط برای مدیره.

انواع سطوح دسترسی آماده (Built-in Permissions) در جنگو رست

انواع سطوح دسترسی آماده (Built-in Permissions)

1.AllowAny : این سطح دسترسی یعنی "در بازه، بفرما تو!"  مهم نیست کاربر لاگین کرده یا نه، ناشناسه یا مدیره. هر کسی میتونه به این API دسترسی داشته باشه. معمولا برای صفحات "ثبت نام" یا "لیست مقالات عمومی" از این استفاده میشه.

۲.IsAuthenticated : این یعنی "فقط اعضا حق ورود دارن". کاربر حتما باید لاگین کرده باشه (توکن معتبر داشته باشه) تا بتونه از این API استفاده کنه. اگر کاربر لاگین نکرده باشه، جنگو رست اصلا اجازه نمیده درخواستش پردازش بشه. این پرکاربرد ترین پرمیشن برای اپلیکیشن‌ های موبایل و پنل‌ های کاربریه.

3.IsAdminUser : این دسترسی مخصوص ادمین ‌هاست. چک میکنه ببینه آیا فیلد is_staff=True برای اون کاربر فعال هست یا نه. اگر میخوای یه API بسازی که فقط خودت بتونی توش یوزر های جدید رو ببینی یا چیزی رو تغییر بدی، این بهترین گزینه است.

۴. IsAuthenticatedOrReadOnly :‌

این یکی خیلی جالبه و هوشمندانه عمل میکنه. ترکیبی از "دیدن" و "نوشتن" هست.

  • اگر درخواست از نوع "خواندن" باشه (مثل GET, HEAD, OPTIONS): همه اجازه دارن (حتی کسانی که لاگین نکردن).

  • اگر درخواست از نوع "تغییر" باشه (مثل POST, PUT, DELETE): کاربر باید حتما لاگین کرده باشه.

کاربرد: تصور کن یک سایت وبلاگ داری. میخوای همه بتونن مقالات رو بخونن (Anonymous)، اما فقط اعضا بتونن کامنت بذارن. این کلاس دقیقا برای همین جاست.

وقتی دسترسی های آماده کافی نیست (Custom Permissions)

گاهی اوقات منطق سایت ما  پیچیده تر از این حرفاست. فرض کن یک اپلیکیشن یادداشت‌ برداری نوشتی. کاربر A نباید بتونه یادداشت‌ های کاربر B رو ببینه یا ویرایش کنه. اگر از IsAuthenticated استفاده کنی، کاربر B چون لاگین کرده، می‌تونه یادداشت کاربر A رو هم دستکاری کنه!

اینجاست که باید Custom Permission بنویسیم. جنگو رست بهت اجازه میده یک کلاس بسازی و توش منطق خودت رو با پایتون بنویسی. مثلا یک کلاس میسازی به اسم IsOwnerOrReadOnly. توی این کلاس چک میکنی: "آیا کاربری که داره درخواست میده (request.user)، همون صاحب  این  یادداشته؟" اگر بود -> True (اجازه بده) اگر نبود -> False (جلوش رو بگیر)

این قدرت واقعی جنگو رسته که دستت رو برای هر سناریویی باز میذاره.

چرا باید از Permissions استفاده کنیم؟

چرا باید از Permissions استفاده کنیم؟ 

شاید بگی "خب من خودم توی کدم یه if میزارم و چک میکنم کاربر کیه. چرا باید از کلاس های DRF استفاده کنم؟‌

۱.کد تمیز تر (Clean Code) : منطق امنیت رو از منطق اصلی برنامه جدا میکنی. ویو های شما پر از شرط ‌های if/else نمیشه.

۲.تکرار نکردن (DRY) : یک بار پرمیشن "فقط نویسنده مقاله" رو مینویسی و توی ۱۰ تا ویو مختلف ازش استفاده می‌کنی.

3.امنیت متمرکز :‌ اگر فردا بخوای قانون دسترسی رو عوض کنی، فقط یک جا رو تغییر میدی و نگران نیستی که جایی یادت رفته باشه.

۴.پیغام های استاندارد :‌ خود فریمورک به صورت خودکار کد های خطای استاندارد HTTP (مثل 403) رو برمیگردونه که برای فرانت‌ اند دولوپر ها قابل فهمه.

جمع بندی

در دنیای توسعه وب مدرن، "اعتماد" چیز خوبی نیست! ما باید فرض کنیم تمام درخواست‌ هایی که به سمت سرور میان نیاز به بررسی دارن. جنگو رست فریمورک با سیستم Permissions به ما یک جعبه ابزار کامل میده تا بتونیم خیلی دقیق تعیین کنیم:

کی میتونه ببینه؟

کی میتونه بسازه؟

کی میتونه پاک کنه؟

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