သင့်အက်ပ်သို့ Role-Based Access Control (RBAC) ထည့်နည်း

role-based access control ထည့်ရန် အသုံးပြုသူတစ်ဦးစီကို role တစ်ခု သို့မဟုတ် ထို့ထက်ပို (ဥပမာ admin၊ editor၊ viewer) ပေးပါ၊ role တစ်ခုစီ လုပ်ခွင့်ရှိသော လုပ်ဆောင်ချက်များကို သတ်မှတ်ပါ၊ ထို့နောက် request တိုင်းအတွက် ထိုခွင့်ပြုချက်များကို server ပေါ်တွင် စစ်ဆေးပါ — ခလုတ်များကို ဝှက်ခြင်းဖြင့်သာ မဟုတ်ပါ။ ဝင်ရောက်နေသော မှတ်တမ်းသည် အသုံးပြုသူ၏ အကောင့် သို့မဟုတ် အဖွဲ့အတွင်း ရှိကြောင်းလည်း စစ်ပါ။ ဒေတာဘေ့စ်တွင် ပုံသေ role အနည်းငယ်ဖြင့် စတင်ပြီး အခြားအသုံးပြုသူ၏ ဒေတာကို တိုက်ရိုက် ဝင်ကြည့်ကြိုးစားခြင်းဖြင့် စမ်းသပ်ပါ။

Authentication နှင့် authorisation

ရောထွေးတတ်သော စကားလုံးနှစ်လုံး:

• Authentication သည် သင်ဘယ်သူလဲ? — လော့ဂ်အင်ဝင်ခြင်း။ အက်ပ်သို့ login ထည့်နည်း ကို ကြည့်ပါ။
• Authorisation သည် ဘာလုပ်ခွင့်ရှိသလဲ? — လော့ဂ်အင်ဝင်ထားသော အသုံးပြုသူသည် ဘယ်စာမျက်နှာ၊ မှတ်တမ်းနှင့် လုပ်ဆောင်ချက်များ ရောက်နိုင်သည်။

RBAC သည် authorisation လုပ်ရန် အသုံးအများဆုံး နည်းလမ်းဖြစ်သည်။ အရေးကြီးသည်: စက်တင်ဘာ 2026 အရ Broken Access Control သည် OWASP Top 10:2025 တွင် #1 ဖြစ်သည်၊ ၎င်းသည် ဝဘ်အက်ပ် လုံခြုံရေး အန္တရာယ်အပြင်းထန်ဆုံး စာရင်းဖြစ်သည်။ ပုံမှန် ချို့ယွင်းမှုများမှာ URL ရှိ ID ကို ပြောင်းလဲခြင်းဖြင့် အခြားအသုံးပြုသူ၏ မှတ်တမ်းများကို ဖတ်ခြင်း၊ သို့မဟုတ် သာမန်အသုံးပြုသူများက admin-only API route များကို ခေါ်ခြင်း ဖြစ်သည်။

မော်ဒယ်ရွေးချယ်ခြင်း

လက်တွေ့တွင် အက်ပ်အများစုသည် အရာနှစ်ခု ပေါင်းသည်: ဘယ်လိုလုပ်ဆောင်ချက်မျိုး လုပ်ခွင့်ရှိသလဲဆိုသည့် role နှင့် ဘယ်မှတ်တမ်းတွင် လုပ်ခွင့်ရှိသလဲဆိုသည့် ပိုင်ဆိုင်မှု။ "Editor များသည် ပို့စ်များကို တည်းဖြတ်နိုင်သည်" သည် role စည်းမျဉ်း ဖြစ်သည်; "…ကိုယ်ပိုင် workspace ရှိ ပို့စ်များ" သည် ပိုင်ဆိုင်မှု စည်းမျဉ်း ဖြစ်သည်။ နှစ်ခုလုံး လိုအပ်သည်။

သင်ထင်သည်ထက် ပိုရိုးရှင်းစွာ စတင်ပါ။ admin၊ member နှင့် viewer သည် အက်ပ်အရေအတွက် အံ့ဩစရာကောင်းစွာ ကျယ်ကျယ်ပြန့်ပြန့် လုံလောက်သည်။ နားမလည်နိုင်သော role ဆယ်ခုကို နောက်ပိုင်း ခွဲခြမ်းရာထက် role တစ်ခုကို နောက်ပိုင်း ခွဲရလွယ်သည်။

ကုဒ်မရေးမီ role များကို ဒီဇိုင်းလုပ်ပါ

ရိုးရိုးစကားဖြင့် ခွင့်ပြုချက်ဇယားကို အရင်ရေးပါ။ ၎င်းသည် AI အတွက် spec နှင့် သင့်စမ်းသပ်ရေးအစီအစဉ် နှစ်မျိုးလုံး ဖြစ်သည်:

