किसके पास क्या एक्सेस है: प्रबंधन एप्लिकेशन में उपयोगकर्ता और अधिकार

“हम पासवर्ड शेयर कर लेंगे”

साझा खाता कोई विकल्प नहीं है, यह तो बस वह बचा हुआ विकल्प है जब टूल कुछ और नहीं ऑफ़र करता। यह कुछ महीनों तक अच्छी तरह काम करता है, फिर अचानक अपना बिल लेकर आ जाता है, और वह भी हमेशा सबसे गलत समय पर।

इसके तीन यांत्रिक परिणाम हैं। किसी एक व्यक्ति का एक्सेस हटाने के लिए आपको सभी का पासवर्ड बदलना पड़ता है, जिसका मतलब है कि किसी के जाने के दिन आपको पूरी टीम को फिर से ब्रीफ करना पड़ेगा, यानी उसी दिन, जब आप इसकी चिंता करना सबसे कम चाहते हैं। दूसरा, कोई भी “इस पंक्ति को किसने बदला?” का जवाब नहीं दे सकता, क्योंकि एप्लिकेशन की नज़र में सभी एक ही व्यक्ति हैं। और तीसरा, आप आंशिक एक्सेस नहीं दे सकते: जो व्यक्ति सिर्फ़ कोई आँकड़ा देखने आता है, उसे वही सभी अधिकार मिल जाते हैं जो बिल बनाने वाले को मिलते हैं।

इसलिए यहाँ जोखिम सुरक्षा के नाटकीय अर्थ में नहीं है, कोई भी पंद्रह लोगों की एप्लिकेशन पर हमला नहीं कर रहा है। यह तो अपरिवर्तनीयता का मामला है: एक साझा खाते को अलग-अलग नहीं किया जा सकता, बल्कि उसे पूरी तरह बदलना पड़ता है, और जितना देर से आप यह करते हैं, उतना ही भारी यह बदलाव होगा।

• किसी एक का एक्सेस हटाना = सभी का पासवर्ड बदलना।
• “यह किसने किया?” का कोई जवाब नहीं: एक ही खाता, एक ही पहचान।
• कोई रीड-ओनली एक्सेस नहीं: देखना और संपादित करना दोनों के लिए समान अधिकार।

तीन भूमिकाएँ, और उनके बीच की सटीक सीमा

जैसे ही एप्लिकेशन लॉगिन के लिए कहती है, वह वास्तविक अलग-अलग खाते और तीन भूमिकाएँ लाती है। इनकी संख्या कम रखी गई है, और यह जानबूझकर किया गया है: एक ऐसी अधिकार प्रणाली जिसे आप एक नज़र में नहीं समझ सकते, वह प्रणाली आपके द्वारा गलत तरीके से कॉन्फ़िगर की जाएगी।

प्रशासक सब कुछ कर सकता है, और खातों का प्रबंधन केवल वही करता है: वह नए खाते बनाता है, खाते अक्षम करता है, या किसी का पासवर्ड रीसेट करता है। उपयोगकर्ता एप्लिकेशन के अंदर काम करता है, वह डेटा बनाता है, संपादित करता है, या हटाता है, लेकिन खातों के प्रबंधन को कभी नहीं देखता। रीड-ओनली भूमिका केवल देखने के लिए है: वह सभी जगह नेविगेट कर सकता है, रिकॉर्ड खोल सकता है, डैशबोर्ड पढ़ सकता है, लेकिन कुछ भी लिख नहीं सकता।

जो बात मायने रखती है, वह सूची नहीं है, बल्कि वह जगह है जहाँ अस्वीकृति की रेखा खींची गई है। रीड-ओनली भूमिका के लिए, अवरोध कोई ऐसा बटन नहीं है जिसे स्क्रीन पर छुपा दिया गया हो: प्रत्येक लेखन अनुरोध को मिडलवेयर द्वारा रूट तक पहुँचने से पहले ही 403 कोड के साथ अस्वीकार कर दिया जाता है। कोई छुपाया गया बटन कीबोर्ड या किसी डेवलपर टूल से बाईपास किया जा सकता है; लेकिन ऊपर की ओर लगाई गई अस्वीकृति नहीं। यही अंतर है एक ऐसे इंटरफ़ेस के बीच जो कुछ सुझाता है, और एक ऐसी एप्लिकेशन के बीच जो अपनी सीमाओं को दृढ़ता से लागू करती है।

भूमिका साइन्ड सेशन कुकी में संग्रहीत होती है, जिसके कारण प्रत्येक अनुरोध पर डेटाबेस की जाँच किए बिना ही यह सत्यापन संभव होता है। और कोई भी बिना सेशन के आने वाला आगंतुक कुछ भी पार नहीं कर सकता: पेज उसे लॉगिन स्क्रीन पर भेज देते हैं (उसके जाने की जगह को याद रखते हुए), और API कॉल्स को 401 कोड मिलता है।

