جینگو ریسٹ فریم ورک اور سادہ جے ڈبلیو ٹی کا استعمال کرتے ہوئے اسکوپڈ نوٹ لینے والا API کیسے بنایا جائے

اگر آپ نے ایک Django API بنایا ہے اور یہ سوچ رہے ہیں کہ تصدیق کیسے شامل کی جائے تاکہ یہ یقینی بنایا جا سکے کہ ہر صارف صرف اپنے ڈیٹا تک رسائی حاصل کر سکتا ہے، آپ صحیح جگہ پر پہنچے ہیں۔

زیادہ تر جیانگو ٹیوٹوریلز سیشن پر مبنی توثیق سکھاتے ہیں۔ جب فرنٹ اینڈ اور بیک اینڈ ایک ہی سرور پر ہوتے ہیں تو یہ اچھی طرح کام کرتا ہے۔ لیکن جیسے ہی آپ انہیں الگ کرتے ہیں، جیسے ہی Netlify کی React ایپ PythonAnywhere کے Django API کے ساتھ بات چیت کرتی ہے، سیشن کریش ہونا شروع ہو جاتا ہے۔

کوکیز تمام ڈومینز میں اچھی طرح سے سفر نہیں کرتی ہیں، اور اچانک آپ کا لاگ ان سسٹم کام کرنا بند کر دیتا ہے۔

یہ وہ جگہ ہے جہاں JWT (JSON Web Tokens) کام میں آتے ہیں۔ JWT صارف کی توثیق کا ایک بے وطن، کوکی لیس طریقہ فراہم کرتا ہے۔ ڈومینز، آلات اور پلیٹ فارمز پر بغیر کسی رکاوٹ کے کام کرتا ہے۔ سرور کو کچھ یاد رکھنے کی ضرورت نہیں ہے۔ آپ صرف ٹوکن کے دستخط کی تصدیق کر سکتے ہیں اور بخوبی جان سکتے ہیں کہ درخواست کون کر رہا ہے۔

لیکن توثیق صرف آدھا مسئلہ ہے۔ ایک بار جب آپ جان لیں کہ آپ کے صارفین کون ہیں، آپ کو یہ کنٹرول کرنے کی ضرورت ہے کہ وہ کیا دیکھ سکتے ہیں۔ یہ جگہ دائرہ کار کی وضاحت کریں۔ اندر آو

اسکوپنگ کا مطلب یہ یقینی بنانا ہے کہ ہر صارف کو صرف اس کے اپنے ڈیٹا تک رسائی حاصل ہے۔ صارف A کو صارف B کا ڈیٹا پڑھنے، ترمیم کرنے یا حذف کرنے کے قابل نہیں ہونا چاہئے (اس صورت میں، نوٹ)۔ یہاں تک کہ اگر وہ صحیح ID کا اندازہ لگاتے ہیں۔

اس ٹیوٹوریل میں، آپ ایک پرائیویٹ نوٹ لینے والا API بنائیں گے جہاں صارف رجسٹر کر سکتے ہیں، JWT ٹوکن کے ساتھ لاگ ان کر سکتے ہیں، اور ان نوٹوں کو محفوظ کر سکتے ہیں جن تک صرف وہ ہی رسائی حاصل کر سکتے ہیں۔

راستے میں، آپ ایک حسب ضرورت صارف ماڈل نافذ کریں گے، ٹوکن پر مبنی توثیق کے لیے SimpleJWT کو ترتیب دیں گے، اور ایک دائرہ کار والا منظر بنائیں گے جو ہر صارف کے ڈیٹا کو ان کی اسناد کے پیچھے بند کر دے گا۔

ہم کیا احاطہ کریں گے:

اس ٹیوٹوریل کا احاطہ کرتا ہے:

کسٹم یوزر ماڈل سیٹ اپ کیسے کریں (اور آپ کو ہمیشہ یہ کیوں کرنا چاہیے)
ٹوکن کی توثیق تک رسائی اور ریفریش کے لیے SimpleJWT کو کیسے ترتیب دیا جائے۔
ایک سیریلائزر کیسے بنایا جائے جو حساس کھیتوں کی حفاظت کرے۔
API ویو کی گنجائش کیسے بنائی جائے تاکہ صارفین صرف اپنا ڈیٹا دیکھ سکیں
پوسٹ مین کا استعمال کرتے ہوئے پورے بہاؤ کی جانچ کیسے کریں۔

آئیے شروع کرتے ہیں۔

شرطیں

شروع کرنے سے پہلے، یقینی بنائیں کہ آپ درج ذیل سے واقف ہیں:

جینگو کی بنیادی باتیں: آپ کو یہ سمجھنے کی ضرورت ہے کہ Django پروجیکٹس اور ایپس کیسے کام کرتی ہیں، بشمول ماڈلز، ویوز، یو آر ایل اور منتقلی۔
جیانگو ریسٹ فریم ورک کی بنیادی باتیں: آپ کو سیریلائزرز، ویو سیٹس، یا API ویوز سے واقف ہونا چاہیے اور DRF درخواستوں اور جوابات کو کیسے ہینڈل کرتا ہے۔
بنیادی کمانڈ لائن کا استعمال: اس پورے ٹیوٹوریل کے دوران، آپ ٹرمینل میں کمانڈز پر عمل کریں گے۔

ٹولز آپ کو انسٹال کرنے کی ضرورت ہے:

Python 3.8 یا اس سے زیادہ
pip (ازگر کا پیکیج مینیجر)
کوڈ ایڈیٹر جیسے بصری اسٹوڈیو کوڈ
پوسٹ مین (یا کوئی API ٹیسٹنگ ٹول) اینڈ پوائنٹ ٹیسٹنگ کے لیے۔ اپنے API کو درخواست بھیجنے کے لیے اسے استعمال کریں۔

JWT کیا ہے اور ہم اسے سیشن کی توثیق پر کیوں استعمال کرتے ہیں؟

کوئی بھی کوڈ لکھنے سے پہلے، یہ سمجھنا ضروری ہے کہ JWTs کن مسائل کو حل کرتے ہیں اور کیوں Django کی بلٹ ان سیشن کی تصدیق ہمیشہ کافی نہیں ہوتی ہے۔

سیشن کی توثیق کیسے کام کرتی ہے۔

جینگو سیشن پر مبنی توثیق کا نظام فراہم کرتا ہے۔ یہاں یہ ہے کہ یہ اعلی سطح پر کیسے کام کرتا ہے:

صارف اپنا صارف نام اور پاس ورڈ سرور کو بھیجتا ہے۔
سرور اسناد کی تصدیق کرتا ہے اور سیشن یہ سرور ڈیٹا بیس میں ذخیرہ شدہ ایک چھوٹا ریکارڈ ہے جو کہتا ہے "یہ صارف لاگ ان ہے۔”
سرور واپس بھیجتا ہے: سیشن آئی ڈی کوکیز کے ساتھ۔ آپ کا براؤزر خود بخود اس کوکی کو اسٹور کرتا ہے۔
تمام بعد کی درخواستوں پر، براؤزر کوکی کو سرور پر واپس بھیجتا ہے۔ سرور ڈیٹا بیس میں سیشن آئی ڈی دیکھتا ہے اور کہتا ہے، "اوہ، یہ صارف اے ہے۔ اسے گزرنے دو۔”

جب فرنٹ اینڈ اور بیک اینڈ ایک ہی ڈومین پر ہوتے ہیں تو یہ بالکل کام کرتا ہے۔ براؤزر خود بخود کوکیز کو ہینڈل کرتے ہیں، اور Django آپ کے ڈیٹا بیس میں سیشنز کا انتظام کرتا ہے بغیر آپ کو اس کے بارے میں سوچے۔

تاہم، اس نقطہ نظر کی کچھ حدود ہیں۔

کراس ڈومین کے مسائل: اگر آپ کا React فرنٹ اینڈ app.example.com پر ہے اور آپ کا Django API api.example.com پر ہے تو کوکیز مشکل ہو جاتی ہیں۔ براؤزر سخت قوانین نافذ کرتے ہیں جس کے بارے میں ڈومینز کوکیز بھیج اور وصول کر سکتے ہیں۔

آپ کراس اوریجن ریسورس شیئرنگ (CORS) ہیڈرز اور خصوصی کوکی سیٹنگز کا استعمال کر کے اس کے ارد گرد کام کر سکتے ہیں، لیکن اس سے پیچیدگی بڑھ جاتی ہے اور یہ کمزور ہو سکتی ہے۔
توسیع پذیری کے مسائل: تمام فعال سیشنز سرور کے ڈیٹا بیس میں محفوظ ہیں۔ اگر ایک ہی وقت میں 10,000 صارفین لاگ ان ہیں، تو یہ 10,000 سیشن ریکارڈز ہیں جنہیں سرور کو ہر ایک درخواست کے لیے تلاش کرنے کی ضرورت ہے۔ جیسے جیسے آپ کی درخواست بڑھتی ہے، یہ تلاش ایک رکاوٹ بن جاتی ہے۔
موبائل کے مسائل: موبائل ایپس کوکیز کو اس طرح ہینڈل نہیں کرتی ہیں جس طرح براؤزر کرتے ہیں۔ اگر آپ ایک ایسا API بنا رہے ہیں جو ویب اور موبائل ایپس دونوں کو پیش کرتا ہے، تو سیشن کوکیز اضافی چیلنجز پیش کرتی ہیں۔

جے ڈبلیو ٹی کی توثیق کیسے کام کرتی ہے۔

JWT بنیادی طور پر مختلف انداز اختیار کرتا ہے۔ سرور پر سیشن کا ڈیٹا ذخیرہ کرنے کے بجائے، ہم تصدیق کی معلومات کو براہ راست ٹوکن میں ڈال دیتے ہیں۔

