WisarWisar
Dasturlash kitobi/5-QISM — Nodejs16 daqiqa

5.17-bob: Authorization — RBAC (role-based access control)

5-QISM — Node.js Backend · 17-mavzu

1. Kirish va motivatsiya

5.15 va 5.16-boblarda authentication (foydalanuvchi kimligini aniqlash) ni o'rgandik. Endi ikkinchi yarmiga — authorization (avtorizatsiya — "kimga nimaga ruxsat bor?") ga o'tamiz. Bu ikkisi har doim birga: avval "kim siz?" (auth), keyin "bu ishni qilishga haqlimisiz?" (authorization).

O'ylab ko'ring: e-commerce ilovasida oddiy foydalanuvchi o'z buyurtmasini ko'radi, lekin boshqalarning buyurtmasini emas, mahsulot qo'sha olmaydi. Admin esa hamma narsani ko'radi, mahsulot qo'shadi/o'chiradi, foydalanuvchilarni boshqaradi. Moderator — faqat sharhlarni nazorat qiladi. Har bir foydalanuvchiga alohida ruxsat berish — chidab bo'lmas (minglab foydalanuvchi). Yechim — rol (role): foydalanuvchilarni guruhlarga bo'lib, ruxsatni rolga bog'lash. Bu — RBAC (Role-Based Access Control) — rollarga asoslangan ruxsat nazorati.

Avtorizatsiyasiz ilova — falokat (14): har kim har narsani qila oladi. Oddiy foydalanuvchi /admin/delete-all ga so'rov yuborib, hamma narsani o'chirishi mumkin. Shuning uchun har himoyalangan amal — "bu foydalanuvchi shu amalga haqlimi?" deb tekshirilishi shart.

O'xshatish: RBAC — kompaniyadagi lavozimlar. Oddiy xodim (user) — o'z stoliga kiradi. Menejer (moderator) — bo'limni boshqaradi. Direktor (admin) — hamma xonaga kiradi, qaror qabul qiladi. Har bir xodimga alohida ruxsat yozilmaydi — lavozim (rol) ruxsatni belgilaydi. Yangi xodim kelsa, unga lavozim beriladi — ruxsatlar avtomatik. Lavozim vazifasi o'zgarsa — bir joyda o'zgartiriladi, hamma shu lavozimdagilarga ta'sir qiladi.

Nega muhim?

  • Xavfsizlik (14) — har kim har narsani qila olmasligi; ruxsatlarni nazorat qilish.
  • Boshqaruv — ruxsatni rolga bog'lash (har foydalanuvchiga emas) — masshtablanadi.
  • Har real ilova — user/admin minimal; ko'pchilikda ko'p rol.
  • Authentication davomi — 5.15/5.16 dan keyingi mantiqiy qadam.

2. Nazariya — chuqur tushuntirish

2.1. Authentication vs Authorization (yana — aniq farq)

text
  Authentication (5.15, 5.16):  "SIZ KIMSIZ?"
     login/parol/token  "bu Ali, id 7, rol: admin"

  Authorization (bu bob):  "SIZGA NIMAGA RUXSAT BOR?"
     Ali (admin) bu amalni qila oladimi?  ha/yo'q

  Tartib: AVVAL authentication (req.user kim), KEYIN authorization (haqlimi)

Authorization doim authentication'dan keyin. Avval req.userni bilamiz (5.15: auth middleware), keyin uning roli/ruxsatini tekshiramiz. Auth'siz authorization — ma'nosiz (kimni tekshirasiz?).

2.2. RBAC nima va asosiy tushunchalar

RBAC (Role-Based Access Control) — ruxsatni rolga bog'lash, foydalanuvchiga rol berish (permify/permit.io):

