पर्सनल कैबिनेट और पोर्टल
पर्सनल कैबिनेट और क्लाइंट पोर्टल: उपयोगकर्ता लॉगिन से आता है और सिर्फ़ अपना देखता है — ऑर्डर, दस्तावेज़, स्टेटस। मैनेजर को फ़ोन करने की जगह सेल्फ़-सर्विस, डेटा आपके नियंत्रण में।
सेवा में क्या शामिल है
हम पर्सनल कैबिनेट और क्लाइंट पोर्टल बनाते हैं, जहाँ आपके उपयोगकर्ता अपने लॉगिन से आते हैं और सिर्फ़ अपना देखते हैं: ऑर्डर, दस्तावेज़, स्टेटस, डेटा, पूछताछ का इतिहास। इसमें आपकी प्रक्रिया के हिसाब से डिज़ाइन, सुरक्षित ऑथराइज़ेशन, रोल के हिसाब से राइट्स का बँटवारा, ज़रूरी डेटा वाले पर्सनल सेक्शन और आपकी सिस्टमों — CRM, अकाउंटिंग, भुगतान — से इंटीग्रेशन शामिल हैं। कैबिनेट मैनेजरों का बोझ हल्का करता है: क्लाइंट ख़ुद ऑर्डर का स्टेटस देखता है, दस्तावेज़ डाउनलोड करता है और पूछताछ छोड़ता है, हर सवाल पर फ़ोन किए बिना। सिस्टम हम आपके सर्वर पर तैनात करते हैं, और उपयोगकर्ताओं का डेटा आपके नियंत्रण में रहता है। नतीजे में आपको एक काम करने वाला सेल्फ़-सर्विस औज़ार मिलता है, जो क्लाइंट के साथ आपकी काम की लॉजिक दोहराता है, न कि फ़ालतू फ़ील्डों वाला यूनिवर्सल बॉक्स।
यह असल में कैसे बना है
कैबिनेट के आधार में प्रमाणीकरण और एक्सेस का बँटवारा है। जब उपयोगकर्ता लॉगिन और पासवर्ड से आता है, सर्वर उसे जाँचता है और एक एन्क्रिप्टेड सेशन-चिह्न देता है, जिसे ब्राउज़र रखता है और हर अगली रिक्वेस्ट पर पेश करता है — इस तरह सिस्टम उपयोगकर्ता को पहचानती है, हर पेज पर पासवर्ड पूछे बिना। इसके ऊपर ऑथराइज़ेशन काम करता है: नियम, जो तय करते हैं कि किसी उपयोगकर्ता या रोल को कौन-सा डेटा और क्रिया उपलब्ध है, ताकि क्लाइंट सिर्फ़ अपने ऑर्डर देखे और कर्मचारी — अपना हिस्सा। डेटा आपकी सिस्टमों से सुरक्षित इंटीग्रेशनों के ज़रिए खींचा जाता है और पर्सनल सेक्शनों में दिखाया जाता है। सभी क्रियाएँ लॉग होती हैं, और संवेदनशील ऑपरेशन अतिरिक्त जाँचों से सुरक्षित होते हैं। यह ढाँचा हम आपकी प्रक्रिया के हिसाब से बनाते हैं, न कि आपकी प्रक्रिया को तैयार पैनल के नीचे ढालते हैं।
पर्सनल कैबिनेट कहाँ से आए
पर्सनल कैबिनेट उस तंत्र की बदौलत संभव हुए जिसने साइट को पेजों के बीच उपयोगकर्ता को याद रखने दिया: HTTP-cookie का आविष्कार लू मोंटुली ने Netscape कंपनी में जून 1994 में किया, और ठीक पहली कुकीज़ जाँचती थीं कि विज़िटर पहले साइट पर आया था या नहीं। सेशनों के आधार पर सुरक्षित पर्सनल सेक्शन उभरे, और पोर्टलों की विधा ख़ुद 1990 के दशक के अंत में आकार पाई, जब कंपनियाँ पर्सनल एक्सेस वाली पोर्टल-साइटें बनाने लगीं। सर्विसों के बीच सुरक्षित प्रत्यायोजित पहुँच का स्टैंडर्ड — OAuth 2.0 — अक्टूबर 2012 में RFC 6749 दस्तावेज़ में तय हुआ, और यह तीसरे-पक्ष अकाउंटों से आधुनिक लॉगिन तथा एप्लिकेशनों की डेटा तक पहुँच की बुनियाद है। हम कैबिनेट को सेशनों और ऑथराइज़ेशन के इन परिपक्व तंत्रों पर बनाते हैं, न कि ख़ुद-बनाई स्कीमों पर, जो परिभाषा से छेददार होती हैं।
एक्सेस की सुरक्षा क्यों अहम है
पर्सनल कैबिनेट क्लाइंटों के संवेदनशील डेटा के साथ काम करता है, इसलिए एक्सेस में गलती की कीमत — किसी और के ऑर्डर, दस्तावेज़ों या व्यक्तिगत डेटा का लीक। राइट्स की जाँच में एक छेद, जिसमें उपयोगकर्ता किसी और का आइडेंटिफ़ायर डालकर अपना नहीं वह डेटा देख सके, एक सुविधाजनक औज़ार को लीक और प्रतिष्ठा-आघात का स्रोत बना देता है। इसलिए मुख्य इंजीनियरिंग काम — कैबिनेट की दिखावट नहीं, बल्कि सख़्त ऑथराइज़ेशन: हर रिक्वेस्ट पर जाँच कि उपयोगकर्ता का ठीक इसी डेटा और क्रिया पर हक़ है। इतने ही अहम हैं सेशनों की सुरक्षा, पासवर्डों का एन्क्रिप्टेड रूप में भंडारण और संवेदनशील ऑपरेशनों पर अतिरिक्त जाँचें। हम कैबिनेट को एक सुरक्षा सिस्टम की तरह मानते हैं, न कि सुंदर पैनल की तरह, और प्रोडक्शन लॉन्च से पहले एक्सेस राइट्स जाँचते हैं। नतीजे में हर उपयोगकर्ता सिर्फ़ अपना देखता है, और बाकी का डेटा बदलाव की कोशिश पर भी उपलब्ध नहीं होता।
हम किस स्टैक पर काम करते हैं
कैबिनेट का सर्वर हिस्सा हम सख़्त फ़्रेमवर्कों पर बनाते हैं — PHP पर Laravel या Node पर आधुनिक फ़्रेमवर्क — जो ऑथराइज़ेशन, फ़ॉर्म-सुरक्षा और डेटाबेस के साथ काम के तैयार तथा परखे तंत्र देते हैं। प्रमाणीकरण और सेशन हम मानक सुरक्षित तरीकों पर लागू करते हैं, और ज़रूरत पड़ने पर OAuth 2.0 प्रोटोकॉल से तीसरे-पक्ष अकाउंटों के ज़रिए लॉगिन जोड़ते हैं। डेटा हम PostgreSQL डेटाबेस में रखते हैं, और आपकी सिस्टमों — CRM, अकाउंटिंग, भुगतान — से इंटीग्रेशन सुरक्षित API के ज़रिए करते हैं। पर्सनल सेक्शन और रोल के हिसाब से राइट्स हम आपकी प्रक्रिया के हिसाब से सेट करते हैं, न कि यूनिवर्सल टेम्पलेट के हिसाब से। स्टैक ओपन है, कोड और डेटा आपके सर्वर पर तैनात होते हैं, इसलिए कैबिनेट आपकी एसेट रहती है, इसे किसी एक सप्लायर से बँधे बिना विकसित और दूसरे डेवलपरों को सौंपा जा सकता है।
प्रमुख तकनीकें कब आईं
पर्सनल कैबिनेटों की तकनीकें लगभग तीन दशकों में बनीं। HTTP-cookie पर आधारित सेशनों का तंत्र लू मोंटुली ने Netscape में जून 1994 में आविष्कार किया, और उसके बिना पर्सनल सेक्शन में कोई भी लॉगिन संभव नहीं। पर्सनल एक्सेस वाली वेब-पोर्टलों की विधा 1990 के दशक के अंत में आकार पाई। प्रत्यायोजित पहुँच का स्टैंडर्ड OAuth 2.0, जिस पर तीसरे-पक्ष अकाउंटों से लॉगिन टिका है, अक्टूबर 2012 में RFC 6749 में तय हुआ। फ़्रेमवर्क, जिन पर हम सर्वर हिस्सा बनाते हैं, — पहले से आधुनिक पीढ़ी हैं जिनमें अंतर्निहित सुरक्षित ऑथराइज़ेशन है। हम मौजूदा और परखे तंत्र इस्तेमाल करते हैं, न कि ख़ुद-बनाया प्रमाणीकरण गढ़ते हैं, जिसमें गलतियों की कीमत डेटा का लीक होती है।
यह हम पर क्यों भरोसा किया जा सकता है
हमारी टीम का IT में कुल अनुभव 45 साल से ज़्यादा है, और पर्सनल कैबिनेट हम एक सुरक्षा सिस्टम की तरह बनाते हैं, न कि एक शोकेस की तरह। हम इंजीनियरिंग ढंग से देखते हैं: एक्सेस मॉडल डिज़ाइन करते हैं, हर रिक्वेस्ट पर राइट्स की जाँच के साथ सख़्त ऑथराइज़ेशन लागू करते हैं और टेस्ट सर्किट पर ज़रूर जाँचते हैं कि उपयोगकर्ता आइडेंटिफ़ायर बदलकर किसी और का डेटा नहीं देख सकता। कोड और डेटा आपके सर्वर पर तैनात होते हैं और आपके होते हैं — फ़ीचरों की सब्सक्रिप्शन फ़ीस और हमारी सर्विस से बँधाव के बिना। हम सीधे कहेंगे कि कहाँ कैबिनेट सचमुच ज़रूरी है और कहाँ काम को कोई सादा समाधान बंद कर देगा। नतीजे में आपको एक सुरक्षित सेल्फ़-सर्विस औज़ार मिलता है, जो मैनेजरों का बोझ हल्का करता है और क्लाइंट के साथ आपकी काम की लॉजिक दोहराता है, न कि किसी और की सीमाओं वाला बॉक्स।
क्या शामिल है
हम कैसे काम करते हैं
सुरक्षित सेल्फ़-सर्विस औज़ार: क्लाइंट सिर्फ़ अपना देखता है, मैनेजरों का बोझ हल्का।
सवाल और जवाब
किसी और का डेटा लीक तो नहीं होगा?+
नहीं — सख़्त ऑथराइज़ेशन हर रिक्वेस्ट पर राइट्स जाँचता है; किसी और का आइडेंटिफ़ायर डालना काम नहीं करेगा।
Google/सोशल मीडिया से लॉगिन?+
हाँ — ज़रूरत पड़ने पर OAuth 2.0 से तीसरे-पक्ष अकाउंटों के ज़रिए लॉगिन जोड़ते हैं।
कोड और डेटा किसके?+
आपके — आपके सर्वर पर तैनात करते हैं, बिना सब्सक्रिप्शन फ़ीस और हमसे बँधाव के।