अपने ऐप में Role-Based Access Control (RBAC) कैसे जोड़ें
Role-based access control जोड़ने के लिए, हर user को एक या अधिक roles दें (जैसे admin, editor, viewer), तय करें कि हर role कौन से कार्य कर सकता है, और हर request के लिए ये permissions सर्वर पर जाँचें — केवल buttons छिपाकर नहीं। यह भी जाँचें कि जिस record तक पहुँचा जा रहा है वह user के account या team का है। अपने database में कुछ तय roles से शुरू करें, और दूसरे user के डेटा तक सीधे पहुँचने की कोशिश करके टेस्ट करें।
Authentication बनाम authorisation
दो शब्द जो अक्सर मिला दिए जाते हैं:
- Authentication है आप कौन हैं? — login करना। देखें अपने ऐप में login कैसे जोड़ें।
- Authorisation है आपको क्या करने की अनुमति है? — कौन से pages, records और actions एक लॉग-इन user तक पहुँच सकता है।
RBAC authorisation करने का सबसे आम तरीका है। यह मायने रखता है: सितंबर 2026 तक, Broken Access Control, OWASP Top 10:2025 में नंबर 1 पर है, जो सबसे गंभीर web application सुरक्षा जोखिमों की व्यापक रूप से इस्तेमाल होने वाली सूची है। आम विफलताएँ हैं: URL में ID बदलकर दूसरे users के records पढ़ना, या साधारण users का केवल-admin API routes को call करना।
Model चुनें
| Model | यह कैसे काम करता है | किसके लिए अच्छा | समझौता |
|---|---|---|---|
| एक role column | users.role = admin / member | दो-तीन roles वाले छोटे ऐप्स | जब लोगों को अलग-अलग जगह अलग roles चाहिए हों, तो गड़बड़ होने लगती है |
| Roles + permissions | Roles नाम वाली permissions से जुड़े होते हैं (invoices.approve); कोड permissions जाँचता है | ऐसे ऐप्स जिनके नियम बढ़ेंगे | ज़्यादा tables; रखरखाव के लिए permissions की सूची |
| हर team के लिए (multi-tenant) roles | एक membership table: user + organisation + role | SaaS जहाँ लोग teams या workspaces में होते हैं | हर query को organisation तक सीमित करना होगा |
| Attribute या relationship पर आधारित | Record के attributes पर नियम ("लेखक अपनी post संपादित कर सकता है") या रिश्तों पर (साझा किया गया) | Documents, sharing, जटिल workflows | समझना कठिन; एक समर्पित library या service पर विचार करें |
| Auth provider के roles | आपका login provider roles या organisation memberships सहेजता है | ऐप्स जो पहले से hosted auth provider इस्तेमाल करते हैं | उस provider से बँधा; फिर भी आपके सर्वर पर लागू करें |
व्यवहार में ज़्यादातर ऐप्स दो चीज़ें मिलाते हैं: roles यह तय करने के लिए कि कोई किस तरह के कार्य कर सकता है, और स्वामित्व यह तय करने के लिए कि वह किन records पर कर सकता है। "Editors posts संपादित कर सकते हैं" एक role नियम है; "…अपने workspace की posts" एक स्वामित्व नियम है। आपको दोनों चाहिए।
आप जितना सोचते हैं उससे सरल शुरू करें। Admin, member और viewer कितने ही ऐप्स के लिए काफ़ी होते हैं। बाद में एक role को बाँटना दस ऐसे roles को सुलझाने से आसान है जिन्हें कोई समझता न हो।
कोड लिखने से पहले roles डिज़ाइन करें
पहले सादी भाषा में एक permission table लिखें। यह AI के लिए spec और आपकी टेस्ट योजना, दोनों का काम करता है:
| कार्य | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| Team के projects देखना | ✓ | ✓ | ✓ | ✓ |
| Projects बनाना और संपादित करना | ✓ | ✓ | ✓ | |
| Projects हटाना | ✓ | ✓ | ||
| लोगों को आमंत्रित करना और हटाना | ✓ | ✓ | ||
| Roles बदलना | ✓ | |||
| Billing | ✓ |
किनारे के मामले भी तय करें: क्या आख़िरी owner छोड़ सकता है? क्या admin owner को हटा सकता है? हटाए गए user को क्या दिखता है?
चरण दर चरण
1. पहले काम करने वाला login रखें
RBAC authentication के ऊपर बैठता है। सर्वर को हर request करने वाले user को भरोसे से पता होना चाहिए, session या सत्यापित token से — कभी उस user ID से नहीं जो browser request body में भेजता है।
2. Roles database में सहेजें
एक ही team वाले ऐप के लिए users पर एक role column ठीक है। Teams के लिए एक 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 से users को अपना role ख़ुद सेट न करने दें। Role बदलना एक समर्पित, permission-जाँच वाले endpoint से हो।
3. Permissions सर्वर पर, एक ही जगह जाँचें
एक helper लिखें — कुछ ऐसा जैसे can(user, 'projects.delete', project) — और हर API route, server action और background task में, जो डेटा पढ़ता या बदलता है, उसे बुलाएँ। एक केंद्रीय function को कोड की समीक्षा और टेस्ट करना, पूरे कोड में बिखरी जाँचों से आसान है। Default रूप से मना करें: अगर कोई नियम कार्य की अनुमति नहीं देता, तो उसे अस्वीकार किया जाता है।
4. हर query को सीमित करें
Team के डेटा की हर query में team शामिल होनी चाहिए: where organization_id = :currentOrg, केवल where id = :id नहीं। यही रोकता है कि कोई /projects/123 को /projects/124 करके दूसरी कंपनी का project न देख ले। दूसरी teams के records के लिए "forbidden" की बजाय "not found" लौटाएँ, ताकि यह न पता चले कि वे मौजूद हैं।
5. जहाँ मायने रखता है, वहाँ database-स्तर की सुरक्षा जोड़ें
Postgres row-level security (RLS) database को तय करने देती है कि हर user कौन सी rows देख सकता है। यह ज़रूरी है अगर browser सीधे database से बात करता है (जैसे कुछ hosted backends में), और बाकी मामलों में संवेदनशील tables के लिए एक उपयोगी दूसरी परत है।
6. Interface में roles दिखाएँ
अब वह छिपाएँ या निष्क्रिय करें जो users नहीं कर सकते, ताकि ऐप भ्रमित न करे। यह केवल उपयोगिता के लिए है; सुरक्षा सर्वर की जाँचें करती हैं।
7. संवेदनशील कार्यों का लॉग रखें
दर्ज करें कि किसने roles बदले, डेटा हटाया या records export किए, और कब। Audit log support के सवालों और घटनाओं में मदद करता है।
8. हमलावर की तरह टेस्ट करें
हर role से लॉग इन करें और permission table का हर कार्य आज़माएँ। फिर वे चीज़ें आज़माएँ जो काम नहीं करनी चाहिए: viewer के रूप में admin API routes call करना, URLs और requests में ID बदलना, आख़िरी owner के रूप में ख़ुद को हटाना। नियम स्थिर होने पर permission table के लिए automated tests लिखना उपयोगी है।
काम करने वाले prompts
Role-based access control जोड़ो। हर organisation के लिए roles: owner, admin, member, viewer, memberships table में सहेजे गए। Permissions इस table में हैं: [अपनी table चिपकाएँ]। एक सर्वर-साइड can(user, action, resource) helper बनाओ, default रूप से मना करो, और उसे हर API route में इस्तेमाल करो। हर query को organization_id से सीमित करो। UI में वे actions छिपाओ जो user नहीं कर सकता, पर सुरक्षा के लिए उस पर कभी भरोसा मत करो।
इस ऐप के हर API route और server function की समीक्षा करो। हर एक के लिए सूची दो कि वह कौन सा डेटा पढ़ता या बदलता है, क्या जाँचता है कि user logged-in है, क्या उसका role जाँचता है, और क्या query उसके organisation तक सीमित है। जिसमें जाँच छूटी हो उसे ठीक करो, और सूची मुझे दिखाओ।
केवल-admin /admin पेज जोड़ो जहाँ owner members के roles बदल सके। आख़िरी owner को हटाने या उसका पद घटाने से रोको, हर role बदलाव को यह दर्ज करते हुए लॉग करो कि किसने और कब किया, और सुनिश्चित करो कि role-बदलाव endpoint हर उस व्यक्ति को अस्वीकार करे जो owner नहीं है।
आम गलतियाँ
- Roles केवल front end पर जाँचना। API तब भी हर उस व्यक्ति के लिए खुला है जो उसे call करे।
- Client से आए IDs पर भरोसा करना — request body में
userIdयाroleलेना, session की जगह। - Unscoped queries जो केवल record ID से डेटा लाती हैं।
- Pages पर roles जाँचे जाते हैं पर API routes, exports, file downloads या webhooks पर नहीं।
- कोड में hard-coded email पते से admin (
if email === 'me@...'), जिसे भूलना आसान और बदलना कठिन है। - बहुत जल्दी बहुत सारे roles, जिन्हें छह महीने बाद कोई समझा न सके।
- पुराने sessions: पद घटाया गया user logout होने तक admin अधिकार रखता है। संवेदनशील कार्यों पर database से roles जाँचें, या उन्हें ताज़ा करें।
RBAC चेकलिस्ट
- Permission table सादी भाषा में लिखी गई, किनारे के मामले तय
- सर्वर user को session से जानता है, कभी request data से नहीं
- Roles database में सहेजे गए; users अपना role ख़ुद नहीं बदल सकते
- एक केंद्रीय permission जाँच, default रूप से मना, हर route में इस्तेमाल
- हर query user के organisation या स्वामित्व तक सीमित
- जहाँ browser database तक पहुँच सकता है, वहाँ row-level security
- UI वे चीज़ें छिपाता है जो users नहीं कर सकते (केवल उपयोगिता के लिए)
- संवेदनशील कार्य लॉग होते हैं
- हर role टेस्ट किया गया, सीधे API calls और बदले गए IDs सहित
Access control सुरक्षा की एक लंबी सूची का एक हिस्सा है; बाकी के लिए AI से बने ऐप्स के लिए सुरक्षा चेकलिस्ट देखें। अगर आप अपने स्टाफ़ के लिए tool बना रहे हैं, तो आंतरिक tool कैसे बनाएँ दिखाता है कि roles कहाँ फ़िट होते हैं।
Mythex पर RBAC
Mythex आपके ऐप के users के लिए built-in login या roles सिस्टम नहीं देता। आप एक auth library या provider चुनते हैं और roles का वर्णन करते हैं, और agent उन्हें आपके कोड और आपके प्रोजेक्ट के Postgres database से जोड़ता है (अपने ऐप में login जोड़ें)। Mythex के अपने workspace roles, जैसे Owner और Member, यह नियंत्रित करते हैं कि आपके Mythex projects कौन संपादित कर सकता है, न कि यह कि आपका publish किया गया ऐप कौन इस्तेमाल कर सकता है। बनाने से पहले permission table पर सहमति के लिए Plan mode इस्तेमाल करें, फिर ऊपर की समीक्षा prompt चलाएँ और publish करने से पहले Preview में हर role टेस्ट करें। Docs के सुरक्षा prompts एक उपयोगी अगला कदम हैं।
सवाल
Role-based access control क्या है?
Role-based access control (RBAC) तय करता है कि हर user क्या कर सकता है, उसके roles के आधार पर, जैसे admin, editor या viewer। Permissions व्यक्तियों की बजाय roles से जुड़ी होती हैं, इसलिए किसी की अनुमति बदलने के लिए उसका role बदलना काफ़ी है।
Authentication और authorisation में क्या अंतर है?
Authentication जाँचता है कि कोई व्यक्ति कौन है, आमतौर पर login से। Authorisation तय करता है कि वह लॉग-इन व्यक्ति क्या देख और कर सकता है। RBAC authorisation करने का एक तरीका है।
क्या interface में buttons छिपाना access सीमित करने के लिए काफ़ी है?
नहीं। कोई भी सीधे आपका API call कर सकता है, इसलिए button छिपाने से केवल यह बदलता है कि लोग क्या देखते हैं। हर request जो डेटा पढ़ता या बदलता है, उसे सर्वर पर user के role और record पर उसके स्वामित्व के आधार पर जाँचा जाना चाहिए।
क्या मुझे Postgres row-level security इस्तेमाल करनी चाहिए?
Row-level security database को ख़ुद तय करने देती है कि हर user कौन सी rows पढ़ या लिख सकता है, जो एक मज़बूत सुरक्षा जाल है, ख़ासकर जब front end सीधे database से बात करता हो। इसमें जटिलता बढ़ती है, इसलिए कई ऐप्स permissions सर्वर कोड में लागू करते हैं और संवेदनशील tables के लिए row-level security को एक अतिरिक्त परत के रूप में इस्तेमाल करते हैं।