یہاں یہ ہے کہ بہاؤ کیسے کام کرتا ہے:

صارف اپنا صارف نام اور پاس ورڈ سرور کو بھیجتا ہے۔
سرور اسناد کی تصدیق کرتا ہے اور ایک JWT تیار کرتا ہے، ایک طویل انکوڈ شدہ تار جس میں صارف کی شناخت اور ٹوکن کی میعاد ختم ہونے پر معلومات ہوتی ہے۔
سرور یہ ٹوکن کلائنٹ کو واپس بھیجتا ہے۔ کلائنٹ اسے ذخیرہ کرتا ہے (عام طور پر میموری یا مقامی اسٹوریج میں)۔
تمام بعد کی درخواستوں میں، کلائنٹ درخواست کے ہیڈر میں ٹوکن شامل کرتا ہے۔ سرور ٹوکن پڑھتا ہے، دستخط کی تصدیق کرتا ہے، اور پھر کہتا ہے، "یہ صارف A ہے۔ براہ کرم پاس کریں۔”

اہم اختلافات ہیں: سرور کچھ بھی ذخیرہ نہیں کرتا ہے۔.

ڈیٹا بیس میں سیشن کو نہیں دیکھا جاتا ہے۔ یہ صرف ٹوکن کو پڑھتا ہے، کرپٹوگرافک دستخط کی تصدیق کرتا ہے تاکہ یہ یقینی بنایا جا سکے کہ کسی نے اس کے ساتھ چھیڑ چھاڑ نہیں کی ہے، اور پھر صارف کی معلومات کو نکالتا ہے۔ اسی لیے JWT کہا جاتا ہے۔ بے وطن – سرور اس بارے میں کوئی حالت برقرار نہیں رکھتا ہے کہ کون لاگ ان ہے۔

یہ کراس ڈومین کا مسئلہ حل کرتا ہے۔ اس کی وجہ یہ ہے کہ ٹوکن ایک درخواست ہیڈر کے طور پر بھیجا جاتا ہے نہ کہ کوکی کے طور پر۔ ہیڈرز اسی طرح کام کرتے ہیں قطع نظر اس کے کہ جس ڈومین سے درخواست آرہی ہے۔

یہ اسکیل ایبلٹی کا مسئلہ حل کرتا ہے۔ اس کی وجہ یہ ہے کہ سرور سیشنز کو اسٹور نہیں کرتا ہے۔ ٹوکن کی توثیق ڈیٹا بیس کی تلاش کے بجائے ایک فوری کرپٹوگرافک تصدیق ہے۔

یہ آپ کے موبائل کا مسئلہ حل کرتا ہے۔ اس کی وجہ یہ ہے کہ کوئی بھی کلائنٹ جو HTTP ہیڈر بھیج سکتا ہے وہ JWT استعمال کرسکتا ہے۔ موبائل ایپس، ڈیسک ٹاپ ایپس، دوسرے سرورز – یہ سب ایک ہی طرح سے کام کرتے ہیں۔

مرحلہ 1: پروجیکٹ کو کیسے ترتیب دیں اور انحصار کو انسٹال کریں۔

1.1 پروجیکٹ کیسے بنایا جائے۔

ایک ٹرمینل کھولیں، اس مقام پر جائیں جہاں آپ اپنا پروجیکٹ رکھنا چاہتے ہیں، اور درج ذیل کمانڈ کو چلائیں:

mkdir notes-project

cd notes-project

1.2 ورچوئل ماحول کیسے بنایا جائے اور مطلوبہ انحصار کو انسٹال کیا جائے۔

یہ وہ جگہ ہے جہاں آپ اپنا ورچوئل ماحول بناتے ہیں۔ درج ذیل کمانڈ درج کریں:

python3 -m venv venv

مذکورہ کمانڈ فولڈر کے اندر ایک ورچوئل ماحول بناتی ہے۔ venv. پہلے venv یہ ایک حکم ہے اور یہ دوسرا ہے۔ venv فولڈر کے نام کی نشاندہی کرتا ہے۔ فولڈر کا نام کچھ بھی ہو سکتا ہے۔ venv عام طور پر ترجیح دی جاتی ہے۔

ورچوئل ماحول کو چالو کرنے کے لیے، آپ کو درج ذیل کمانڈ کو استعمال کرنے کی ضرورت ہے:

macOS/Linux کے لیے:

source venv/bin/activate

ونڈوز کے لیے:

venvScriptsactivate

آپ دیکھیں گے کہ اس نے کام کیا۔ (venv) ٹرمینل پرامپٹ کے شروع میں۔ کوئی بھی Python پیکج جو آپ اس مقام سے انسٹال کرتے ہیں صرف اس کے اندر موجود ہوں گے۔ مجازی ماحول.

ورچوئل ماحول کے فعال ہونے کے ساتھ، درج ذیل کمانڈز کا استعمال کرتے ہوئے Django، Django Rest Framework، اور Simple JWT Framework انسٹال کریں:

pip install django djangorestframework djangorestframework-simplejwt

آپ چل کر چیک کر سکتے ہیں کہ سب کچھ صحیح طریقے سے انسٹال ہے:

pip list

تینوں پیکجوں کو ان کے انحصار کے ساتھ درج کیا جانا چاہئے۔

1.3 پروجیکٹس اور ایپس کیسے بنائیں

درج ذیل کمانڈ کو چلا کر جینگو پروجیکٹ بنائیں:

django-admin startproject notes_core .

آخر میں نقطہ اہم ہے۔ یہ جینگو کو اضافی نیسٹڈ فولڈر بنانے کے بجائے موجودہ ڈائرکٹری میں پروجیکٹ فائل بنانے کو کہتا ہے۔

اب آئیے درج ذیل کمانڈ کو داخل کرکے ایپ بنائیں:

python manage.py startapp notes

1.4 ایپ اور جیانگو ریسٹ فریم ورک (DRF) کو کیسے رجسٹر کریں

کھلا notes_core/settings.py اور شامل کریں rest_framework اور notes پر INSTALLED_APPS انوینٹری:

اب Django نئی ایپس اور REST فریم ورک کے بارے میں جانتا ہے۔ آئیے سب سے اہم تعمیراتی فیصلے کی طرف چلتے ہیں جو آپ اس پروجیکٹ کے لیے کریں گے۔

مرحلہ 2: حسب ضرورت صارف ماڈل کیسے بنائیں

اگر آپ نے پہلے جیانگو پروجیکٹ بنایا ہے تو، آپ نے جینگو کا ڈیفالٹ صارف ماڈل استعمال کیا ہوگا۔ فوری پروٹو ٹائپنگ کے لیے، یہ ٹھیک ہے۔ تاہم، کسی بھی پروجیکٹ کے لیے جو آپ بڑھانا یا برقرار رکھنا چاہتے ہیں، حسب ضرورت صارف ماڈل کے ساتھ شروع کرنا ایک بہترین عمل ہے جسے کبھی نہیں چھوڑنا چاہیے۔

یہاں کیوں ہے: جینگو کا ڈیفالٹ User ماڈل ہے۔ username فیلڈ کو بنیادی شناخت کنندہ کے طور پر استعمال کریں۔ مسائل پیدا ہوتے ہیں اگر آپ بعد میں فیصلہ کرتے ہیں کہ صارفین کو ان کے ای میل ایڈریس کے ساتھ لاگ ان کرنے، یا پروفائل پکچر فیلڈ یا فون نمبر شامل کرنے کی ضرورت ہے۔

ایک حسب ضرورت صارف ماڈل آپ کو اس پر مکمل کنٹرول فراہم کرتا ہے کہ آپ کی ایپ میں "صارف” کا کیا مطلب ہے۔ صارف نام سے منسلک ہونے کے بجائے، آپ اپنے لاگ ان کو زیادہ عملی چیز کے ارد گرد ڈیزائن کر سکتے ہیں، جیسے فٹنس یا موبائل پر مبنی ایپس کے لیے ای میل یا فون نمبر۔ الگ الگ پروفائلز کو برقرار رکھنے کے بجائے، آپ براہ راست صارف کے ماڈل میں کردار (ڈاکٹر، مریض، ہسپتال کے نظام میں ریسپشنسٹ) یا تاریخ پیدائش بھی شامل کر سکتے ہیں۔

یہ آپ کے پروجیکٹ کو مزید مستقبل کا ثبوت بنانے میں بھی مدد کرتا ہے۔ اگر آپ بنیادی ماڈل کے ساتھ شروع کرتے ہیں اور بعد میں لاگ ان کو صارف نام سے ای میل میں تبدیل کرنے یا مطلوبہ فیلڈز شامل کرنے کا فیصلہ کرتے ہیں تو تبدیلیاں مشکل اور خطرناک ہو جاتی ہیں۔ شروع سے ہی حسب ضرورت صارف ماڈل کا استعمال اس مسئلے سے بچاتا ہے اور آپ کی ایپ کے بڑھنے کے ساتھ ساتھ آپ کے تصدیقی نظام کو ایڈجسٹ کرنا بہت آسان بنا دیتا ہے۔

اگر آپ شروع سے ایک حسب ضرورت صارف ماڈل بناتے ہیں، تو آپ اسے بعد میں بغیر کسی دقت کے آزادانہ طور پر تبدیل کر سکتے ہیں، چاہے یہ بنیادی ماڈل سے مماثل ہی کیوں نہ ہو۔

2.1 حسب ضرورت صارف ماڈل کی وضاحت کیسے کریں۔

کھلا notes/models/py اور درج ذیل کوڈ شامل کریں:

from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    pass

ہم Django کی بلٹ ان فعالیت کو درآمد کر رہے ہیں۔ AbstractUser کلاس

سوچو AbstractUser آپ کے لیے تیار کردہ بلیو پرنٹس کے ساتھ۔ یہ پہلے سے ہی فیلڈز پر مشتمل ہے جیسے صارف نام، پاس ورڈ، ای میل، پہلا نام، آخری نام، اور تصدیق کی منطق۔