• प्रशासक: सब कुछ, और खातों का प्रबंधन भी।
• उपयोगकर्ता: डेटा बनाता है, संपादित करता है, हटाता है; खातों तक कोई पहुँच नहीं।
• रीड-ओनली: सभी जगह नेविगेट करता है और देखता है; प्रत्येक लेखन को रूट से पहले 403 के साथ अस्वीकार कर दिया जाता है।
• बिना सेशन के, API पर 401, पेज पर लॉगिन पर रीडायरेक्ट।

एक्सेस खोलना: एक यूज़रनेम, एक भूमिका, एक अस्थायी पासवर्ड

किसी खाते को बनाने के लिए तीन जानकारियों की आवश्यकता होती है, और उनमें से कोई भी ईमेल पता नहीं है। प्रशासक एक यूज़रनेम दर्ज करता है (2 से 31 अक्षर: अक्षर, अंक, डॉट, हाइफ़न, अंडरस्कोर), भूमिका चुनता है, और एप्लिकेशन स्वयं एक अस्थायी पासवर्ड जनरेट करती है।

यह पासवर्ड केवल एक बार, उसी समय प्रदर्शित किया जाता है। बाद में इसे फिर से पढ़ा नहीं जा सकता, न तो खातों की सूची में, न ही कहीं और: केवल इसका हैश संग्रहीत रखा जाता है। अगर इसे भेजे जाने से पहले खो दिया जाता है, तो प्रशासक एक नया जनरेट कर सकता है, जो केवल दस सेकंड का काम है। इसके अतिरिक्त, खाते को ‘पासवर्ड बदलना आवश्यक’ के रूप में चिह्नित कर दिया जाता है: व्यक्ति को पहली बार लॉगिन करते समय अपना स्वयं का पासवर्ड चुनना होगा, इसलिए प्रशासक कभी भी अपने सहकर्मियों के पासवर्ड को नहीं जान पाएगा।

कोई ईमेल नहीं भेजा जाता है, और यह जानना आपके लिए अपनी व्यवस्था बनाने से पहले ज़रूरी है: एप्लिकेशन में कोई ईमेल भेजने की सुविधा शामिल नहीं है। यूज़रनेम और अस्थायी पासवर्ड को अपने स्वयं के साधनों से भेजने की ज़िम्मेदारी प्रशासक पर है। इसका एक अन्य प्रभाव ईमेल के अभाव से भी अधिक परेशान करने वाला है, यहाँ कोई स्व-सेवा “पासवर्ड भूल गया” विकल्प नहीं है: जो कोई भी अपना पासवर्ड खो देता है, वह प्रशासक के माध्यम से ही इसे रीसेट करवा सकता है।

पहला खाता एप्लिकेशन के साथ ही बनाया जाता है: यूज़रनेम “admin”, पासवर्ड “admin”, और पहली बार लॉगिन करते समय इसे बदलना अनिवार्य है। यह कोई वास्तविक पासवर्ड नहीं है, बल्कि एक प्रारंभिक सेटअप पासवर्ड है, और एप्लिकेशन आपको इसे बनाए रखने नहीं देगी।

• यूज़रनेम + भूमिका: प्रशासक केवल यही दर्ज करता है।
• अस्थायी पासवर्ड एप्लिकेशन द्वारा जनरेट किया जाता है, और केवल एक बार प्रदर्शित किया जाता है।
• पहली बार लॉगिन करते समय अनिवार्य परिवर्तन, इसके बाद प्रशासक को यह नहीं पता होगा।
• कोई ईमेल नहीं: भेजना और रीसेट करना दोनों प्रशासक के माध्यम से होते हैं।

इतिहास में कोई छेद बनाए बिना एक्सेस बंद करना

कोई खाता नहीं हटाया जाता, बल्कि अक्षम कर दिया जाता है, और बाद में पुनः सक्रिय किया जा सकता है। यह कोई कार्यान्वयन की सुविधा नहीं है, बल्कि डेटा की ट्रैश के समान ही एक निर्णय है: एक बार पूरी तरह हटाया गया रिकॉर्ड उससे जुड़े सभी डेटा को भी साथ ले जाता है, और आपको यह तब पता चलता है जब महीनों बाद आप कुछ ऐसा ढूँढ़ते हैं जो अब मौजूद नहीं है।

कोड में दो अस्वीकृतियाँ लिखी गई हैं, और यही वे हैं जो आपको खुद को बाहर करने से रोकती हैं। आप अपना स्वयं का खाता अक्षम नहीं कर सकते, जो एक सूची साफ़ करते समय सबसे आसानी से गलती से किया जा सकने वाला कार्य है। और आप अंतिम सक्रिय प्रशासक का खाता भी अक्षम नहीं कर सकते: कोई प्रशासक वाली एप्लिकेशन वह है जिसमें कोई भी फिर से किसी का एक्सेस नहीं खोल सकता, न तो दूसरों के लिए, न ही अपने लिए। यह अस्वीकृति स्पष्ट रूप से दिखाई जाती है, यह केवल विफल होने के लिए नहीं है।