အစွန်းကိစ္စများကိုလည်း ဆုံးဖြတ်ပါ: နောက်ဆုံး ပိုင်ရှင်က ထွက်နိုင်သလား? admin က ပိုင်ရှင်ကို ဖယ်ရှားနိုင်သလား? ဖယ်ရှားခံရသော အသုံးပြုသူ ဘာကိုမြင်သလဲ?

အဆင့်အလိုက် လုပ်ဆောင်ချက်

၁။ အလုပ်လုပ်သော login ကို ဦးစွာရှိစေပါ

RBAC သည် authentication အပေါ်တွင် ထိုင်သည်။ server သည် session သို့မဟုတ် စစ်ဆေးပြီး token မှ request တိုင်းကို ဘယ်သူပြုလုပ်နေသည်ကို ယုံကြည်စွာ သိရမည် — browser က request body တွင် ပို့သော user ID မှ ဘယ်တော့မှ မသိရပါ။

၂။ role များကို ဒေတာဘေ့စ်တွင် သိမ်းပါ

အဖွဲ့တစ်ခုတည်း အက်ပ်အတွက် users ပေါ်ရှိ role column သည် ရပါသည်။ အဖွဲ့များအတွက် memberships table ကို သုံးပါ:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

ပုံမှန် profile update မှတစ်ဆင့် အသုံးပြုသူများ ကိုယ့် role ကို သတ်မှတ်ခွင့် မပေးပါနှင့်။ role ပြောင်းလဲမှုများကို သီးသန့် ခွင့်ပြုချက်စစ်သော endpoint မှတစ်ဆင့်သာ ပြုလုပ်ပါ။

၃။ ခွင့်ပြုချက်ကို server ပေါ်တွင် နေရာတစ်ခုတည်းမှ စစ်ပါ

helper တစ်ခု ရေးပါ — ဥပမာ can(user, 'projects.delete', project) — ပြီး ဒေတာဖတ်ခြင်း သို့မဟုတ် ပြောင်းခြင်း လုပ်သော API route၊ server action နှင့် background task တိုင်းတွင် ခေါ်ပါ။ ဗဟို function တစ်ခုသည် code တစ်ခွင် ပြန့်ကျဲနေသော စစ်ဆေးမှုများထက် ပြန်သုံးသပ်ရန်နှင့် စမ်းသပ်ရန် ပိုလွယ်သည်။ ပုံသေအားဖြင့် ငြင်းပါ: စည်းမျဉ်းတစ်ခုမျှ ခွင့်မပြုလျှင် ငြင်းပယ်သည်။

၄။ query တိုင်းကို ကန့်သတ်ပါ

အဖွဲ့ဒေတာအတွက် query တိုင်း၌ အဖွဲ့ကို ထည့်ပါ: where id = :id သာမဟုတ်ဘဲ where organization_id = :currentOrg။ ၎င်းသည် တစ်စုံတစ်ဦးက /projects/123 ကို /projects/124 သို့ ပြောင်းပြီး အခြားကုမ္ပဏီ၏ ပရောဂျက်ကို မမြင်စေရန် တားသည်။ အခြားအဖွဲ့များရှိ မှတ်တမ်းများအတွက် "forbidden" အစား "not found" ကို ပြန်ပေးပါ၊ ထိုသို့ဆိုလျှင် ထိုမှတ်တမ်းများ ရှိနေကြောင်း မထုတ်ဖော်မိပါ။

၅။ အရေးကြီးသည့်နေရာတွင် ဒေတာဘေ့စ်အဆင့် အကာအကွယ် ထည့်ပါ

Postgres row-level security (RLS) သည် အသုံးပြုသူ ဘယ်အတန်းများ မြင်နိုင်သည်ကို ဒေတာဘေ့စ်က ပြဌာန်းစေသည်။ browser က ဒေတာဘေ့စ်ကို တိုက်ရိုက်ဆက်သွယ်သည့်အခါ (hosted backend အချို့ကဲ့သို့) အရေးကြီးပြီး၊ မဟုတ်ပါက ထိခိုက်လွယ်သော table များအတွက် အသုံးဝင်သော အလွှာ ဒုတိယတစ်ခု ဖြစ်သည်။

၆။ role များကို interface တွင် ထင်ဟပ်စေပါ

ယခု အသုံးပြုသူ မလုပ်နိုင်သည်များကို ဝှက်ပါ သို့မဟုတ် ပိတ်ပါ၊ ထို့ကြောင့် အက်ပ်သည် ရှုပ်ထွေးမှု မရှိပါ။ ၎င်းသည် အသုံးပြုရလွယ်ကူရန်အတွက်သာ ဖြစ်ပြီး ကာကွယ်ခြင်းကို server စစ်ဆေးမှုများက လုပ်ဆောင်သည်။