کہ pass بیان کا مطلب ہے کہ آپ نے ابھی تک کوئی اضافی فیلڈ شامل نہیں کی ہے۔

لیکن اہم بات یہ ہے کہ یہ ماڈل آپ کا ہے۔ لہذا یہ ماڈل بالکل وہی کام کرتا ہے جیسا کہ جینگو کے ڈیفالٹ صارف ماڈل، لیکن بڑا فائدہ: اب آپ اسے بعد میں لچکدار طریقے سے اپنی مرضی کے مطابق بنا سکتے ہیں۔

اب سے 3 ماہ بعد phone_number اگر آپ کسی فیلڈ کو پُر کرنا چاہتے ہیں یا ای میل پر مبنی لاگ ان پر جانا چاہتے ہیں، تو آپ فیلڈ کو اس کلاس میں شامل کر سکتے ہیں اور منتقلی چلا سکتے ہیں۔

from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    phone_number = models.CharField(max_length=15)

بھی CustomUser کلاس اس سے وراثت میں ملی: AbstractUser کلاس

آپ اس کے لیے ازگر کا شیل استعمال کر سکتے ہیں۔ درج ذیل کمانڈ درج کریں:

python manage.py shell

یقینی بنائیں کہ جب آپ یہ کمانڈ داخل کرتے ہیں تو آپ کا ورچوئل ماحول فعال ہے۔

اس کے بعد CustomUser شیل کا ماڈل:

from notes.models import CustomUser

پھر درج ذیل کوڈ درج کریں:

[fields.name for field in CustomUser._meta.get_fields()]

مندرجہ بالا بیان میں درج ذیل تمام شعبوں کی فہرست ہے: CustomUser کلاس

2.2 کس طرح Django کو کسٹم یوزر ماڈل استعمال کرنے کے لیے بتائیں

اب اہم حصہ آتا ہے۔ کھلا notes_core/settings.py اور درج ذیل لائن شامل کریں:

AUTH_USER_MODEL = 'notes.CustomUser'

یہ ترتیب جینگو کو اجازت دیتی ہے۔ CustomUser توثیق سے متعلق ہر چیز کے لیے بلٹ ان ماڈلز کے بجائے ماڈلز استعمال کریں، جیسے لاگ ان، اجازتیں، غیر ملکی کیز وغیرہ۔

اس بارے میں کوئی سخت اور تیز اصول نہیں ہیں کہ آپ اسے کہاں شامل کریں، لیکن بہترین عمل یہ ہے کہ اسے فائل کے آخر میں شامل کریں۔

آپ چیک کر سکتے ہیں کہ کون سا صارف ماڈل Django مندرجہ ذیل طریقہ استعمال کر رہا ہے۔ get_user_model().

اپنا ازگر کا شیل دوبارہ کھولیں اور درآمد کریں: get_user_model() طریقہ:

from django.contrib.auth import get_user_model

پھر استعمال کریں۔ get_user_model() آؤٹ پٹ پرنٹ کریں۔

user = get_user_model()
print(user)

آپ جو ماڈل استعمال کررہے ہیں اس کا نام ظاہر ہوگا۔

اگر آپ نے اسے شامل نہیں کیا۔ AUTH_USER_MODEL پر settings.py اگر آپ فائل کو محفوظ کرتے ہیں، تو Django پہلے سے طے شدہ صارف ماڈل استعمال کرتا:

میمو: آپ کو اپنی پہلی منتقلی چلانے سے پہلے یہ کرنا چاہیے۔ اگر آپ AUTH_USER_MODEL سیٹ کرنے سے پہلے ہجرت چلاتے ہیں، تو Django پہلے سے طے شدہ صارف ماڈل کے لیے ایک ٹیبل بنائے گا اور بعد میں اس پر سوئچ کرنا سر درد کا باعث ہوگا۔

2.3 منتقلی کیسے چلائی جائے۔

اب آئیے ابتدائی منتقلی بنائیں اور لاگو کریں۔

python manage.py makemigrations
python manage.py migrate

Django تمام بلٹ ان Django ٹیبلز کے ساتھ آپ کے حسب ضرورت صارف ماڈل کے لیے درکار جدولیں بناتا ہے۔

آپ ہڈ کے نیچے ایک اور جھانک کر ایس کیو ایل کے سوالات کو دیکھنے کے لیے جانگو کو دیکھ سکتے ہیں، خاص طور پر ٹیبل بنانے کے لیے۔ CustomUser میز

درج ذیل کمانڈ درج کریں:

python manage.py sqlmigrate notes 0001

یہاں notes یہ ایپ کا نام ہے۔ 0001 منتقلی نمبر کی نشاندہی کرتا ہے۔

اس سے درج ذیل نتائج برآمد ہوں گے۔

آئیے ایک سپر یوزر بھی بنائیں تاکہ ہم بعد میں ڈیبگ کرنے کے لیے ایڈمن پینل تک رسائی حاصل کر سکیں۔

python manage.py createsuperuser

جب اشارہ کیا جائے تو اپنا صارف نام، ای میل (اختیاری) اور پاس ورڈ درج کریں۔

مرحلہ 3: نوٹ ماڈل کی وضاحت کیسے کریں۔

اب آئیے اپنی ایپلیکیشن کے بنیادی حصے کے لیے ڈیٹا ماڈل بنائیں۔ سب سے پہلے، ایک نئی درآمد شامل کرکے settings اعتراض

from django.conf import settings

پھر ذیل میں درج ذیل کوڈ شامل کریں: CustomUser کلاس:

class Notes(models.Model):
    owner = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="notes"
    )
    title = models.CharField(max_length=200)
    body = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    def __str__(self):
        return f"{self.title} (by {self.owner.username})"

یہاں مکمل ایک ہے۔ model.py پاس ورڈ:

from django.contrib.auth.models import AbstractUser
from django.db import models
from django.conf import settings

class CustomUser(AbstractUser):
    pass

class Notes(models.Model):
    owner = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="notes"
    )
    title = models.CharField(max_length=200)
    body = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    def __str__(self):
        return f"{self.title} (by {self.owner.username})"

آئیے ہر ایک فیلڈ کو دیکھیں۔

owner = models.ForeignKey(settings.AUTH_USER_MODEL, ...): ہر نوٹ اور صارف کے درمیان تعلق پیدا کرتا ہے۔ کہ ForeignKey فیلڈ جینگو کو بتاتی ہے کہ ہر نوٹ بالکل ایک صارف کا ہے، لیکن صارف کے پاس بہت سے نوٹ ہو سکتے ہیں۔

ہم جو استعمال کرتے ہیں اس پر توجہ دیں۔ settings.AUTH_USER_MODEL براہ راست درآمد کرنے کے بجائے CustomUser. یہ تجویز کردہ طریقہ ہے کیونکہ یہ آپ کے کوڈ کو لچکدار رکھتا ہے۔ یہ غیر ملکی کلید خود بخود لاگو ہو جاتی ہے جب آپ سیٹنگز میں اپنے صارف ماڈل کا حوالہ تبدیل کرتے ہیں۔

کہ on_delete=models.CASCADE اس کا مطلب یہ ہے کہ جب صارف کو حذف کر دیا جاتا ہے، تو اس صارف کے تمام نوٹس بھی حذف ہو جائیں گے۔

کہ related_name="notes" آپ یہ استعمال کرکے اپنے نوٹس تک رسائی حاصل کرسکتے ہیں: user.notes.all().
title = models.CharField(max_length=200): کام کے نام کے لیے ایک ٹیکسٹ فیلڈ بناتا ہے، زیادہ سے زیادہ 200 حروف تک محدود۔
body = models.TextField(): نوٹ کے اصل مواد پر مشتمل ہے۔ TextField حروف کی کوئی حد نہیں ہے، اس لیے صارف اپنی ضرورت کے مطابق لکھ سکتے ہیں۔
created_at = models.DateTimeField(auto_now_add=True): خود بخود اس تاریخ اور وقت کو ریکارڈ کرتا ہے جب ٹاسک بنایا گیا تھا۔ آپ کو اسے دستی طور پر ترتیب دینے کی ضرورت نہیں ہے۔

کہ __str__() طریقہ ہر نوٹ کی پڑھنے کے قابل نمائندگی فراہم کرتا ہے۔ ایڈمن پینل میں یا ڈیبگ کرتے وقت "نوٹس آبجیکٹ (1)” دیکھنے کے بجائے، آپ کو "میٹنگ نوٹس (سولینا کی تحریر کردہ)” جیسا کچھ نظر آئے گا۔

3.2 ہجرت کا اطلاق کیسے کریں۔

نوٹ ٹیبل بنانے کے لیے مائیگریشن کمانڈ پر عمل کریں۔

python manage.py makemigrations
python manage.py migrate

پہلے کی طرح، آپ بالکل وہی SQL استفسار دیکھ سکتے ہیں جو Django پیدا کرنے کے لیے استعمال کرتا تھا۔ notes میز:

3.3 مینیجر میں ماڈل کو کیسے رجسٹر کریں۔

کھلا notes/admin.py دونوں ماڈلز کو رجسٹر کریں تاکہ آپ ایڈمن پینل کے ذریعے ڈیٹا کا معائنہ کر سکیں۔

from django.contrib import admin
from .models import CustomUser, Notes

admin.site.register(CustomUser)
admin.site.register(Notes)

یہ ترقی کے دوران مفید ہے جب آپ فوری طور پر یہ چیک کرنا چاہتے ہیں کہ آپ کا ڈیٹا صحیح طریقے سے ذخیرہ کیا جا رہا ہے۔

مرحلہ 4: سیریلائزر کیسے بنائیں