text
  User (foydalanuvchi) ──▶ Role (rol) ──▶ Permission (ruxsat)

  Ali ──▶ admin  ──▶ [mahsulot:yaratish, foydalanuvchi:o'chirish, ...]
  Vali ──▶ user  ──▶ [buyurtma:yaratish, profil:ko'rish]
  Hasan ──▶ moderator ──▶ [sharh:o'chirish, sharh:ko'rish]

Uch element: User (kim), Role (lavozim — admin/user), Permission (aniq ruxsat — "mahsulot yaratish"). Oddiy RBAC'da rolga qarab tekshiramiz; murakkabroqda — aniq ruxsatga (permission) qarab 2.9-bob.

2.3. Nega rol (har foydalanuvchiga emas)

text
   Har foydalanuvchiga alohida ruxsat:
     Ali: [a, b, c, d, ...]
     Vali: [a, b, c, d, ...]    10000 foydalanuvchi = 10000 ro'yxat (chidab bo'lmas)

   Rolga ruxsat, foydalanuvchiga rol:
     admin roli: [a, b, c, d]
     Ali  admin, Vali  admin    rol o'zgarsa, hammaga ta'sir (bir joyda)

Foyda (best practices): boshqarish oson (rolni o'zgartirsangiz — hamma shu roldagilarga ta'sir); xato kam; audit oson ("kim o'chira oladi?" admin rolini ko'ring); masshtablanadi.

2.4. Rolni qayerda saqlash (DB + token)

Rol foydalanuvchi bilan DB'da saqlanadi (6), va tokenga 5.15-bob qo'shiladi:

text
  users jadvali:
  | id | email    | rol      |
  | 7  | ali@a.uz | admin    |

  JWT payload 5.15-bob: { sub: 7, rol: "admin" }
   har so'rovda token'dan rolni bilamiz (DB'ga qaramasdan — tez)

Nuans: rolni token'ga qo'yish — tez (DB'siz). Lekin rol o'zgarsa, eski token'da eski rol qoladi (token muddatigacha — 5.16). Sezgir holatda — DB'dan tekshiring (har doim yangi), yoki qisqa token + refresh 5.16-bob. Ko'p holatda token'dagi rol yetarli.

2.5. Authorization middleware (asosiy naqsh)

RBAC — middleware bilan amalga oshiriladi (Express — 5.6): auth'dan keyin rolni tekshiruvchi middleware (permit.io):

text
  So'rov  [auth: kim?]  [authorize: haqlimi?]  route handler
              │ req.user        │ rol mos emas  403 5.7-bob
              ▼                  ▼
           req.user.rol      ruxsat  next()
js
// Rol talab qiluvchi middleware (5.6)
const roleRequired = (...ruxsatRollar) => (req, res, next) => {
  if (!req.user) return res.status(401).json({ error: "Avtorizatsiya kerak" });   // (5.15)
  if (!ruxsatRollar.includes(req.user.rol)) {
    return res.status(403).json({ error: "Ruxsat yo'q" });   // 403 (2.6)
  }
  next();   // ruxsat (5.6)
};

2.6. 401 vs 403 (muhim farq)

text
  401 Unauthorized — "kim ekanligingni bilmayman" (login qilmagan, token yo'q/xato)
                      authentication muammosi 5.15-bob
  403 Forbidden    — "kim ekaningni bilaman, LEKIN bu ishga ruxsating yo'q"
                      authorization muammosi (bu bob)

Aralashtirma 5.7-bob: token yo'q/xato 401 (kim ekanligingni bilmayman). Token to'g'ri, lekin rol yetmaydi 403 (bilaman, lekin haqing yo'q). Bu farq — REST dizaynining muhim qismi.

2.7. Rol iyerarxiyasi (rollar darajasi)

Ba'zan rollar iyerarxiya hosil qiladi: yuqori rol — quyi rolning hamma ruxsatiga ega (leadwithskills):

text
  superadmin > admin > moderator > user
  (superadmin — hamma narsa; user — eng kam)

  Agar route "moderator" talab qilsa:
   user: yo'q; moderator: ha; admin: ha; superadmin: ha (yuqorilari ham o'tadi)
js
const IYERARXIYA = { user: 1, moderator: 2, admin: 3, superadmin: 4 };
const minRole = (kerak) => (req, res, next) => {
  if (IYERARXIYA[req.user.rol] >= IYERARXIYA[kerak]) return next();   // daraja yetarli
  return res.status(403).json({ error: "Ruxsat yo'q" });
};
// minRole("moderator")  moderator va undan yuqori o'tadi

2.8. Resurs egaligi (ownership) — muhim nuans

Rol yetarli emas: foydalanuvchi o'z resursini o'zgartirishi mumkin, lekin boshqalarnikini emas (rol bir xil bo'lsa ham):

text
  Vali (user) o'z buyurtmasini o'chira oladi 
  Vali (user) Hasanning buyurtmasini o'chira OLMAYDI  (rol bir xil — user!)

   Rol tekshiruvi YETARLI EMAS; "bu resurs SIZNIKIMI?" ham tekshirilishi kerak

Ownership check (14): ko'p xatolik shu yerda. "user roli bor" deb hamma buyurtmani o'chirishga ruxsat berish — xavfli (boshqaning ma'lumotini o'zgartiradi — IDOR hujumi, 14). Resurs egasini (order.userId === req.user.id) doim tekshiring. Admin esa hammasiga (rol + ownership birga).

2.9. RBAC vs ABAC vs PBAC (qisqacha)

text
  RBAC — rolga qarab (admin/user) — eng keng tarqalgan, sodda (bu bob)
  PBAC — aniq ruxsatga (permission) qarab ("mahsulot:o'chirish") — moslashuvchan 2.10-bob
  ABAC — atributga qarab (vaqt, joy, bo'lim — "ish vaqtida, o'z bo'limida") — murakkab

Ko'p ilova uchun RBAC yetadi. Murakkab tizimda — permission-based (PBAC — 2.10) yoki ABAC. Boshlash uchun RBAC; o'sgan sari permission'ga o'tish mumkin.

2.10. Permission-based (aniq ruxsatlar) — moslashuvchanroq

Faqat rol emas, aniq ruxsatlar (permission) bilan ishlash — moslashuvchanroq (permit.io):

text
  Rollar ruxsatlar to'plamiga ega:
  admin      ["mahsulot:yaratish", "mahsulot:o'chirish", "foydalanuvchi:o'qish", ...]
  moderator  ["sharh:o'chirish", "sharh:o'qish"]

  Middleware aniq ruxsatni tekshiradi:
  hasPermission("mahsulot:o'chirish")  foydalanuvchi rolida shu ruxsat bormi?

Foyda: yangi ruxsat qo'shish oson (rolga permission qo'shasiz, kodni o'zgartirmaysiz); nozik nazorat. Kamchilik: murakkabroq. RBAC + permission — ko'p professional tizimda ishlatiladi.

Tayyor kutubxona: murakkab loyihada ruxsatni qo'lda yozmasdan, policy (siyosat) kutubxonasidan foydalanish mumkin — masalan CASL (@casl/ability): ruxsatlarni bir joyda e'lon qilasiz (can("delete", "Order")), ownership 2.8-bob va shartli qoidalarni ham qamraydi. Boshlash uchun yuqoridagi qo'lda yozilgan middleware yetarli; tizim o'sgach, CASL kabi yechimga o'tish mumkin.

2.11. Xavfsizlik amaliyotlari (14)

text
   Default RAD eting (deny by default) — ruxsat aniq berilmaganda — yo'q (14)
   Har himoyalangan amalni tekshiring (route'ni ochiq qoldirmang)
   Ownership tekshiring (rol + "bu sizniki?" — 2.8, 14)
   401 vs 403 to'g'ri 2.6-bob
   Rolni server tekshiradi (clientga ishonmang — 14); token imzolangan 5.15-bob
   Eng kam imtiyoz (least privilege) — faqat zarur ruxsat
   Frontend yashirishi — UX; backend tekshiruvi — HAQIQIY himoya (14)

Frontend yashirish — himoya EMAS (14): "admin tugmasini oddiy user'ga ko'rsatmaslik" — faqat UX. Hacker to'g'ridan API'ga so'rov yuboradi 0.4-bob. Backend har doim tekshirishi shart (5.9 ruhida — "clientga ishonmang").

3. Sintaksis — tez ma'lumotnoma

js
// Rol middleware (2.5)
const roleRequired = (...rollar) => (req, res, next) => {
  if (!req.user) return res.status(401).json({ error: "..." });        // (2.6)
  if (!rollar.includes(req.user.rol)) return res.status(403).json({ error: "Ruxsat yo'q" });
  next();
};

// Ishlatish (auth'dan KEYIN — 2.1)
app.delete("/products/:id", auth, roleRequired("admin"), deleteProduct);

// Ownership (2.8)
if (resurs.userId !== req.user.id && req.user.rol !== "admin")
  return res.status(403).json({ error: "Bu sizniki emas" });

// Permission 2.10-bob: hasPermission("mahsulot:o'chirish")

4. Batafsil kod namunalari

Misol 1 — Asosiy rol middleware (2.5)

js
// middleware/authorize.js
export const roleRequired = (...ruxsatRollar) => (req, res, next) => {
  // auth middleware oldin ishlagan bo'lishi kerak (req.user bor — 5.15, 2.1)
  if (!req.user) {
    return res.status(401).json({ error: "Avtorizatsiya kerak" });   // 401 (2.6)
  }
  if (!ruxsatRollar.includes(req.user.rol)) {
    return res.status(403).json({ error: "Bu amal uchun ruxsatingiz yo'q" });   // 403 (2.6)
  }
  next();   // rol mos — davom (5.6)
};

// Ishlatish (auth  authorize  handler — 2.5)
import { auth } from "./auth.js";
app.post("/api/products", auth, roleRequired("admin"), createProduct);
app.delete("/api/users/:id", auth, roleRequired("admin", "superadmin"), deleteUser);  // ikki rol
app.get("/api/reports", auth, roleRequired("admin", "moderator"), getReports);

Misol 2 — Rol iyerarxiyasi (2.7)

js
// Rol darajalari (2.7)
const ROL_DARAJA = { user: 1, moderator: 2, admin: 3, superadmin: 4 };

// Minimal rol talab qiluvchi middleware (yuqorilari ham o'tadi)
export const minRole = (kerakliRol) => (req, res, next) => {
  if (!req.user) return res.status(401).json({ error: "Avtorizatsiya kerak" });
  const userDaraja = ROL_DARAJA[req.user.rol] || 0;
  const kerakDaraja = ROL_DARAJA[kerakliRol] || 0;
  if (userDaraja >= kerakDaraja) return next();   // daraja yetarli (2.7)
  return res.status(403).json({ error: "Ruxsat yo'q" });
};

// "moderator" va undan yuqori (admin, superadmin) o'tadi
app.delete("/api/comments/:id", auth, minRole("moderator"), deleteComment);

Misol 3 — Ownership tekshiruvi (2.8, 14)

js
// Foydalanuvchi o'z resursini yoki admin hammasini (2.8)
export const deleteBuyurtma = async (req, res, next) => {
  try {
    const buyurtma = await Order.findById(req.params.id);   // DB (6)
    if (!buyurtma) return res.status(404).json({ error: "Topilmadi" });   // (5.7)

    // OWNERSHIP: o'ziniki yoki admin (2.8, 14)
    const oziniki = buyurtma.userId.toString() === req.user.id;
    const admin = req.user.rol === "admin";
    if (!oziniki && !admin) {
      return res.status(403).json({ error: "Bu buyurtma sizniki emas" });   // 403 (2.6)
    }

    await buyurtma.deleteOne();
    res.json({ message: "O'chirildi" });
  } catch (err) { next(err); }
};
//  Faqat rol ("user") tekshirilsa — Vali Hasanning buyurtmasini o'chirardi (IDOR — 14)

Misol 4 — Ownership middleware (qayta ishlatiladigan — 2.8)

js
// Resurs egaligini tekshiruvchi umumiy middleware (DRY — 2.8)
export const ownerOrAdmin = (Model, param = "id") => async (req, res, next) => {
  try {
    const resurs = await Model.findById(req.params[param]);   // (6)
    if (!resurs) return res.status(404).json({ error: "Topilmadi" });
    const oziniki = resurs.userId?.toString() === req.user.id;
    if (!oziniki && req.user.rol !== "admin") {
      return res.status(403).json({ error: "Ruxsat yo'q" });   // (2.6)
    }
    req.resurs = resurs;   // keyingi handler ishlatishi uchun
    next();
  } catch (err) { next(err); }
};

// Ishlatish
app.patch("/api/orders/:id", auth, ownerOrAdmin(Order), updateOrder);
app.delete("/api/posts/:id", auth, ownerOrAdmin(Post), deletePost);

Misol 5 — Permission-based (aniq ruxsatlar — 2.10)

js
// Rol  ruxsatlar (2.10)
const ROL_RUXSAT = {
  user: ["buyurtma:yaratish", "profil:o'qish", "profil:tahrir"],
  moderator: ["sharh:o'qish", "sharh:o'chirish", "buyurtma:o'qish"],
  admin: ["*"],   // hammasi (2.10)
};

// Aniq ruxsatni tekshiruvchi middleware
export const hasPermission = (ruxsat) => (req, res, next) => {
  if (!req.user) return res.status(401).json({ error: "Avtorizatsiya kerak" });
  const ruxsatlar = ROL_RUXSAT[req.user.rol] || [];
  if (ruxsatlar.includes("*") || ruxsatlar.includes(ruxsat)) {
    return next();   // ruxsat bor (2.10)
  }
  return res.status(403).json({ error: `"${ruxsat}" uchun ruxsat yo'q` });
};

// Ishlatish — aniq ruxsat bo'yicha (rol emas)
app.delete("/api/comments/:id", auth, hasPermission("sharh:o'chirish"), deleteComment);
app.post("/api/orders", auth, hasPermission("buyurtma:yaratish"), createOrder);

Misol 6 — Permission'larni DB'da saqlash (dinamik — 2.10)

js
// Rollar va ruxsatlar DB'da (dinamik — kodni o'zgartirmasdan boshqarish — 2.10)
const roleSchema = new mongoose.Schema({
  nom: { type: String, unique: true },              // "admin", "moderator"
  ruxsatlar: [String],                               // ["mahsulot:yaratish", ...]
});

// Middleware — DB'dan ruxsatlarni oladi
export const can = (ruxsat) => async (req, res, next) => {
  const rol = await Role.findOne({ nom: req.user.rol });   // (6)
  if (rol?.ruxsatlar.includes(ruxsat) || rol?.ruxsatlar.includes("*")) {
    return next();
  }
  return res.status(403).json({ error: "Ruxsat yo'q" });
};
// Admin panelda rolga ruxsat qo'shish/olib tashlash mumkin (kodga tegmasdan)

Misol 7 — To'liq himoyalangan router (2.5)

js
import { Router } from "express";
import { auth } from "../middleware/auth.js";
import { roleRequired } from "../middleware/authorize.js";

const router = Router();

// Ochiq (auth kerak emas)
router.get("/products", getProducts);

// Auth kerak (har kirgan foydalanuvchi)
router.post("/orders", auth, createOrder);
router.get("/profile", auth, getProfile);

// Admin (auth + admin rol — 2.5)
router.post("/products", auth, roleRequired("admin"), createProduct);
router.delete("/products/:id", auth, roleRequired("admin"), deleteProduct);
router.get("/admin/stats", auth, roleRequired("admin"), getStats);

// Moderator yoki admin
router.delete("/comments/:id", auth, roleRequired("admin", "moderator"), deleteComment);

export default router;

Misol 8 — Rol tayinlash (admin tomonidan — 2.4)

js
// Faqat admin boshqa foydalanuvchiga rol bera oladi (2.4, 2.11)
export const rolTayinlash = async (req, res, next) => {
  try {
    const { rol } = req.body;
    // Faqat ruxsat etilgan rollar (validatsiya — 5.9, 2.11)
    if (!["user", "moderator", "admin"].includes(rol)) {
      return res.status(400).json({ error: "Noto'g'ri rol" });
    }
    const user = await User.findByIdAndUpdate(req.params.id, { rol }, { new: true });   // (6)
    if (!user) return res.status(404).json({ error: "Topilmadi" });
    res.json({ message: `${user.email}  ${rol}`, user: { id: user.id, rol } });
    //  Rol o'zgardi — eski token'da eski rol qoladi (token muddatigacha — 2.4, 5.16)
  } catch (err) { next(err); }
};

// Faqat admin (2.5)
app.patch("/api/users/:id/role", auth, roleRequired("admin"), rolTayinlash);

5. To'g'ri va noto'g'ri holatlar

1) Authorization'siz himoyalangan route

js
//  har kim admin amalini bajaradi (14, 2.11)
app.delete("/products/:id", auth, deleteProduct);   // faqat auth (rol yo'q!)

//  rol tekshiruvi
app.delete("/products/:id", auth, roleRequired("admin"), deleteProduct);

2) Faqat rol, ownership'siz

js
//  har user har buyurtmani o'chiradi (IDOR — 14, 2.8)
app.delete("/orders/:id", auth, roleRequired("user"), deleteOrder);

//  ownership tekshiring
app.delete("/orders/:id", auth, ownerOrAdmin(Order), deleteOrder);

3) 401 va 403 ni aralashtirish

js
//  rol yetmaganda 401 (noto'g'ri — 2.6)
if (req.user.rol !== "admin") return res.status(401)...;

//  kirgan, lekin haqi yo'q  403
if (req.user.rol !== "admin") return res.status(403)...;

4) Frontend'ga ishonish

text
 "admin tugmasini yashirdim, yetarli" (hacker API'ga to'g'ridan so'rov — 14, 2.11)
 backend har doim tekshiradi (frontend — faqat UX)

5) Default ruxsat berish

js
//  noma'lum rolga ruxsat (14, 2.11)
if (req.user.rol === "banned") return res.status(403)...;
next();   // qolgan hammaga ruxsat!

//  deny by default — faqat ruxsat etilganlarga
if (!ruxsatRollar.includes(req.user.rol)) return res.status(403)...;

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — req.user undefined (authorize'da)

Sababi: auth middleware authorize'dan oldin qo'yilmagan 2.1-bob. Yechimi: tartib: auth roleRequired (auth oldin — 2.5).

Xato 2 — Admin ham 403 oladi

Sababi: rol nomi mos emas ("Admin" vs "admin"), yoki token'da rol yo'q 5.15-bob. Yechimi: rol nomini izchil (kichik harf); token payload'da rol borligini tekshiring 2.4-bob.

Xato 3 — User boshqaning ma'lumotini o'zgartira oldi (IDOR)

Sababi: ownership tekshirilmagan (2.8, 14). Yechimi: resurs.userId === req.user.id (Misol 3, 4).

Xato 4 — Rol o'zgartirildi, lekin eski ruxsat ishlayapti

Sababi: eski token'da eski rol 2.4-bob. Yechimi: qisqa token + refresh 5.16-bob; yoki sezgir amalda DB'dan rolni tekshiring.

Xato 5 — Hamma route ochiq qolib ketdi

Sababi: ba'zi route'ga middleware qo'shilmagan. Yechimi: himoyalangan route'larni guruhlash (router.use(auth)); audit (har route tekshirilganmi).

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

  • Authentication (5.15, 5.16): req.user — bu yerdan; rol token'da.
  • Express 5.6-bob: authorize — middleware.
  • REST 5.7-bob: 401/403 status.
  • Validatsiya 5.9-bob: rol qiymatini tekshirish.
  • Error handling 5.10-bob: 403 javoblar.
  • DB (6): user.rol; rollar/ruxsatlar jadvali (dinamik).
  • Xavfsizlik (14): IDOR, deny by default, least privilege.
  • Frontend (11): rolga qarab UI (UX — backend HAQIQIY himoya).
  • NestJS 8.7-bob: Guards (@Roles() dekorator) — shu g'oya.

8. Eng yaxshi amaliyotlar (best practices)

  • Authorization auth'dan keyin (req.user — 2.1); tartib: auth authorize.
  • Har himoyalangan amalni tekshiring (route'ni ochiq qoldirmang — 2.11).
  • Rolga ruxsat, foydalanuvchiga rol (RBAC — 2.3); rol iyerarxiyasi 2.7-bob.
  • Ownership tekshiring (rol + "bu sizniki?" — IDOR himoyasi — 2.8, 14).
  • 401 vs 403 to'g'ri (kim emasligi vs ruxsati — 2.6).
  • Deny by default (ruxsat aniq berilmasa — yo'q — 2.11, 14).
  • Eng kam imtiyoz (least privilege — faqat zarur ruxsat — 2.11).
  • Server tekshiradi (frontend yashirish — faqat UX — 2.11, 14).
  • Murakkab tizimda permission-based (PBAC — 2.10); DB'da dinamik rollar.
  • Rol tayinlashni himoyala (faqat admin — 2.4, Misol 8).

9. Amaliy loyiha: "RBAC bilan Himoyalangan API"

Avtorizatsiyani professional darajada mustahkamlash.

Maqsad

RBAC tizimini qurish: rollar (user/moderator/admin), rol middleware, ownership tekshiruvi, rol iyerarxiyasi va permission-based nazorat (5.15/5.16 auth'i ustiga).

Talablar (requirements)

  1. Rol middleware: roleRequired(...rollar) — auth'dan keyin; 403 (Misol 1, 2.5, 2.6).
  2. Rollar: user/moderator/admin; DB'da (user.rol) va token'da 2.4-bob.
  3. Himoyalangan route'lar: ochiq / auth / admin / moderator (Misol 7, 2.5).
  4. Ownership: foydalanuvchi o'z resursini, admin hammasini (Misol 3/4, 2.8, 14).
  5. Rol iyerarxiyasi: minRole("moderator") — yuqorilari o'tadi (Misol 2, 2.7).
  6. Permission-based (bonus): hasPermission("mahsulot:o'chirish") (Misol 5, 2.10).
  7. Rol tayinlash: faqat admin boshqaga rol bera oladi (Misol 8, 2.4).
  8. 401 vs 403: to'g'ri ishlatilsin 2.6-bob.
  9. Deny by default: ruxsat etilmaganda rad (2.11, 14).
  10. (Bonus) Dinamik rollar: rollar/ruxsatlar DB'da; admin panel orqali boshqarish (Misol 6, 2.10).

Maslahatlar (hint)

  • Tartib: auth roleRequired (req.user oldin — 2.1, 1-xato).
  • 403 (ruxsat yo'q) ≠ 401 (kirilmagan — 2.6).
  • Ownership: resurs.userId.toString() === req.user.id 2.8-bob.
  • Iyerarxiya: { user: 1, moderator: 2, admin: 3 } 2.7-bob.
  • Permission: rol ruxsatlar map 2.10-bob.
  • Rol tayinlash faqat admin + validatsiya (2.4, 5.9).

"Tayyor" mezonlari (acceptance criteria)

  • Rol middleware ishlaydi (admin route'ni user ololmaydi 403).
  • Himoyalangan route'lar to'g'ri (ochiq/auth/admin).
  • Ownership: user boshqaning resursini o'zgartira olmaydi.
  • Rol iyerarxiyasi (yuqori rol quyi ruxsatni oladi).
  • 401 va 403 to'g'ri ishlatilgan.
  • Deny by default.
  • Rol tayinlash faqat admin'da.
  • (Bonus) Permission-based / dinamik rollar.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda auth'ning ikkinchi yarmini — authorization (RBAC) ni — chuqur o'rgandik:

  • Authentication (kim?) vs authorization (nimaga haqli? — 2.1); tartib: auth authorize.
  • RBAC — User Role Permission 2.2-bob; rolga ruxsat (har foydalanuvchiga emas — 2.3); rol DB + token'da 2.4-bob.
  • Authorization middleware 2.5-bob; 401 vs 403 2.6-bob; rol iyerarxiyasi 2.7-bob.
  • Ownership — rol + "bu sizniki?" (IDOR himoyasi — 2.8, 14); RBAC vs PBAC vs ABAC 2.9-bob; permission-based 2.10-bob.
  • Xavfsizlik — deny by default, least privilege, server tekshiruvi (frontend — UX — 2.11, 14).

Keyingi bob — 5.18-bob: OTP va SMS integratsiyasi (Eskiz / Play Mobile). Auth tizimini (5.15-5.17) qurdik; endi O'zbekistonda juda keng tarqalgan amaliy mavzuni — telefon raqami orqali tasdiqlash (OTP) va SMS yuborish (Eskiz, Play Mobile) — o'rganamiz: OTP yaratish, yuborish, tekshirish, muddat, rate limiting va xavfsizlik.

Foydalanilgan rasmiy/ishonchli manbalar

  • Permify / Permit.io — RBAC in Node.js/Express; Auth0 — Express RBAC code sample
  • LeadWithSkills — RBAC (rol iyerarxiyasi); OWASP — Broken Access Control (IDOR)
  • CASL (@casl/ability) — isomorphic authorization (policy-based ruxsatlar)
  • expressjs.com — middleware (authorization naqshi)

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
5.17-bob: Authorization — RBAC (role-based access control) — Wisar