क्या एक उत्पन्न एप्लिकेशन पर कई उपयोगकर्ताओं का होना संभव है?

“कई उपयोगकर्ता” का व्यावहारिक अर्थ क्या है

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

यह कोई अलग से सक्रिय करने योग्य सुविधा नहीं है: जैसे ही आपके प्रोजेक्ट के वर्णन में लॉगिन की आवश्यकता स्पष्ट होती है (आपकी टीम के लिए सीमित पहुँच, एक सार्वजनिक पृष्ठ के विपरीत), खाता प्रबंधन स्वतः ही बिल्डर द्वारा उत्पन्न किए गए आउटपुट का हिस्सा हो जाता है।

खाता कैसे बनाया जाता है

‘सेटिंग्स’ स्क्रीन से, प्रशासक एक पहचानकर्ता (जैसे ईमेल या उपयोगकर्ता नाम) दर्ज करता है और भूमिका चुनता है (संपादन करने योग्य या केवल-पठन), फिर पुष्टि करता है। एप्लिकेशन एक एकल-उपयोग के अस्थायी पासवर्ड के साथ प्रतिक्रिया देती है, जो केवल एक बार प्रदर्शित किया जाता है, बाद में न तो प्रशासक और न ही कोई अन्य व्यक्ति उसे पुनः पढ़ सकता है। व्यक्ति उसका उपयोग लॉगिन करने के लिए करता है और पहली बार लॉगिन करते समय उसे अपने व्यक्तिगत पासवर्ड से अवश्य बदल देता है।

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

केवल-पठन भूमिका वास्तव में क्या रोकती है

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

जो कुछ इसमें शामिल नहीं है

दो सीमाएँ, स्पष्ट शब्दों में बताई गईं। पहली: भूमिकाएँ पूरी एप्लिकेशन के स्तर पर वैश्विक होती हैं, कोई सूक्ष्म-स्तरीय अनुमति नहीं है, न तो प्रत्येक एंटिटी (जैसे ग्राहक, बिल) के आधार पर, न ही प्रत्येक अनुभाग के आधार पर (“यह खाता ग्राहकों को देख सकता है, लेकिन बिलिंग नहीं”), यह संपूर्ण एप्लिकेशन के लिए संपादन या केवल-पठन है। दूसरी: उत्पन्न एप्लिकेशन के खातों पर दो-कारक प्रमाणीकरण (2FA) नहीं है: एकल-उपयोग का अस्थायी पासवर्ड और पहली बार लॉगिन करते समय अनिवार्य पुनः सेट करना ही निर्धारित सुरक्षा है, कोई दूसरा कारक नहीं। यदि आपके व्यवसाय को अधिक सूक्ष्म अनुमतियों या 2FA की आवश्यकता है, तो चूँकि कोड मानक, निर्यात योग्य Next.js और Prisma है, कोई डेवलपर मौजूदा कोड पर आधारित इन्हें जोड़ सकता है।