DRF میں، سیریلائزر ڈیٹا بیس اور انٹرنیٹ کے درمیان ایک پل کی طرح ہے۔

Django ماڈلز ڈیٹا کو Python آبجیکٹ کے طور پر اسٹور کرتے ہیں۔ تاہم، اگر آپ اس ڈیٹا کو فرنٹ اینڈ ایپلی کیشن (جیسے کہ React یا موبائل ایپ) کو بھیجنا چاہتے ہیں، تو آپ Python آبجیکٹ نہیں بھیج سکتے۔ یقینی بنائیں کہ آپ اسے ایک عام JSON فارمیٹ میں بھیجتے ہیں جسے ہر کوئی سمجھ سکتا ہے۔

ایک سیریلائزر تین اہم کام انجام دیتا ہے:

سیریلائزیشن: پیچیدہ Python اشیاء (ماڈل) کو Python لغات میں تبدیل کریں (جسے آسانی سے JSON کے طور پر پیش کیا جا سکتا ہے)۔
ڈی سیریلائز کرنا: صارف سے آنے والے JSON ڈیٹا کو ایک پیچیدہ Python آبجیکٹ میں تبدیل کریں۔
چیک کریں: تصدیق کرتا ہے کہ آنے والا ڈیٹا ڈیٹا بیس میں محفوظ کرنے سے پہلے درست ہے۔

4.1 یوزر سیریلائزر کیسے بنایا جائے۔

نامی ایک نئی فائل بنائیں notes/serializers.py اور درج ذیل کوڈ شامل کریں:

from rest_framework import serializers
from django.contrib.auth import get_user_model

User = get_user_model()
class UserSerializer(serializers.ModelSerializer):
    password = serializers.CharField(write_only=True)

    class Meta:
        model = User
        fields = ['id', 'username', 'email', 'password']

    def create(self, validated_data):
        user = User.objects.create_user(
            username=validated_data['username'],
            email=validated_data.get('email', ''),
            password=validated_data['password']
        )
        return user

آئیے اس سیریلائزر کا تجزیہ کرتے ہیں۔

کہ UserSerializer صارف کی رجسٹریشن کو ہینڈل کرتا ہے۔
User = get_user_model() آپ جو صارف ماڈل استعمال کر رہے ہیں اسے لیں اور اسے متغیر میں اسٹور کریں۔ User. ہمارے معاملے میں CustomUser ماڈل
class UserSerializer(serializers.ModelSerializer):: یہاں ہم نے ایک UserSerializer کلاس بنائی ہے جو وراثت میں ملتی ہے: ModelSerializer.

کوئی راستہ نہیں ModelSerializer یہ ایک شارٹ کٹ ہے جو ماڈل کلاس میں فیلڈز کا استعمال کرتے ہوئے خود بخود سیریلائزر کلاس تیار کرتا ہے۔

ہم ModelSerializerDRF آپ کے ماڈل کی جانچ کرتا ہے اور خود بخود درج ذیل اعمال انجام دیتا ہے:

1. ہم ماڈل میں فیلڈز بناتے ہیں، لہذا آپ کو کچھ اور کرنے کی ضرورت نہیں ہے۔
2. ماڈل میں موجود فیلڈ کی توثیق کو خودکار طور پر شامل کرتا ہے۔
3. نفاذ create() اور update() طریقے کوئی راستہ نہیں ModelSerializer آپ جانتے ہیں کہ کون سا ماڈل استعمال کرنا ہے اور اسے کس طرح اپ ڈیٹ اور بنانا ہے۔ اوور رائڈ کیا جا سکتا ہے۔ create() اور update() اگر آپ کو حسب ضرورت رویے کی ضرورت ہو تو یہ کیسے کریں۔ تم ہو create() مذکورہ کوڈ میں طریقہ۔
password = serializers.CharField(write_only=True): یہ لائن اہم ہے۔ کہ write_only=True اگرچہ جھنڈا رجسٹریشن کے دوران پاس ورڈ کی اجازت دیتا ہے، مطلقیت تمام API جوابات میں ظاہر ہوتا ہے۔ اس کے بغیر، API ہر بار صارف کا ڈیٹا واپس کرنے پر پاس ورڈ (چاہے ہیش ہو) واپس بھیج دے گا۔

لہذا صارفین اکاؤنٹس بنا سکتے ہیں، لیکن ان کے پاس ورڈ دوبارہ ظاہر نہیں کیے جائیں گے۔
class Meta: اندرونی Meta کلاس سیریلائزر کو بتاتی ہے کہ کون سا ماڈل استعمال کرنا ہے۔ اس صورت میں استعمال کرنے کے لئے ماڈل ہے User اور عمل کرنے کے لیے فیلڈز۔
کہ create() کیسے کریں: یہ سب سے اہم حصہ ہے۔ یہ طریقہ نیا صارف بناتے وقت چلتا ہے۔ پہلے سے طے شدہ استعمال کرنے کے بجائے .create() آپ نے ایک طریقہ کو اوور رائیڈ کیا۔

یہ سمجھنا ضروری ہے کہ یہ طریقہ کیوں اوور رائڈ کیا گیا تھا۔ پہلے سے طے شدہ create() یہ طریقہ صارفین کو محفوظ طریقے سے بنانے کے لیے موزوں نہیں ہے۔

پہلے سے طے شدہ طور پر، یہ طریقہ پاس ورڈز کو سادہ ٹیکسٹ فارمیٹ میں اسٹور کرتا ہے۔ یہ ایک سنگین مسئلہ ہے کیونکہ پاس ورڈز کو خام شکل میں محفوظ نہیں کیا جانا چاہیے۔ انہیں چاہیے ہیش لہذا یہاں تک کہ اگر آپ کے ڈیٹا بیس سے سمجھوتہ کیا جاتا ہے، تو آپ کا پاس ورڈ کبھی بھی سامنے نہیں آئے گا۔

جینگو مندرجہ ذیل خصوصی طریقے فراہم کرتا ہے: create_user() اسے خود بخود ہینڈل کرنے کا طریقہ یہاں ہے: پاس ورڈ ہیشنگ تصدیق کے لیے صارفین کو مناسب طریقے سے ترتیب دیں۔

4.2 نوٹ سیریلائزر کیسے بنایا جائے۔

جب سے UserSerializer آئیے ایک کلاس بنائیں۔ NoteSerializer کلاس کہ NoteSerializer نوٹ ڈیٹا پر کارروائی کریں۔

سب سے پہلے، ہمیں ایک درآمد شامل کرنے کی ضرورت ہے. Notes کلاس ایک لائن شامل کریں from .models import Notes جب آخری درآمد ختم ہوتی ہے۔

براہ کرم اس کوڈ کو نیچے رکھیں UserSerializer کلاس:

class NoteSerializer(serializers.ModelSerializer):
    owner = serializers.ReadOnlyField(source="owner.username")
    class Meta:
        model = Notes
        fields = ['id', 'owner', 'title', 'body', 'created_at']

اب اس کا تجزیہ کرتے ہیں۔

owner = serializers.ReadOnlyField(source="owner.username"): یہ کوڈ میں سب سے اہم لائن ہے۔ یہ ہے owner میدان صرف پڑھیں. اس کا مطلب ہے کہ API دکھائے گا کہ نوٹ کا مالک کون ہے (صارف کا نام دکھا رہا ہے)، لیکن API کے ذریعے کوئی بھی مالک کو سیٹ یا تبدیل نہیں کر سکتا۔

اس تحفظ کے بغیر، بدنیتی پر مبنی صارف درج ذیل کی طرح POST کی درخواست بھیج سکتا ہے۔ "owner": 5 آپ کسی اور کے نوٹس کو ان کے اکاؤنٹ میں تفویض کرکے، یا اس سے بھی بدتر، ملکیت کو دوبارہ تفویض کرکے ان میں ترمیم کرسکتے ہیں۔

کہ source="owner.username" حصہ DRF کو عددی ID کے بجائے مالک کا صارف نام ظاہر کرنے کے لیے کہہ کر API کے جواب کو مزید پڑھنے کے قابل بناتا ہے۔
class Meta: …: پہلے کی طرح Meta کلاس میں وہ ماڈل ہوتا ہے جسے سیریلائزر استعمال کرے گا اور وہ فیلڈز جنہیں API بے نقاب کرے گا۔

یہاں مکمل کوڈ ہے: serializers.py فائل

from rest_framework import serializers
from django.contrib.auth import get_user_model
from .models import Notes

User = get_user_model()
class UserSerializer(serializers.ModelSerializer):
    password = serializers.CharField(write_only=True)
    class Meta:
        model = User
        fields = ['id', 'username', 'email', 'password']

    def create(self, validated_data):
        user = User.objects.create_user(
            username=validated_data['username'],
            email=validated_data.get('email', ''),
            password=validated_data['password']
        )
        return user

class NoteSerializer(serializers.ModelSerializer):
    owner = serializers.ReadOnlyField(source="owner.username")
    class Meta:
        model = Notes
        fields = ['id', 'owner', 'title', 'body', 'created_at']

مرحلہ 5: SimpleJWT کو کنفیگر کرنے کا طریقہ

اب آئیے تصدیق کا نظام ترتیب دیں۔ یہاں ہم DRF سے کہتے ہیں کہ سیشن کی بجائے تصدیق کے لیے JWT استعمال کرے۔ یہ قدم اہم ہے کیونکہ اس کے بغیر، ڈی آر ایف سیشن پر مبنی تصدیق کے لیے ڈیفالٹ ہو جاتا ہے۔

SimpleJWT DRF کے لیے JWT کا مکمل نفاذ فراہم کرتا ہے، لہذا آپ کو شروع سے ٹوکن جنریشن، دستخط کرنے یا تصدیق کرنے کی ضرورت نہیں ہے۔

