Authorization — kirishni nazorat qilish

Oldingi bo‘limda server foydalanuvchini tanishni o‘rgandi. Endi har bir so‘rovda "bu kim?" degan savolga javob bor. Lekin bu yetarli emas.

Kutubxona ilovasini tasavvur qiling. Aziza tizimga kirdi va token oldi. U kitoblar ro‘yxatini ko‘ra oladimi? Albatta. O‘zi qo‘shgan kitobni tahrirlay oladimi? Ha. Boshqa foydalanuvchining kitobini o‘chira oladimi? Yo‘q. Barcha foydalanuvchilar ro‘yxatini ko‘ra oladimi? Faqat u administrator bo‘lsa.

Bu savollarga avtorizatsiya (authorization) javob beradi: tanilgan foydalanuvchiga nimaga ruxsat berilgan?

Nima uchun bu alohida bo‘lim?

Avtorizatsiyadagi xatolar veb-ilovalardagi eng keng tarqalgan va eng xavfli zaifliklar qatoriga kiradi. OWASP Top 10 ro‘yxatida Broken Access Control, ya’ni buzilgan kirish nazorati birinchi o‘rinda turadi.

Odatiy xatolar oddiy ko‘rinadi:

• GET /orders/1001 o‘rniga GET /orders/1002 yozib, boshqa odamning buyurtmasini ko‘rish;
• frontend’da admin tugmasi yashirilgan, lekin API endpointi hammaga ochiq;
• foydalanuvchi o‘z profilini yangilayotganda "role": "admin" yuborib, o‘ziga administrator huquqini berish.

Bularning hech biri murakkab hujum emas. Barchasi server tomonida bitta tekshiruv unutilgani sababli yuz beradi.

Nimani o‘rganamiz?

Dars	Mavzu
Authorization nima?	Asosiy tushunchalar, modellar va tamoyillar
RBAC	Rollarga asoslangan ruxsatlar
Resource-based permission modeli	Resursga egalik: "faqat o‘z kitobingizni tahrirlay olasiz"
Middleware orqali ruxsat tekshirish	Ruxsatlarni middleware bilan tekshirish
401, 403 va 500 statuslar	Qaysi holatda qaysi status kod qaytariladi

Umumiy sxema

Bo‘lim oxirida har bir so‘rov quyidagi yo‘ldan o‘tadi:

So‘rov
  │
  ↓
Auth middleware ──── token yo‘q yoki yaroqsiz ───→ 401 Unauthorized
  │  foydalanuvchi: {id: 7, role: "author"}
  ↓
Ruxsat middleware ─── rolda "books:create" yo‘q ──→ 403 Forbidden
  │
  ↓
Handler
  │  kitobni bazadan oladi
  ↓
Egalik tekshiruvi ──── kitob boshqa odamniki ─────→ 403 Forbidden
  │
  ↓
200 OK

Tekshiruvlar ikki darajada bajariladi:

1. Endpoint darajasi — foydalanuvchi bu turdagi amalni umuman bajara oladimi? Masalan, "kitob yaratish". Bu tekshiruv middleware’da, handler ishga tushishidan oldin bajariladi.
2. Resurs darajasi — foydalanuvchi aynan shu resurs ustida amal bajara oladimi? Masalan, "42-kitobni o‘chirish". Buning uchun resursni bazadan o‘qib, uning egasini bilish kerak. Shuning uchun bu tekshiruv handler yoki service ichida bajariladi.

Oldindan kerakli bilimlar

Bu bo‘lim Authentication bo‘limining davomi. Ayniqsa Auth middleware yozish darsidagi Principal turi va PrincipalFrom funksiyasi keyingi darslarda qayta-qayta ishlatiladi.

Birinchi darsda avtorizatsiya tushunchalari va asosiy modellar bilan tanishamiz.