Django middleware — Django ilovasiga kirayotgan HTTP so‘rov va undan chiqayotgan HTTP javobni umumiy qoidalar asosida qayta ishlaydigan komponentdir. Middleware muayyan viewga tegishli bo‘lmagan vazifalarni, masalan sessionni yuklash, autentifikatsiya holatini aniqlash, xavfsizlik sarlavhalarini qo‘shish yoki so‘rov vaqtini o‘lchashni markazlashtiradi.
Zanjir tuzilishi
Middlewarelar settings.py faylidagi MIDDLEWARE ro‘yxatida tartib bilan ko‘rsatiladi. So‘rov ro‘yxat bo‘ylab yuqoridan pastga o‘tadi. View javob qaytargach, javob middlewarelar orqali teskari tartibda chiqadi. Shu sababli birinchi middleware butun keyingi zanjirni o‘rab turadi.
Oddiy funksiya ko‘rinishidagi middleware quyidagicha yoziladi:
def request_id_middleware(get_response):
def middleware(request):
request.request_id = request.headers.get("X-Request-ID")
response = get_response(request)
if request.request_id:
response["X-Request-ID"] = request.request_id
return response
return middleware
Tashqi funksiya server ishga tushganda get_responseni qabul qiladi. Ichki funksiya esa har so‘rovda bajariladi. get_response(request) keyingi middleware yoki viewni chaqiradi.
Tartibga bog‘liq xatti-harakat
Standart AuthenticationMiddleware foydalanuvchini aniqlash uchun session ma’lumotiga tayanadi, shuning uchun SessionMiddleware undan oldin turadi. Xuddi shunday, xabarlar tizimi session yoki cookiega bog‘liq bo‘lishi mumkin. Noto‘g‘ri tartib atributning mavjud emasligi, noto‘liq autentifikatsiya yoki javob sarlavhalarining yo‘qolishiga sabab bo‘ladi.
Middleware javobni viewgacha bormasdan ham qaytarishi mumkin. Masalan, ruxsat etilmagan host, ortiqcha so‘rov yoki texnik xizmat rejimi aniqlansa, zanjir qisqa tutashadi. Pastdagi middlewarelar va view bunday holatda ishlamaydi.
Standart komponentlar
Django xavfsizlik, session, umumiy HTTP tuzatishlari, CSRF, autentifikatsiya, xabarlar va clickjacking himoyasi uchun middlewarelar beradi. Ularning har biri alohida sozlama va talabga ega. CSRF middleware xavfli HTTP usullarida tokenni tekshiradi; SecurityMiddleware esa HSTS va boshqa xavfsizlik sarlavhalarini boshqarishi mumkin.
Sinxron va asinxron moslik
Zamonaviy Django sinxron hamda asinxron request pipeline bilan ishlaydi. Custom middleware qaysi rejimlarni qo‘llashini frameworkga bildirishi kerak. Sinxron komponent asinxron zanjirda ishlatilsa, Django moslashtirish bajarishi mumkin, ammo ko‘p rejim almashinuvi qo‘shimcha xarajat tug‘diradi. Uzoq bloklovchi amal har so‘rovda bajarilsa, umumiy latency oshadi.
Qo‘llanish chegaralari
Middleware barcha endpointlarga taalluqli kesishuvchi vazifalar uchun mos. Muayyan biznes qoidasini middlewarega joylash esa oqimni yashirishi va testni murakkablashtirishi mumkin. Masalan, maqola narxini hisoblash view yoki domen xizmatiga tegishli, request ID yaratish esa middleware vazifasidir. Kiritilgan ma’lumot, log va xatolar test client orqali tekshiriladi.
Streaming javoblar
Oddiy HttpResponse tanasi xotirada mavjud bo‘ladi, StreamingHttpResponse esa kontentni iterator orqali qismlarga bo‘lib yuboradi. Middleware streaming javobning content atributiga oddiy javobdek murojaat qila olmaydi. U zarur bo‘lsa streaming_contentni o‘rab, har bo‘lakka mos ishlov beradi, biroq butun oqimni xotiraga yig‘ish streaming maqsadini buzadi. Fayl yoki uzoq oqim yuborilganda javobning haqiqiy tugash vaqti middleware funksiyasi qaytgan vaqtdan farq qilishi mumkin. Shuning uchun latency o‘lchovi, resursni yopish va xatoni qayd etish streaming semantikasini hisobga oladi.
Template response bosqichi
Ba’zi viewlar darhol tayyor body emas, keyin render qilinadigan TemplateResponse qaytaradi. Eski uslubdagi middleware hooklari va zamonaviy zanjirda response rendering va exception qayta ishlash bosqichlari farqlanadi. Custom komponent qaysi turdagi javobni qabul qilishini aniq bilishi kerak. Javobga header qo‘shish odatda bodyni o‘qishni talab qilmaydi, kontentni o‘zgartirish esa streaming va siqish tartibi bilan to‘qnashishi mumkin.
Bog‘liq tushunchalar
Django, request pipeline, HTTP request, HTTP response, CSRF, session, ASGI