رسائی ٹوکن وہی ہے جو کلائنٹ ہر API درخواست کے ساتھ بھیجتا ہے۔ ڈیزائن کے لحاظ سے، اس کی عمر مختصر ہے۔ اسے اپنے دفتر کی عمارت میں وزیٹر بیج کی طرح سوچیں۔ آپ دروازے سے گزر سکتے ہیں، لیکن یہ دن کے اختتام پر ختم ہو جاتا ہے۔ اگر کوئی اسے چوری کرتا ہے تو نقصان محدود ہے کیونکہ یہ فوراً کام کرنا بند کر دیتا ہے۔

ریفریش ٹوکن دیرپا ہوتے ہیں اور ان کا صرف ایک مقصد ہوتا ہے: وہ یہ ہے کہ جب موجودہ رسائی ٹوکن کی میعاد ختم ہو جاتی ہے، ایک نیا رسائی ٹوکن حاصل کیا جاتا ہے۔ کلائنٹ اسے محفوظ طریقے سے اسٹور کرتا ہے اور اسے صرف ایک مخصوص اینڈ پوائنٹ پر بھیجتا ہے۔ آپ اسے ملازم کے شناختی کارڈ کی طرح سوچ سکتے ہیں۔ ہم اسے ہر صبح ایک نیا وزیٹر بیج حاصل کرنے کے لیے استعمال کرتے ہیں، لیکن ہم اسے ہر دروازے پر نہیں چمکاتے ہیں۔

یہ علیحدگی سیکورٹی وجوہات کی بناء پر موجود ہے۔ اگر ایک قلیل المدت رسائی ٹوکن سے سمجھوتہ کیا جاتا ہے (جس کا زیادہ امکان ہے کیونکہ اسے ہر درخواست کے ساتھ بھیجا جاتا ہے)، حملہ آور کے پاس اس کی میعاد ختم ہونے سے پہلے ایک مختصر وقت ہوتا ہے۔ ریفریش ٹوکن جو کم کثرت سے بھیجے جاتے ہیں ان میں مداخلت کا خطرہ کم ہوتا ہے۔

آئیے دیکھتے ہیں کہ رسائی ٹوکن اور ریفریش ٹوکن کیسے ایک ساتھ کام کرتے ہیں۔

جب کوئی صارف لاگ ان ہوتا ہے، سرور ایک رسائی ٹوکن اور ریفریش ٹوکن دونوں فراہم کرتا ہے۔
ایک صارف رسائی ٹوکن کا استعمال کرتے ہوئے درخواست کرتا ہے۔
ٹوکن کی میعاد ختم ہونے تک رسائی
ایپ سرور کو ریفریش ٹوکن بھیجتی ہے۔
سرور اس کی تصدیق کرتا ہے اور ایک نیا رسائی ٹوکن فراہم کرتا ہے۔
صارف کے دوبارہ لاگ ان کیے بغیر جاری رکھیں۔

5.1 REST فریم ورک کی ترتیبات کو کیسے اپ ڈیٹ کریں۔

کھلا notes_core/settings.py اور درج ذیل کوڈ شامل کریں:

from datetime import timedelta
REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ),

    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated',
    ),
}

SIMPLE_JWT = {
    'ACCESS_TOKEN_LIFETIME': timedelta(minutes=30),
    'REFRESH_TOKEN_LIFETIME': timedelta(days=1),
}

آئیے ایک نظر ڈالتے ہیں کہ ہر سیکشن کیا کرتا ہے۔

کہ DEFAULT_AUTHENTICATION_CLASSES ترتیب DRF کو ہدایت کرتی ہے کہ JWT کو تمام API اینڈ پوائنٹس کے لیے تصدیقی طریقہ کے طور پر استعمال کرے۔ تمام آنے والی درخواستوں کو اجازت کے ہیڈر میں ایک درست JWT ٹوکن کے لیے چیک کیا جاتا ہے۔

کہ DEFAULT_PERMISSION_CLASSES سیٹ سیٹ IsAuthenticated عالمی اجازتوں کی پالیسی کے ساتھ۔ اس کا مطلب یہ ہے کہ API میں تمام اینڈ پوائنٹس بطور ڈیفالٹ بند ہیں۔ صرف درست ٹوکن والے صارفین ہی تمام اختتامی مقامات تک رسائی حاصل کر سکتے ہیں۔

یہ بنیادی طور پر محفوظ طریقہ ہے۔ ہر نقطہ نظر کو انفرادی طور پر محفوظ کرنے کے لیے یاد رکھنے کے بجائے، ہر چیز محفوظ ہے اور آپ واضح طور پر ان نکات کو کھولتے ہیں جن کو سامنے لانے کی ضرورت ہے۔ (مثلاً رجسٹریشن کا اختتامی نقطہ اگلے مرحلے میں سنبھالا جائے گا)

کہ SIMPLE_JWT لغتیں ٹوکن رویے کو کنٹرول کرتی ہیں۔ رسائی کے ٹوکن 30 منٹ تک رہتے ہیں۔ یہ ایک ٹوکن ہے جسے کلائنٹ ہر درخواست کے ساتھ شامل کرتا ہے۔ اگر کوئی اسے روکتا ہے، تو نقصان 30 منٹ تک محدود ہے۔ ریفریش ٹوکن ایک دن تک رہتے ہیں۔

ایکسیس ٹوکن کی میعاد ختم ہونے پر، صارف کو دوبارہ لاگ ان کیے بغیر نیا رسائی ٹوکن حاصل کرنے کے لیے کلائنٹ ریفریش ٹوکن استعمال کر سکتا ہے۔ ریفریش ٹوکن کی مدت 1 دن ہے۔ اس کا مطلب ہے کہ 1 دن کے بعد، صارف کو اپنا صارف نام اور پاس ورڈ استعمال کرکے دوبارہ لاگ ان کرنا ہوگا۔ جب آپ پوسٹ مین کے ساتھ بعد میں اس کی جانچ کریں گے تو آپ بالکل دیکھیں گے کہ یہ کیسے کام کرتا ہے۔

5.2 ٹوکن یو آر ایل اینڈ پوائنٹ کیسے شامل کریں۔

SimpleJWT ٹوکنز کو حاصل کرنے اور تازہ کرنے کے لیے پہلے سے تیار کردہ نظارے فراہم کرتا ہے۔ بس یو آر ایل سے لنک کریں۔

کھلا notes_core/urls.py درج ذیل کوڈ کے ساتھ اپ ڈیٹ کریں:

from django.contrib import admin
from django.urls import path, include
from rest_framework_simplejwt.views import (
    TokenObtainPairView,
    TokenRefreshView,
)

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('notes.urls')),
    path('api/token/', TokenObtainPairView.as_view(), name="token_obtain_pair"),
    path('api/token/refresh/', TokenRefreshView.as_view(), name="token_refresh"),
]

کہ token/ اختتامی نقطہ صارف نام اور پاس ورڈ کو قبول کرتا ہے اور ایک رسائی ٹوکن اور ریفریش ٹوکن واپس کرتا ہے۔

کہ token/refresh/ اینڈ پوائنٹ ریفریش ٹوکن کو قبول کرتا ہے اور ایک نیا رسائی ٹوکن لوٹاتا ہے۔ آپ جانچ کے دوران ان خصوصیات کو عملی شکل میں دیکھ سکتے ہیں۔

مرحلہ 6: توثیق کی منطق کیسے بنائیں

کھلا notes/views.py اور شامل کریں:

from rest_framework import generics, permissions
from django.contrib.auth import get_user_model
from .serializers import UserSerializer

User = get_user_model()

class RegisterView(generics.CreateAPIView):
    queryset = User.objects.all()
    serializer_class = UserSerializer
    permission_classes = [permissions.AllowAny]

اب اس کوڈ کو دیکھتے ہیں۔

پہلا حصہ درآمد اور اس کے بعد get_user_model() کیسے حاصل کرنا ہے۔ CustomUser ماڈل

اب اہم حصہ ہے RegisterView کلاس کلاس اس سے وراثت میں ملتی ہے: generics.CreateAPIView یہ ایک بلٹ ان DRF ویو ہے جو خاص طور پر POST درخواستوں کو ہینڈل کرنے کے لیے ڈیزائن کیا گیا ہے جو نئی اشیاء تخلیق کرتی ہیں۔

لہذا آپ کو POST کی درخواستوں پر کارروائی کرنے، ڈیٹا کی توثیق کرنے، یا ڈیٹا بیس میں محفوظ کرنے کے لیے دستی طور پر منطق لکھنے کی ضرورت نہیں ہے۔ DRF پردے کے پیچھے سب کچھ کرتا ہے۔

کلاس کے اندر، queryset = Users.objects.all() صارف اشیاء کے سیٹ کی وضاحت کرتا ہے جس کے ساتھ یہ منظر کام کر سکتا ہے۔

کہ serializer_class = UserSerializer منظر کو بتاتا ہے کہ آنے والے ڈیٹا کی توثیق کرنے اور صارفین بنانے کے لیے کون سا سیریلائزر استعمال کرنا ہے۔

آخر میں permission_classes = [permissions.AllowAny] عالمی سطح پر اوور رائیڈ کریں۔ IsAuthenticated اجازتیں پہلے اقدار پر سیٹ کی گئی تھیں۔ DEFAULT_PERMISSION_CLASSES .

اس کا مطلب ہے کہ کوئی بھی رجسٹریشن اینڈ پوائنٹ تک رسائی حاصل کر سکتا ہے، چاہے وہ لاگ ان نہ ہوں۔

API میں موجود دیگر تمام آراء کو عالمی IsAuthenticated اجازت وراثت میں ملتی ہے، اس لیے صرف یہ رجسٹریشن اینڈ پوائنٹ کھولا جاتا ہے۔

مرحلہ 7: اسکوپڈ ویو کو کیسے نافذ کریں۔