၇။ အရေးကြီးသော လုပ်ဆောင်ချက်များကို မှတ်တမ်းတင်ပါ

role ပြောင်းသူ၊ ဒေတာဖျက်သူ သို့မဟုတ် ထုတ်ယူသူကို ဘယ်အချိန်ဖြစ်သည်ကို မှတ်ပါ။ audit log သည် support မေးခွန်းများနှင့် ဖြစ်ရပ်များအတွက် ကူညီသည်။

၈။ တိုက်ခိုက်သူတစ်ဦးကဲ့သို့ စမ်းသပ်ပါ

role တစ်ခုစီဖြင့် ဝင်ပြီး ခွင့်ပြုချက်ဇယားရှိ လုပ်ဆောင်ချက်တိုင်းကို စမ်းကြည့်ပါ။ ထို့နောက် မဖြစ်သင့်သော အရာများကို စမ်းကြည့်ပါ: viewer အနေဖြင့် admin API route များကို ခေါ်ခြင်း၊ URL နှင့် request ရှိ ID များကို ပြောင်းခြင်း၊ နောက်ဆုံး ပိုင်ရှင်အဖြစ် ကိုယ်ကိုယ်ကို ဖယ်ရှားခြင်း။ စည်းမျဉ်းများ တည်ငြိမ်ပြီးသည်နှင့် ခွင့်ပြုချက်ဇယားအတွက် အလိုအလျောက် စမ်းသပ်ချက်များ ရေးရန် တန်ဖိုးရှိသည်။

အလုပ်ဖြစ်သော prompt များ

role-based access control ထည့်ပါ။ အဖွဲ့တစ်ခုစီအတွက် role များ: owner၊ admin၊ member၊ viewer၊ memberships table တွင် သိမ်းပါ။ ခွင့်ပြုချက်များသည် ဤဇယားတွင် ရှိသည်: [သင့်ဇယားကို ထည့်ပါ]။ server-side can(user, action, resource) helper တစ်ခုတည်း ဖန်တီးပါ၊ ပုံသေအားဖြင့် ငြင်းပါ၊ API route တိုင်းတွင် သုံးပါ။ query တိုင်းကို organization_id ဖြင့် ကန့်သတ်ပါ။ အသုံးပြုသူ မလုပ်နိုင်သော လုပ်ဆောင်ချက်များကို UI တွင် ဝှက်ပါ၊ သို့သော် လုံခြုံရေးအတွက် ထိုအရာကို ဘယ်တော့မှ မှီခိုမပါနှင့်။

ဤအက်ပ်ရှိ API route နှင့် server function တိုင်းကို ပြန်သုံးသပ်ပါ။ တစ်ခုချင်းစီအတွက် ဘယ်ဒေတာကို ဖတ်သည် သို့မဟုတ် ပြောင်းသည်၊ အသုံးပြုသူ လော့ဂ်အင်ဝင်ထားကြောင်း စစ်သလား၊ role ကို စစ်သလား၊ query ကို ၎င်း၏ အဖွဲ့အတွက် ကန့်သတ်သလား ဆိုသည်ကို စာရင်းပြုစုပါ။ စစ်ဆေးမှု ပျောက်နေသော နေရာများကို ပြင်ပြီး စာရင်းကို ပြပါ။

owner က အဖွဲ့ဝင်များ၏ role ကို ပြောင်းနိုင်သော admin-only /admin စာမျက်နှာ ထည့်ပါ။ နောက်ဆုံး owner ကို ဖယ်ရှားခြင်း သို့မဟုတ် လျှော့ချခြင်းကို တားပါ၊ role ပြောင်းလဲမှုတိုင်းကို ဘယ်သူပြုလုပ်သည်နှင့် ဘယ်အချိန်ဆိုသည်ကို မှတ်ပါ၊ role-change endpoint သည် owner မဟုတ်သူမည်သူကိုမဆို ပယ်ချကြောင်း သေချာစေပါ။

အများဆုံးဖြစ်သော အမှားများ