इसलिए किसी के जाने का प्रबंधन एक ही कार्य से हो जाता है, बिना किसी अन्य के पासवर्ड को छुए, और बिना किसी रिकॉर्ड को मिटाए। किसी के स्थान पर किसी नए को लाने के लिए दो कार्य करने होते हैं: पहले अक्षम करें, फिर नया बनाएँ।

• अक्षम करना उलटा जा सकता है, हटाना नहीं।
• अपना स्वयं का खाता अक्षम करना असंभव है।
• अंतिम सक्रिय प्रशासक का खाता अक्षम करना असंभव है।
• प्रशासक द्वारा किसी भी समय पासवर्ड को रीसेट करना।

जो यह नहीं करता, और आपको पहले जानना बेहतर है

अधिकार पूरी एप्लिकेशन के लिए वैश्विक हैं। कोई खाता एक भूमिका ले सकता है, और यह भूमिका किसी भी एंटिटी, किसी भी सेक्शन, या किसी भी फ़ील्ड से जुड़ी नहीं होती। इसलिए “यह सेल्स पर्सन केवल अपने ग्राहकों को देख सकता है”, “यह व्यक्ति हस्तक्षेप तक पहुँच सकता है लेकिन बिलिंग तक नहीं”, या “यह फ़ील्ड गैर-प्रबंधकों के लिए छुपाई गई है” जैसे कथन व्यक्त करने का कोई भी तरीका नहीं है। तीन भूमिकाएँ “देखें या संपादित करें” के प्रश्न को अच्छी तरह से कवर करती हैं, लेकिन “कौन सा हिस्सा” के प्रश्न को बिल्कुल नहीं।

एप्लिकेशन केवल यह रिकॉर्ड करती है कि डेटा कब बदला गया, कभी यह नहीं कि किसने बदला। प्रत्येक रिकॉर्ड में स्वतः उसकी रचना की तारीख और अंतिम संशोधन की तारीख शामिल होती है, लेकिन कोई भी कॉलम लेखक को नहीं रखता। अलग-अलग खाते इसलिए “कौन प्रवेश कर सकता है” का जवाब देते हैं, न कि “इस पंक्ति को किसने लिखा” का, ये दो अलग-अलग प्रश्न हैं, और केवल पहला ही संबोधित किया गया है। यह सबसे आसान सीमा है जिसे एक वितरित क्षमता के साथ भ्रमित किया जा सकता है, क्योंकि नामित खाते होने के कारण लगता है कि आपके पास ऑडिट ट्रेल है।

लॉगिन केवल यूज़रनेम और पासवर्ड के माध्यम से होता है, और कुछ भी नहीं। कोई Google या Microsoft खाते के माध्यम से लॉगिन नहीं, कोई उद्यम-स्तरीय एकल साइन-ऑन नहीं, कोई दूसरा कारक नहीं। जिस टीम के पास पहले से ही अपनी पहचानें कहीं और प्रबंधित हो रही हैं, उनके लिए यह एक और खातों की सूची का प्रबंधन करने का मामला है।

ये चार सीमाएँ कोई भूल या छूट नहीं हैं जिन्हें घेरा जा सके: ये वही सीमाएँ हैं जो वितरित की गई हैं, और इन्हें लिखना उन्हें खोजने से कहीं अधिक उपयोगी है। इन सभी का एक ही समाधान है, जो उत्पाद का मूल उद्देश्य भी है, एप्लिकेशन का कोड आपका है। यह एक मानक Next.js और Prisma प्रोजेक्ट है, जिसे ZIP के रूप में एक्सपोर्ट किया जा सकता है या आपके स्वयं के रिपॉजिटरी पर पुश किया जा सकता है: लेखक कॉलम जोड़ना, टीम के आधार पर विभाजन करना, या उद्यम-स्तरीय प्रमाणीकरण जोड़ना, ये सभी सामान्य विकास कार्य हैं, जो आपके स्वामित्व वाले कोड पर किए जाते हैं, और कोई भी विक्रेता आपको इन्हें करने से रोक नहीं सकता। और अगर विभाजन आपके व्यवसाय के लिए संरचनात्मक रूप से आवश्यक है, तो इसे शुरुआत में ही वर्णित कर दिया जाना चाहिए, यह आपका वर्णन ही एंटिटीज़ और उनके संबंधों को निर्धारित करता है।

• वैश्विक अधिकार: कोई एंटिटी, सेक्शन या फ़ील्ड के आधार पर विभाजन नहीं।
• संशोधन की तारीख रिकॉर्ड की गई है, लेकिन लेखक नहीं।
• केवल यूज़रनेम और पासवर्ड: कोई SSO, कोई तृतीय-पक्ष लॉगिन, कोई दूसरा कारक नहीं।
• सामान्य समाधान: कोड आपका है, और ये विस्तार सामान्य विकास हैं।