یہ سبق کا خلاصہ ہے۔ میں نے تصدیق ترتیب دی ہے تاکہ API کو معلوم ہو۔ ڈبلیو ایچ او آپ ایک درخواست کر رہے ہیں۔ اب ہمیں یہ یقینی بنانا ہوگا کہ ہر صارف صرف اس کے ساتھ تعامل کرسکتا ہے: ان کا اپنے میمو

اس طرح سوچو۔ سرٹیفیکیشن اپارٹمنٹ کی عمارت کے سامنے والے دروازے پر لگا ہوا تالا ہے۔ یہ اجنبیوں کو داخل ہونے سے روکتا ہے۔ تاہم، اسکوپنگ ہر ایک اپارٹمنٹ پر ایک تالا ہے۔ عمارت میں رہنا آپ کو پڑوسی اپارٹمنٹس تک رسائی نہیں دیتا ہے۔

اسکوپنگ کے بغیر، ایک توثیق شدہ صارف ممکنہ طور پر ڈیٹا بیس میں موجود تمام نوٹ دیکھ سکتا ہے، یا اس سے بھی بدتر، ان نوٹوں میں ترمیم کر سکتا ہے جو کسی اور کے ہیں۔ آپ ویو سیٹ میں دو طریقوں کو اوور رائیڈ کر کے اس سے مکمل طور پر بچ سکتے ہیں:

7.1 نوٹ ویو سیٹ کیسے بنایا جائے۔

اب NoteViewSet. سب سے پہلے، ان درآمدات کو فائل کے اوپری حصے میں شامل کریں۔ ویو سیٹس، سیریلائزرز اور ماڈلز درآمد کرنا۔

from .models import Note
from .serializers import UserSerializer, NoteSerializer
from rest_framework import generics, viewsets, permissions

درج ذیل شامل کریں: notes/views.pyرجسٹر ویو کے نیچے:

class NoteViewSet(viewsets.ModelViewSet):
    serializer_class = NoteSerializer

    def get_queryset(self):
        return Notes.objects.filter(owner=self.request.user).order_by('-created_at')

    def perform_create(self, serializer):
        serializer.save(owner=self.request.user)

اب میں اس کوڈ کو مزید تفصیل سے بیان کرتا ہوں۔

میں نے ایک نئی کلاس بنائی جس کا نام ہے۔ NoteViewSet DRF کلاس سے وراثت میں ملا۔ ModelViewSet. یہ مکمل CRUD آپریشن فراہم کرتا ہے۔ اس کا مطلب ہے کہ آپ نوٹوں کی فہرست بنا سکتے ہیں اور سنگل نوٹ تلاش کر سکتے ہیں، نیز نوٹ بنا سکتے ہیں، اپ ڈیٹ کر سکتے ہیں اور حذف کر سکتے ہیں۔

اگلا حصہ serializer_class = NoteSerializer ہم جینگو کو استعمال کرنے کو کہتے ہیں: NoteSerializer ایک کلاس جو Python آبجیکٹ اور JSON کے درمیان تبدیل ہوتی ہے۔

لیکن جادو کی نئی تعریف کرنے کے دو طریقے ہیں۔ get_queryset() اور perform_create().

کہ get_queryset() یہ طریقہ کنٹرول کرتا ہے کہ کون سے API کو نوٹ کرتا ہے۔ اگر آپ اس طریقہ کو اوور رائڈ نہیں کرتے ہیں تو یہ واپس آجائے گا: Note.objects.all() (تمام صارفین کو ڈیٹا بیس میں موجود تمام نوٹوں تک رسائی فراہم کرتا ہے)۔

تاہم، یہاں ہم نے موجودہ صارف کے نوٹس کو فلٹر کرنے کے لیے اس طریقے کو اوور رائڈ کر دیا ہے۔

اگلا ہے۔ perform_create() یہ طریقہ تب کہا جاتا ہے جب کوئی نوٹ محفوظ کیا جاتا ہے۔ میں نے فی الحال لاگ ان صارف کے نوٹس محفوظ کرنے کے لیے اس طریقہ کو اوور رائیڈ کر دیا ہے۔ اگر آپ اس طریقہ کو اوور رائڈ نہیں کرتے ہیں، تو یہ لاگ ان صارف سے قطع نظر تمام نوٹ واپس کر دے گا۔

ہم آپ کو مطلع کرنا چاہتے ہیں کہ آپ نے امتحان پاس کر لیا ہے۔ self.request.user پیرامیٹرز filter() فنکشن یہ کوڈ لاگ ان صارف کو نوٹ کے مالک کے طور پر منسلک کرتا ہے۔

یاد رکھیں کہ ہم نے مالک فیلڈ کو سیریلائزر میں صرف پڑھنے کے لیے کیسے بنایا؟ یہ حفاظتی اقدامات کا دوسرا نصف ہے۔

صارف API کی درخواست کے ذریعے مالک کو متعین نہیں کر سکتے ہیں اور سرور خود بخود مالک کو تصدیق شدہ شخص پر سیٹ کر دیتا ہے۔ یہ دونوں حصے اس بات کو یقینی بنانے کے لیے مل کر کام کرتے ہیں کہ ملکیت کے ساتھ چھیڑ چھاڑ نہ ہو۔

7.2 یہ کیوں ضروری ہے: ID شماری کے حملوں کو روکنا

get_queryset فلٹرنگ کے بغیر، API اجازت دے سکتا ہے: صارف GET کی درخواست کرتا ہے۔ /api/notes/42/ آپ کو کسی اور کا نوٹ نظر آتا ہے کیونکہ آپ نے ان کی شناخت کا اندازہ لگایا تھا۔

یہ شناختی گنتی پر حملہ — حملہ آور دوسرے لوگوں کے ڈیٹا کو دریافت کرنے اور ان تک رسائی حاصل کرنے کے لیے IDs (1, 2, 3, 4…) کے ذریعے چکر لگاتے ہیں۔

دائرہ کار get_querysetیہاں تک کہ اگر صارف B کو درخواست بھیجتا ہے۔ /api/notes/42/ نوٹ 42 کا تعلق صارف A سے ہے، لہذا ویو سیٹ اسے صارف B کے فلٹر کردہ سوال سیٹ میں نہیں ڈھونڈ سکتا۔ DRF 404 واپس کرتا ہے۔ جہاں تک صارف B کا تعلق ہے، وہ نوٹ موجود نہیں ہے۔

مرحلہ 8: یو آر ایل کو کیسے جوڑیں۔

اب ہمیں آراء کو یو آر ایل پاتھز کے ساتھ جوڑنے کی ضرورت ہے تاکہ API کو معلوم ہو کہ ہر اینڈ پوائنٹ کے لیے کون سا ویو کال کرنا ہے۔

8.1 ایپ لیول یو آر ایل کیسے بنائیں

نامی ایک نئی فائل بنائیں notes/urls.py اور شامل کریں:

from django.urls import path, include
from rest_framework.routers import DefaultRouter
from .views import RegisterView, NoteViewSet

router = DefaultRouter()
router.register(r'notes', NoteViewSet, basename="note")

urlpatterns = [
    path('register/', RegisterView.as_view(), name="register"),
    path('', include(router.urls)),
]

کہ DefaultRouter NoteViewSet کے لیے خود بخود ایک URL پیٹرن تیار کرتا ہے۔ کیونکہ آپ استعمال کر رہے ہیں۔ ModelViewSetروٹر تمام نوٹوں کی فہرست بنانے، نوٹ بنانے، ایک نوٹ کو بازیافت کرنے، نوٹوں کو اپ ڈیٹ کرنے، اور نوٹوں کو حذف کرنے کے لیے اختتامی نقطے بناتا ہے۔ یہ سب ایک ہی راؤٹر رجسٹر کال میں ہوتا ہے۔

کہ basename="note" یہاں پیرامیٹر کی ضرورت ہے کیونکہ ویو سیٹ میں کلاس پر براہ راست بیان کردہ سوال سیٹ کی خصوصیات نہیں ہوتی ہیں۔ (میں اس کے بجائے get_queryset استعمال کر رہا ہوں). DRF ہے۔ basename یو آر ایل پیٹرن کا نام اس طرح تیار کرنے کے لیے: note-list اور note-detail.

8.2 پروجیکٹ لیول یو آر ایل کو کیسے چیک کریں۔

آپ کا notes_core/urls.py ایسا لگتا ہے (ہم نے اسے مرحلہ 5 میں ترتیب دیا ہے، لیکن آئیے اسے چیک کریں):

from django.contrib import admin
from django.urls import path, include
from rest_framework_simplejwt.views import (
    TokenObtainPairView,
    TokenRefreshView,
)

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('notes.urls')),
    path('api/token/', TokenObtainPairView.as_view(), name="token_obtain_pair"),
    path('api/token/refresh/', TokenRefreshView.as_view(), name="token_refresh"),
]

API کے URL ڈھانچے کی مکمل تصویر یہ ہے:

اختتامی نقطہ	طریقہ	وضاحت
`api/register/`	میل	ایک نیا صارف اکاؤنٹ بنائیں
`api/token/`	میل	رسائی حاصل کریں اور ٹوکن ریفریش کریں۔
`api/token/refresh/`	میل	ریفریش ٹوکن کا استعمال کرتے ہوئے ایک نیا رسائی ٹوکن حاصل کریں۔
`api/notes/`	حاصل کریں	ایک مستند صارف کے لیے تمام نوٹ درج کریں۔
`api/notes/`	میل	ایک نیا نوٹ بنائیں
`api/notes//`	حاصل کریں	مخصوص نوٹ تلاش کریں۔
`api/notes//`	پٹ/پیچ	مخصوص نوٹس کو اپ ڈیٹ کریں۔
`api/notes//`	حذف کریں	ایک مخصوص نوٹ حذف کریں۔