• role များကို front end တွင်သာ စစ်ခြင်း။ API သည် ခေါ်ဆိုသူ မည်သူမဆို ဝင်ရောက်နိုင်ဆဲ ဖြစ်သည်။
• client မှ ID များကို ယုံကြည်ခြင်း — session အစား request body ရှိ userId သို့မဟုတ် role။
• ID တစ်ခုတည်းဖြင့် ရှာသော အကန့်အသတ်မရှိ query များ။
• စာမျက်နှာများတွင် role စစ်သော်လည်း API route၊ export၊ ဖိုင်ဒေါင်းလုဒ် သို့မဟုတ် webhook များတွင် မစစ်ခြင်း။
• code ထဲတွင် ပြင်ထားသော admin email လိပ်စာ (if email === 'me@...')၊ မေ့ရလွယ်ပြီး ပြောင်းရခက်သည်။
• အစောကြီး role များ အရမ်းများခြင်း၊ ခြောက်လနောက်တွင် မည်သူမျှ ရှင်းပြနိုင်မည် မဟုတ်။
• ဟောင်းနေသော session များ: ရာထူးလျှော့ခံရသော အသုံးပြုသူသည် logout မလုပ်မချင်း admin ခွင့် ဆက်ရှိသည်။ အရေးကြီးသော လုပ်ဆောင်ချက်များတွင် role များကို ဒေတာဘေ့စ်မှ စစ်ပါ သို့မဟုတ် ပြန်လတ်ပါ။

RBAC စစ်ဆေးစာရင်း

• ခွင့်ပြုချက်ဇယားကို ရိုးရိုးစကားဖြင့် ရေးထား၊ အစွန်းကိစ္စများ ဆုံးဖြတ်ထား
• server သည် session မှ အသုံးပြုသူကို သိသည်၊ request ဒေတာမှ ဘယ်တော့မှ မသိပါ
• role များကို ဒေတာဘေ့စ်တွင် သိမ်းထား; အသုံးပြုသူများ ကိုယ့် role ကို ပြောင်းခွင့်မရှိ
• ဗဟို ခွင့်ပြုချက် စစ်ဆေးမှု တစ်ခုတည်း၊ ပုံသေအားဖြင့် ငြင်းပယ်၊ route တိုင်းတွင် သုံးထား
• query တိုင်းကို အသုံးပြုသူ၏ အဖွဲ့ သို့မဟုတ် ပိုင်ဆိုင်မှုအလိုက် ကန့်သတ်ထား
• browser က ဒေတာဘေ့စ်သို့ ရောက်နိုင်သည့်နေရာတွင် row-level security ရှိ
• UI သည် အသုံးပြုသူ မလုပ်နိုင်သည်များကို ဝှက်ထား (အသုံးပြုရလွယ်ကူရန်သာ)
• အရေးကြီးသော လုပ်ဆောင်ချက်များ မှတ်တမ်းတင်ထား
• role တိုင်းကို စမ်းသပ်ထား၊ API တိုက်ရိုက်ခေါ်ဆိုမှုနှင့် ပြောင်းထားသော ID များအပါအဝင်

ဝင်ရောက်ခွင့် ထိန်းချုပ်မှုသည် ရှည်လျားသော စာရင်းတစ်ခုရှိ အပိုင်းတစ်ခုသာဖြစ်ပြီး AI ဖြင့် တည်ဆောက်ထားသော အက်ပ်များအတွက် လုံခြုံရေး စစ်ဆေးစာရင်း က ကျန်အရာများကို ဖုံးလွှမ်းသည်။ ဝန်ထမ်းများအတွက် ကိရိယာတစ်ခု တည်ဆောက်နေပါက internal tool တည်ဆောက်နည်း တွင် role များ ဘယ်နေရာ ဝင်သည်ကို ပြသထားသည်။

Mythex ရှိ RBAC

Mythex က သင့်အက်ပ်၏ အသုံးပြုသူများအတွက် built-in login သို့မဟုတ် role စနစ် မပေးပါ။ သင် auth library သို့မဟုတ် provider ကို ရွေးပြီး role များကို ဖော်ပြသည်၊ agent က ၎င်းတို့ကို သင့် code နှင့် ပရောဂျက်၏ Postgres ဒေတာဘေ့စ်သို့ ချိတ်ဆက်ပေးသည် (အက်ပ်သို့ login ထည့်ခြင်း)။ Mythex ၏ ကိုယ်ပိုင် workspace role များ၊ ဥပမာ Owner နှင့် Member၊ သည် သင့် Mythex ပရောဂျက်များကို ဘယ်သူ တည်းဖြတ်နိုင်သည်ကို ထိန်းချုပ်သည်၊ သင် publish လုပ်သော အက်ပ်ကို ဘယ်သူသုံးနိုင်သည်ကို မဟုတ်ပါ။ တည်ဆောက်မီ ခွင့်ပြုချက်ဇယားကို သဘောတူရန် Plan mode ကို သုံးပါ၊ ထို့နောက် အထက်ပါ ပြန်သုံးသပ်ရေး prompt ကို သုံးပြီး publish မလုပ်မီ Preview တွင် role တိုင်းကို စမ်းသပ်ပါ။ docs ၏ လုံခြုံရေး prompt များ သည် အသုံးဝင်သော နောက်ဆက်တွဲ ဖြစ်သည်။

မေးခွန်းများ