Row-Level Security ကို သဘောတရားအရ နားလည်ခြင်း

နားလည်ထားရမယ့် အချက်

API endpoint တိုင်းက permission ကို မှန်ကန်စွာ စစ်ဆေးပေမယ့် endpoint တစ်ခုမှာ bug ရှိရင်၊ endpoint အသစ်တစ်ခုက check ကို မေ့ကျန်ခဲ့ရင်၊ တစ်ယောက်ယောက်က database ကို တိုက်ရိုက် query လုပ်ရင် ဘာဖြစ်မလဲ။ Application-level authorization ဟာ mistake တစ်ခုက ကျော်သွားနိုင်တဲ့ code ထဲမှာသာ ရှိနေပါတယ်။

Row-level security က enforcement ရဲ့ တစ်စိတ်တစ်ပိုင်းကို database ကိုယ်တိုင်ဆီ ရွှေ့ပေးပါတယ်၊ table တစ်ခုနဲ့ ချိတ်ဆက်ထားတဲ့ policy တစ်ခုအနေနဲ့ပါ — ဘယ် code path ကနေ တောင်းဆိုတောင်ဆို ထိခွင့်မရှိတဲ့ row ကို database က ပြန်မပေးပါဘူး။

ဒီ lesson က သဘောတရားအဆင့်မှာသာ ရပ်ထားပါတယ်။ PostgreSQL ရဲ့ roles-privileges-and-row-security lesson နှင့် Cloud Providers & Platforms course ရဲ့ Supabase lesson နှစ်ခုစလုံးက policy syntax လက်တွေ့ အတိအကျကို ဖော်ပြထားပါတယ်။

Row-Level Security

Database feature တစ်ခုဖြစ်ပြီး access-control policy တွေကို table တစ်ခုနှင့် တိုက်ရိုက် ချိတ်ဆက်ထားလို့ database ကိုယ်တိုင်က connection အဲဒီက ဘယ်သူလဲဆိုတာအပေါ် အခြေခံပြီး ဘယ် row တွေ မြင်/ပြင်နိုင်မလဲ filter လုပ်ပေးပါတယ် — application-level check တွေနဲ့ သီးခြားပြီး ထပ်ဆင့်ထည့်ထားတဲ့ layer တစ်ခုပါ။

ROW-LEVEL SECURITY POLICY LAYER
-------------------------------
NOTES TABLE (raw rows)          RLS POLICY LAYER
+----+-------+-----------+      (owner = current_user)
| id | owner | text      |
+----+-------+-----------+
| 1  | alice | "shopping"|  ---> User A (alice) queries:
| 2  | bob   | "taxes"   |       sees only row 1, 3
| 3  | alice | "recipe"  |
| 4  | carol | "diary"   |  ---> User B (bob) queries:
+----+-------+-----------+       sees only row 2

              Same table, same query shape --
              the policy layer decides what
              each connection is allowed back.

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Row-level security ဟာ application-level authorization မှားရလွယ်ဆုံးနေရာတွေမှာပဲ တန်ဖိုးအရှိဆုံးပါ: multi-tenant app, user-generated content, 'ကိုယ်ပိုင် data' ကို တင်းကျပ်စွာ ခွဲထားရမယ့် table ဘယ်ဟာမဆို။

အောက်က code က ဒီ idea ကို database အစစ်မပါဘဲ simulate လုပ်ပြထားပါတယ်: owner tag ပါတဲ့ row နှင့် 'လက်ရှိ' user ကို ယူပြီး အဲဒီ user မြင်သင့်တဲ့ row တွေကိုသာ filter ချထားပါတယ် — RLS policy အစစ် အလိုအလျောက် enforce လုပ်ပုံ၏ အသေးစားနမူနာပါ။

• Row-level security က database ကိုယ်တိုင်ကို user တစ်ဦးစီက ကိုယ်ပိုင် row ကိုသာ မြင်/ပြင်နိုင်စေဖို့ application code နဲ့ သီးခြား enforce လုပ်စေပါတယ်။
• Authentication တစ်ခုတည်းနဲ့ row-level enforcement မရနိုင်ပါ — identity ကို row ownership နဲ့ ချိတ်ဆက်ပေးတဲ့ policy တမင်လိုအပ်ပါတယ်။
• RLS က application-level authorization ကို အစားထိုးမည့်အစား backup ပေးပါတယ် — layer နှစ်ခုလုံးထားရှိခြင်းက တစ်ခုစီရဲ့ bug ကနေ ကာကွယ်ပေးပါတယ်။

အတူတူ စမ်းရေးကြည့်မယ်

// Simulates what a database row-level-security policy would enforce:
// each connecting user only ever sees rows they own.
function applyRowLevelSecurity(rows, currentUser) {
  return rows.filter((row) => row.owner === currentUser);
}

const notes = [
  { id: 1, owner: "alice", note: "Alice's private note" },
  { id: 2, owner: "bob", note: "Bob's private note" },
  { id: 3, owner: "alice", note: "Alice's second note" },
  { id: 4, owner: "carol", note: "Carol's private note" }
];

console.log("alice sees:", applyRowLevelSecurity(notes, "alice"));
console.log("bob sees:", applyRowLevelSecurity(notes, "bob"));

Note row ၄ ခုပါတဲ့ table ကို "alice" အတွက် filter လုပ်ရင် သူ့ row နှစ်ခု (id 1, 3) ပြန်ရပြီး "bob" အတွက် filter လုပ်ရင် သူ့ row တစ်ခုတည်း (id 2) ပြန်ရပါတယ် — carol ရဲ့ row က user နှစ်ဦးစလုံးအတွက် ဘယ်တော့မှ ပေါ်မလာပါဘူး၊ row-level-security policy အစစ်တစ်ခုက connection တစ်ခုစီရဲ့ ရလဒ်ကို ဘယ်လို scope လုပ်မယ်ဆိုတာနဲ့ အတိအကျ တူညီပါတယ်။

Wikipedia: Row-level security — How Databases Work