ڈویلپمنٹ سرور شروع کریں اور یقینی بنائیں کہ سب کچھ بغیر کسی غلطی کے چلتا ہے۔

python manage.py runserver

اگر سرور شکایت کیے بغیر شروع ہوتا ہے، تو آپ کا کوڈ صحیح طریقے سے جڑا ہوا ہے۔

مرحلہ 9: پوسٹ مین کے ساتھ اپنے API کی جانچ کیسے کریں۔

API بنانا ایک چیز ہے۔ یہ ثابت کرنا ایک اور چیز ہے کہ یہ کام کرتا ہے۔ آئیے پوسٹ مین کا استعمال کرتے ہوئے صارف کی رجسٹریشن سے لے کر اسکوپنگ کو عملی جامہ پہنانے تک پورے بہاؤ پر چلتے ہیں۔

اگر آپ نے پہلے کبھی پوسٹ مین کا استعمال نہیں کیا ہے، تو یہ ایک ایسا ٹول ہے جو آپ کو HTTP درخواستیں API کو بھیجنے اور جواب کا معائنہ کرنے دیتا ہے۔ آپ اسے postman.com/downloads پر ڈاؤن لوڈ کر سکتے ہیں۔

متبادل طور پر، آپ کمانڈ لائن یا کسی دوسرے مانوس API ٹیسٹنگ ٹول سے curl استعمال کر سکتے ہیں۔

جاری رکھنے سے پہلے یقینی بنائیں کہ آپ کا ڈیولپمنٹ سرور چل رہا ہے۔

9.1 صارف کو رجسٹر کرنے کا طریقہ

پوسٹ مین کھولیں:

ایک نئی درخواست بنائیں۔

طریقہ	میل
URL	`http://127.0.0.1:8000/api/register/`
باڈی ٹیب	"را” کو منتخب کریں اور ڈراپ ڈاؤن سے "JSON” کو منتخب کریں۔
جسمانی مواد	{ "صارف کا نام”: "پریا”، "ای میل”: "priya@example.com”، "password”: "securepassword123” }

کلک کریں جانے دو. تم ہو 201 Created صارف کے ڈیٹا کے ساتھ جواب دیں۔ (بغیر پاس ورڈ کےشکریہ write_only=True میدان) UserSerializer کلاس

9.2 رسائی حاصل کرنے اور ٹوکنز کو ریفریش کرنے کا طریقہ

اب لاگ ان کریں اور اپنا JWT حاصل کریں۔

طریقہ	میل
URL	`http://127.0.0.1:8000/api/token/`
جسم	{"username”: "priya”, "password”: "securepassword123”}

آپ کو رسائی اور ریفریش ٹوکنز پر مشتمل جواب موصول ہوگا۔

رسائی ٹوکن کاپی کریں۔ آپ کو مستقبل کی تمام درخواستوں کے لیے اس معلومات کی ضرورت ہوگی۔ آئندہ استعمال کے لیے ریفریش ٹوکن کو بھی محفوظ کریں۔

JWT صرف انکوڈ شدہ ہے، انکرپٹڈ نہیں۔ انکوڈنگ ڈیٹا کو محفوظ، معیاری سٹرنگ فارمیٹ میں تبدیل کرنے کا ایک طریقہ ہے جسے انٹرنیٹ پر آسانی سے منتقل کیا جا سکتا ہے۔

کوئی بھی انکوڈنگ کے ذریعے ڈیٹا دیکھ سکتا ہے۔ یہ base64url انکوڈنگ کا استعمال کرتے ہوئے کیا جاتا ہے۔

آپ Python لائبریریاں استعمال کر سکتے ہیں۔ pyjwt JWT کو ڈی کوڈ کریں یا اسے ڈی کوڈ کرنے کے لیے آن لائن سائٹ استعمال کریں۔ یہ نوٹ کرنا ضروری ہے کہ JWTs میں حساس معلومات ہوسکتی ہیں اور آپ کو آن لائن سائٹس کو احتیاط کے ساتھ استعمال کرنا چاہیے۔

یہ ڈیمو jwt.io نامی سائٹ استعمال کرتا ہے۔

سائٹ کھولیں اور رسائی ٹوکن کو پیسٹ کریں جو آپ نے ابھی بنایا ہے۔

JWT تین حصوں پر مشتمل ہے: ہیڈر، پے لوڈ، اور دستخط۔

ہیڈرز سیکشن آپ کو بتاتا ہے کہ ہیڈرز پر کیسے دستخط کیے جاتے ہیں۔ اس صورت میں یہ استعمال کرتے ہوئے دستخط کیا جاتا ہے: HS256 حساب

پے لوڈ وہ جگہ ہے جہاں اصل ڈیٹا یا دعوے رہتے ہیں۔ ٹوکن کی قسم، میعاد ختم ہونے کا وقت ( exp اشاعت کا وقت ( iat ) اور حسب ضرورت دعوے کریں۔

دستخط والے حصے کو سالمیت کی تصدیق کے لیے استعمال کیا جاتا ہے۔ آپ اسے معنی خیز ڈیٹا میں ڈی کوڈ نہیں کیا جا سکتا۔ یہ سیکشن تصدیق کرتا ہے کہ ٹوکن کے ساتھ چھیڑ چھاڑ نہیں کی گئی ہے۔

9.3 نوٹ کیسے لکھیں۔

اب اپنے رسائی ٹوکن کا استعمال کرتے ہوئے ایک نوٹ بنائیں۔

طریقہ	میل
URL	`http://127.0.0.1:8000/api/notes/`
ہیڈر ٹیب:	ایک نیا ہیڈر شامل کریں۔
کلید: اختیار کرنا، قدر: بردار
جسم	{‘title’: ‘My Note’, ‘body’: ‘خفیہ معلومات پر مشتمل ہے۔’}

مالک فیلڈ شامل نہیں ہے۔ یہ Perform_create کے ذریعے خود بخود سنبھالا جاتا ہے۔ تم ہو 201 Created response:

آپ کچھ مزید نوٹس بنا سکتے ہیں تاکہ آپ کے پاس کام کرنے کے لیے ڈیٹا موجود ہو۔

9.4 نوٹ کیسے لسٹ کریں۔

اب، پریا کے تمام نوٹ حاصل کرنے کے لیے، ان مراحل پر عمل کریں:

طریقہ	حاصل کریں
URL	`http://127.0.0.1:8000/api/notes/`
ہیڈر ٹیب:	ایک ہی اجازت: بیئرر ہیڈر

تمام تخلیق کردہ نوٹ تازہ ترین سے شروع کرکے ترتیب کے ساتھ دکھائے جائیں گے۔

9.5 سکوپنگ کا مظاہرہ کیسے کریں۔

آئیے ثابت کرتے ہیں کہ دوسرا صارف پہلے صارف کے نوٹ نہیں دیکھ سکتا۔

سب سے پہلے، دوسرے صارف کو رجسٹر کریں۔

پوسٹ کی درخواست بھیجیں۔ http://127.0.0.1/api/register درج ذیل ڈیٹا کے ساتھ:

طریقہ	میل
URL	`http://127.0.0.1:8000/api/register/`
باڈی ٹیب	"را” کو منتخب کریں اور ڈراپ ڈاؤن سے "JSON” کو منتخب کریں۔
جسمانی مواد	{ "صارف کا نام”: "sujan”، "email”: "sujan@example.com”، "password”: "anotherpassword123” }

پھر ہم سوجن کے لیے ٹوکن حاصل کرنے کے لیے POST کی درخواست بھیجتے ہیں۔ http://127.0.0.1:8000/api/token/ سوجن کے رسائی ٹوکن کو اس کی اسناد (صارف کا نام اور پاس ورڈ) استعمال کرتے ہوئے کاپی کریں۔

اب ایک GET درخواست بھیجیں۔ http://127.0.0.1:8000/api/notes/ ہم اجازت کے ہیڈر میں سوجن کا ٹوکن استعمال کرتے ہیں۔

اس صارف نے کوئی نوٹ نہیں بنایا، اس لیے جواب ایک خالی فہرست ہونا چاہیے۔

اس سے بھی اہم بات یہ ہے کہ پریا کا نوٹ اس کے لیے مکمل طور پر پوشیدہ ہے۔ یہاں تک کہ اگر سوجن ID کے ذریعہ کسی مخصوص نوٹ تک رسائی حاصل کرنے کی کوشش کرتا ہے – جیسے http://127.0.0.1:8000/api/notes/1/ – وہ حاصل کرے گا 404 Not Found جواب نہیں 403 Forbidden.

یہ جان بوجھ کر ہے۔ کوئی راستہ نہیں 404 Not Found اگرچہ یہ ظاہر نہیں کرتا کہ نوٹ موجود ہے۔ 403 Forbidden یہ ممکنہ حملہ آوروں کے لیے اس کے وجود کی تصدیق کرتا ہے۔

کوئی راستہ نہیں 403 Forbidden جواب ایک نشان کے ساتھ دروازے کی طرح ہے۔ "صرف مجاز اہلکار”۔ اب آپ جانتے ہیں کہ اندر کی چیز وہی ہے جو شمار کرتی ہے۔ کوئی راستہ نہیں 404 Not Found ردعمل ایک خالی دیوار کی طرح ہے. آپ کو یہ بھی نہیں معلوم کہ کمرہ موجود ہے۔

اب ہم کیوں 404 اس کے بجائے جواب دیں 403میں آپ کو یہ دکھاتا ہوں۔

سب سے پہلے، آئیے اس کی اسناد اور رسائی ٹوکن کا استعمال کرتے ہوئے پریا کے انفرادی نوٹس تک رسائی حاصل کریں۔

اب ایکسیس ٹوکن کو تبدیل کریں اور سوجن (نئے صارف) کا ایکسیس ٹوکن داخل کریں۔

اگر آپ پرانے صارف کے نوٹوں تک رسائی کے لیے نئے صارف کا ٹوکن استعمال کرتے ہیں، تو آپ یہ ہوتا دیکھ سکتے ہیں: 404 Not Found جواب

مرحلہ 10: ریفریش ٹوکنز کا استعمال کرتے ہوئے ٹوکن کی میعاد ختم ہونے کو کیسے ہینڈل کریں۔

رسائی ٹوکن جان بوجھ کر قلیل المدتی ہیں (ہماری ترتیب میں 30 منٹ)۔ اگر ٹوکن چوری ہو جائے تو یہ نقصان کی حد کو محدود کرتا ہے۔

تاہم، آپ نہیں چاہتے کہ صارفین ہر 30 منٹ میں اپنی اسناد دوبارہ درج کریں۔ ریفریش ٹوکن اس کے لیے ہیں۔

جب پریا کے رسائی ٹوکن کی میعاد ختم ہو جاتی ہے، تو اس کی API کی درخواستیں واپس آنا شروع ہو جاتی ہیں۔ 401 Unauthorized جواب دوبارہ لاگ ان کرنے کے بجائے، کلائنٹ ایک نیا رسائی ٹوکن حاصل کرنے کے لیے ریفریش ٹوکن بھیجتا ہے۔

طریقہ	میل
URL	`http://127.0.0.1:8000/api/token/refresh/`
باڈی ٹیب	"را” کو منتخب کریں اور ڈراپ ڈاؤن سے "JSON” کو منتخب کریں۔
جسمانی مواد	{ ریفریش: < Priya's refresh token >}

اپنے پرانے رسائی ٹوکن کو ایک نئے سے تبدیل کرنے سے آپ کو مزید 30 منٹ کا استعمال ملے گا۔ ریفریش ٹوکن بذات خود ایک دن تک رہتا ہے، لہذا صارفین کو ہر 24 گھنٹے میں صرف ایک بار مکمل طور پر لاگ ان کرنے کی ضرورت ہوتی ہے۔

ایک حقیقی ایپلی کیشن میں، فرنٹ اینڈ کلائنٹ اسے خود بخود ہینڈل کرتا ہے۔ API کال 401کلائنٹ اسے پکڑتا ہے، نیا رسائی ٹوکن حاصل کرنے کے لیے ریفریش ٹوکن بھیجتا ہے، اور پھر اصل درخواست پر دوبارہ کوشش کرتا ہے۔ یہ سب کچھ صارف کے نوٹس کیے بغیر ہوتا ہے۔

سیڈوکوڈ میں، متعلقہ بہاؤ مندرجہ ذیل ہے:

کلائنٹ رسائی ٹوکن کے ساتھ ایک درخواست بھیجتا ہے۔
سرور 401 (ٹوکن کی میعاد ختم) کے ساتھ جواب دیتا ہے۔
کلائنٹ /api/token/refresh/ کو ریفریش ٹوکن بھیجتا ہے۔
سرور ایک نئے رسائی ٹوکن کے ساتھ جواب دیتا ہے۔
کلائنٹ نئے رسائی ٹوکن کا استعمال کرتے ہوئے اصل درخواست کی دوبارہ کوشش کرتا ہے۔
سرور ڈیٹا کے ساتھ جواب دیتا ہے۔

اگر ریفریش ٹوکن کی میعاد ختم ہو گئی ہے (آپ کی ترتیب میں 24 گھنٹے کے بعد)، پھر مرحلہ 4 میں بھی 401. اس مقام پر، صارف کو اپنا صارف نام اور پاس ورڈ استعمال کرکے دوبارہ لاگ ان کرنا ہوگا۔ یہ ڈیزائن کے لحاظ سے ہے۔ اس کا مطلب ہے کہ چوری شدہ ریفریش ٹوکن کی بھی محدود مفید زندگی ہوتی ہے۔

ہم اس منصوبے کو کیسے بہتر بنا سکتے ہیں؟

یہ API فعال اور محفوظ ہے، لیکن اس پر تعمیر کرنے کے لیے کافی گنجائش ہے۔ یہاں کچھ رہنما خطوط ہیں جو آپ لے سکتے ہیں:

تلاش اور فلٹرنگ شامل کریں۔ صارف عنوان یا باڈی ٹیکسٹ کے ذریعہ نوٹ تلاش کرسکتے ہیں۔ DRF کے SearchFilter اور django-filter کا استعمال کرتے ہوئے، آپ درج ذیل استفسار کے پیرامیٹرز کو شامل کر سکتے ہیں: ?search=meeting نوٹ لسٹ اینڈ پوائنٹ پر جائیں۔
زمرے یا ٹیگز شامل کریں۔ بنانا Category ایک ماڈل شامل کریں غیر ملکی کلید کو Noteمتبادل طور پر، ٹیگز میں متعدد سے کئی رشتہ استعمال کریں۔ یہ صارفین کو اپنے نوٹوں کو ترتیب دینے اور زمرہ کے لحاظ سے فلٹر کرنے کی اجازت دیتا ہے۔
صفحہ بندی شامل کریں۔ اگر کسی صارف کے پاس سینکڑوں نوٹ ہیں تو ان سب کو ایک ہی جواب میں واپس کرنا سست ہو جاتا ہے۔ DRF میں صفحہ بندی کی ایک بلٹ ان کلاس ہے جو 10 صفحات، 20 صفحات یا جس سائز کے بھی آپ چاہیں نوٹ واپس کر سکتی ہے۔
پروڈکشن سرورز پر تعینات کریں۔ API فی الحال آپ کی مقامی مشین پر چلتا ہے۔ کہیں بھی رسائی کے لیے PythonAnywhere، Railway، یا Render جیسے پلیٹ فارمز پر تعینات کریں۔ آپ کو ایک پروڈکشن ڈیٹا بیس (مثلاً PostgreSQL) ترتیب دینے کی ضرورت ہے، ایک محفوظ SECRET_KEY سیٹ کریں، اور HTTPS کے پیچھے اپنی درخواست پیش کریں۔
ایک فرنٹ اینڈ بنائیں۔ اپنے React، Next.js، یا Vue.js فرنٹ اینڈ کو اس API سے مربوط کریں۔ JWT کو کلائنٹ پر اسٹور کریں اور صارفین کو بغیر کسی رکاوٹ کے لاگ ان رکھنے کے لیے ٹوکن ریفریش فلو نافذ کریں۔
ٹوکن بلیک لسٹ شامل کریں۔ SimpleJWT ٹوکن بلیک لسٹنگ کی حمایت کرتا ہے، جو صارف کے لاگ آؤٹ ہونے پر ریفریش ٹوکن کو باطل کر سکتا ہے۔ اس کے بغیر، ریفریش ٹوکن اس وقت تک درست رہے گا جب تک کہ اس کی میعاد ختم نہ ہو جائے، صارف کے "لاگ آؤٹ” ہونے کے بعد بھی۔

ان میں سے ہر ایک اضافہ ان نمونوں پر بناتا ہے جو آپ پہلے ہی سیکھ چکے ہیں اور Django، DRF، اور API ڈیزائن کے بارے میں آپ کی سمجھ کو مزید گہرا کرتا ہے۔

نتیجہ

ہم نے Django، Django REST Framework، اور SimpleJWT کا استعمال کرتے ہوئے ایک مکمل خصوصیات والا، محفوظ نوٹ لینے والا API بنایا ہے۔ راستے میں، میں نے کچھ بنیادی تصورات سیکھے جو مستقبل میں میرے بنائے ہوئے کسی بھی API پر لاگو ہوں گے۔

ہم نے ایک حسب ضرورت صارف ماڈل کے ساتھ آغاز کیا۔ شروع میں چھوٹے فیصلے بعد میں مشکل ہجرت سے بچنے میں آپ کی مدد کر سکتے ہیں۔ ہم نے JWT توثیق کو ترتیب دیا ہے تاکہ ہمارا API ایک فرنٹ اینڈ فراہم کر سکے جو موبائل کلائنٹس سے الگ ہو جو سیشن کوکیز پر انحصار نہیں کر سکتے۔

ہم نے ایک سیریلائزر بنایا ہے جو پاس ورڈ کو صرف لکھنے اور ملکیت کو صرف پڑھنے کے لیے رکھ کر حساس ڈیٹا کی حفاظت کرتا ہے۔ سب سے اہم بات، ہم نے دائرہ نظر کو نافذ کیا تاکہ ہر صارف کا ڈیٹا دیگر تمام صارفین کے ڈیٹا سے مکمل طور پر الگ ہو جائے۔

یہاں پر عمل کیے جانے والے پیٹرن – دوبارہ تعریف get_queryset موجودہ صارف کی بنیاد پر فلٹر اور اوور رائڈ کریں۔ perform_create خود بخود ملکیت تفویض کریں اور read-only ڈیٹا ٹمپرنگ کو روکنے کے لیے استعمال کیے جانے والے فیلڈز وہی پیٹرن ہیں جو پروڈکشن APIs میں استعمال ہوتے ہیں جو حقیقی صارف کے ڈیٹا پر کارروائی کرتے ہیں۔

جو کچھ آپ نے سیکھا ہے اسے مضبوط کرنے کا بہترین طریقہ یہ ہے کہ اس پر تعمیر کرتے رہیں۔ تلاش اور فلٹرنگ کو شامل کرنے کی کوشش کریں، ایک React فرنٹ اینڈ بنائیں جو اس API کو استعمال کرے، یا مکمل طور پر نیا پروجیکٹ شروع کریں، جیسے کہ ٹاسک مینیجر، جرنل ایپ، یا بک مارک API جو ایک جیسے JWT اور اسکوپنگ پیٹرن کا استعمال کرتا ہے۔ بنیادی ورک فلو وہی رہتا ہے۔ صرف ماڈل اور کاروباری منطق بدلتے ہیں۔