सेवा सदस्य लॉगिन

मान लीजिए आप एक कपड़ों की दुकान का ऑनलाइन शॉपिंग साइट चलाते हैं। कई बार आप चाहते हैं कि ग्राहक खुद सदस्य के रूप में साइन अप करें, और केवल सदस्य ही समीक्षाएं लिख सकें या श्रेणी के अनुसार लाभ पा सकें। इसके लिए आपको एक ऐसी "सदस्यता प्रणाली" चाहिए जिसमें ग्राहक खुद साइन अप करके लॉगिन करें। इस सदस्यता प्रणाली को आपकी साइट से जोड़ने वाली Space सुविधा है ServiceLogin (आपकी सेवा में ग्राहक खुद साइन अप करके इस्तेमाल करते हैं, वह लॉगिन सेटिंग)।

ServiceLogin को चालू करने पर ग्राहक Google जैसे सोशल खाते से कोई भी सीधे साइन अप कर सकता है। साइन अप करने वाला हर एक ग्राहक एक ServiceUser (आपकी सेवा में साइन अप किया हुआ सदस्य) बन जाता है। लॉगिन की प्रक्रिया और लॉगिन की स्थिति बनाए रखने का काम WEEGLOO आपकी ओर से संभालता है, इसलिए आपको पासवर्ड खुद संग्रहीत करने या सोशल लॉगिन को शुरू से बनाने की ज़रूरत नहीं होती।

इस पेज पर पहले हम देखेंगे कि ServiceLogin क्या है और यह संचालन टीम के खातों से कैसे अलग है, उसके बाद कपड़ों की दुकान वाले Space में ServiceLogin को खुद चालू करके सेट करेंगे।

सदस्य संचालन टीम से अलग होते हैं

WEEGLOO में लॉगिन करने वाले दो तरह के लोग होते हैं। यह आसानी से उलझा सकता है, इसलिए पहले सीमा खींच लेते हैं।

संचालन टीम/टीम वे लोग हैं जो उत्पाद दर्ज करते हैं और साइट का प्रबंधन करते हैं। वे ग्राहकों की तरह ServiceLogin से साइन अप नहीं करते, बल्कि WEEGLOO खाते से इस Space के सदस्य बनकर आते हैं (पहले से अंदर मौजूद किसी व्यक्ति के आमंत्रण और भूमिका सौंपने से)। संचालन टीम के अधिकार भूमिका और अधिकार में बताए गए हैं।
ServiceUser वह ग्राहक/सदस्य है जो उस साइट का उपयोग करता है। यह वह व्यक्ति है जिसने आपकी चलाई हुई कपड़ों की दुकान वाली साइट पर सोशल खाते से सीधे साइन अप किया है। यह संचालन टीम से बिल्कुल अलग लॉगिन है।

संक्षेप में, संचालन टीम "दुकान चलाने वाले लोग" हैं, और ServiceUser "दुकान पर आए हुए ग्राहक" हैं। ServiceLogin इन ग्राहकों के आने-जाने के लिए एक दरवाज़ा बनाने का काम है।

साथ चलने वाली तीन चीज़ें

सदस्यता प्रणाली में तीन चीज़ें एक-दूसरे से जुड़कर चलती हैं।

ServiceLogin: यह लॉगिन सेटिंग ही है। कौन सा सोशल लॉगिन इस्तेमाल करना है, साइन अप किए सदस्य को डिफ़ॉल्ट रूप से कौन से अधिकार देने हैं, जैसी बातें यहीं तय होती हैं।
ServiceUserRole: सदस्य को दिए जाने वाले अधिकारों का समूह है। यह तय करता है कि सदस्य क्या देख सकता है और क्या लिख सकता है।
ServiceUser: साइन अप किया हुआ हर एक सदस्य है। हर बार जब कोई ग्राहक साइन अप करता है, एक नया बनता है।

यह पेज दरवाज़ा खोलने वाली ServiceLogin सेटिंग पर केंद्रित है। सदस्य असल में क्या देख और इस्तेमाल कर सकता है (अधिकार), यह तय करने वाली ServiceUserRole सदस्य भूमिका और अधिकार में अलग से बताई गई है। नीचे की सेटिंग में चुनी जाने वाली डिफ़ॉल्ट Role ही उस पेज पर बनाई जाने वाली भूमिका है।

ServiceLogin चालू करना

कपड़ों की दुकान वाले Space में सदस्य लॉगिन चालू करके देखते हैं।

सदस्य लॉगिन सेटिंग एक Space में एक ही होती है। इसे कई बार नया नहीं बनाया जाता, बल्कि इसी एक को चालू रखकर ज़रूरत पड़ने पर सुधारते हुए इस्तेमाल किया जाता है।

ServiceLogin शुरुआत में बंद रहती है। सेटिंग स्क्रीन खोलने पर "ServiceLogin अक्षम है" वाली सूचना के साथ सक्रिय करें बटन दिखता है। सूचना में लिखा होता है कि "अपनी साइट पर सोशल लॉगिन (Google आदि) सक्षम करने के लिए ServiceLogin सक्रिय करें। OAuth और सेशन Weegloo आपके लिए संभालता है।"।

बाईं ओर के मेनू में Services को फैलाकर ServiceLogin पर क्लिक करें।
मूल जानकारी स्क्रीन में सक्रिय करें बटन पर क्लिक करें।

ServiceLogin अभी चालू नहीं हुई है, ऐसी स्थिति। "ServiceLogin अक्षम है" वाली सूचना और सक्रिय करें बटन दिखता है

सक्रिय करें पर क्लिक करने पर सेटिंग फ़ॉर्म खुलता है। इस फ़ॉर्म में कम से कम एक सोशल लॉगिन चालू करके सहेजें करना होता है, तभी सदस्य लॉगिन असल में काम करता है।

सेटिंग फ़ॉर्म भरना

सेटिंग फ़ॉर्म मूल जानकारी और सोशल लॉगिन सेटिंग में बँटा होता है। पहले मूल जानकारी भरते हैं।

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

सेवा का नाम में ग्राहक को दिखने वाला नाम दर्ज करें। कपड़ों की दुकान हो तो कोज़ी क्लोज़ेट जैसा दुकान का नाम लिखें।
संपर्क ईमेल में पूछताछ प्राप्त करने वाला पता दर्ज करें। उदाहरण: help@cozy-closet.com।
लॉगिन के बाद का URL में लॉगिन के बाद ग्राहक के वापस लौटने वाली आपकी साइट का पता दर्ज करें। उदाहरण: https://cozy-closet.com/auth/callback। इस खाने में https://... जैसा वेब पता डाला जाता है। मोबाइल ऐप (Android और iOS) में लॉगिन जोड़ने की स्थिति में ऐप का पता यहाँ वैसे का वैसा नहीं डाला जा सकता, इसलिए जुड़ने का तरीका थोड़ा अलग होता है। उस समय ज़रूरी तकनीकी चरण Auth API में बताए गए हैं।
डिफ़ॉल्ट Role में नए सदस्य को देने वाला अधिकार चुनें। अगर अभी तक कोई अधिकार नहीं बनाया है, तो बगल के Role प्रबंधित करें में पहले बनाकर वापस आएं।

डिफ़ॉल्ट Role में क्या चुनना है, सदस्य को कौन से अधिकार देने हैं, यह सदस्य भूमिका और अधिकार में बताया गया है।

साइन अप स्वीकार करने से पहले अगर संचालन टीम एक बार जाँचना चाहती है, तो नए साइन-अप के लिए admin की मंज़ूरी ज़रूरी करें को चालू रखा जा सकता है। इस विकल्प को चालू करने पर नया साइन अप किया ग्राहक तुरंत लॉगिन नहीं कर पाता, बल्कि संचालन टीम के मंज़ूरी देने तक प्रतीक्षा करता है। पहले से साइन अप किए सदस्यों पर इसका कोई असर नहीं होता।

साइन अप करते ही कोई भी लॉगिन कर सके, इसके लिए नए साइन-अप के लिए admin की मंज़ूरी ज़रूरी करें को बंद रखें। हर साइन अप को एक-एक करके जाँचना चाहते हैं तो चालू रखें।

सक्रिय करने के बाद खुलने वाला ServiceLogin सेटिंग फ़ॉर्म। सेवा का नाम, संपर्क ईमेल, लॉगिन के बाद का URL, डिफ़ॉल्ट Role और सोशल लॉगिन की सूची दिखती है

ग्राहक किस खाते से साइन अप करेगा, यह Login Providers में तय होता है। Google, GitHub, Facebook, GitLab, LINE, Kakao, Naver में से हर एक को चालू किया जा सकता है।

सोशल लॉगिन दो जगहों को जोड़ने का काम है। उस प्रदाता के पास (उदाहरण के लिए Google हो तो Google Cloud Console) आपकी साइट को दर्ज करें, और वहाँ से मिले मान WEEGLOO में दर्ज करें। Google चालू करने पर स्क्रीन इन्हीं दो चरणों को सिलसिलेवार बताती है।

Google चालू करें। दो चरणों का मार्गदर्शन दिखाई देता है।
Step 1 में दिख रहे Authorized redirect URI को कॉपी करके, Google Cloud Console के OAuth क्लाइंट में दर्ज करें। यह पता Google को बताता है कि लॉगिन का परिणाम कहाँ वापस भेजना है।
Google Cloud Console से प्राप्त मान को Step 2 के Client ID और Client Secret खानों में दर्ज करें।
अन्य सोशल लॉगिन भी इस्तेमाल करने हों तो GitHub या Facebook को भी उसी तरह चालू करके मान दर्ज करें, उसके बाद सहेजें पर क्लिक करें।

Google चालू करने पर आने वाला क्रेडेंशियल मार्गदर्शन। Step 1 का Authorized redirect URI और Step 2 के Client ID, Client Secret दर्ज करने के खाने दिखते हैं

चालू किया हुआ सोशल लॉगिन सूची में चालू स्थिति में दिखे और सहेजें भी पूरा हो जाए, तब ग्राहक उस खाते से लॉगिन कर सकता है।

हर provider में जो अलग है: स्कोप और ईमेल

जोड़ने की प्रक्रिया हर provider के लिए ऊपर जैसी ही है। रीडायरेक्ट पता दर्ज करने वाले खाने का नाम हर provider में थोड़ा-थोड़ा अलग होता है (Authorized redirect URI, Callback URL, Redirect URI आदि)। नाम अलग होने पर भी, मान के रूप में provider को चालू करने पर आने वाले निर्देश के Step 1 में दिख रहे पते को वैसे का वैसा चिपका देना ही काफ़ी है।

नीचे की तालिका के स्कोप (लॉगिन करते समय ग्राहक से माँगी जाने वाली जानकारी का दायरा) वे मान हैं जिन्हें WEEGLOO लॉगिन के समय provider से माँगता है। Google और GitHub के लिए कंसोल में पहले से कुछ तय करने की ज़रूरत नहीं है; ग्राहक लॉगिन करते समय सहमति दे दे, इतना काफ़ी है। बाकी provider के मामले में कुछ चीज़ें कंसोल में पहले से चालू रखनी होती हैं, इसलिए तालिका में देख लें।

WEEGLOO ग्राहक के लॉगिन करते समय provider से ईमेल भी साथ में लेकर सदस्य में दर्ज कर लेता है। एक ही Space में एक ईमेल से सिर्फ़ एक बार ही साइन अप किया जा सकता है। तालिका में लिखी तैयारी उसी ईमेल को पाने के लिए है, इसलिए उसे छोड़ें नहीं। दोनों मान पाने की प्रक्रिया हर provider में अलग होती है, इसलिए तालिका के दाएँ छोर पर दी गई जोड़ने की गाइड में उसे स्क्रीन के साथ बताया गया है।

provider	WEEGLOO जो स्कोप माँगता है	provider कंसोल में पहले से क्या चालू रखें	जोड़ने की गाइड
Google	`email`, `profile`	कुछ नहीं	जोड़ें
GitHub	`read:user`, `user:email`	कुछ नहीं	जोड़ें
Facebook	`email`, `public_profile`	ऐप के Permissions and features में `email` जोड़ना होता है	जोड़ें
GitLab	`read_user`	ऐप बनाते समय स्कोप में `read_user` को चेक करना होता है	जोड़ें
Kakao	`profile_nickname`, `profile_image`, `account_email`	Biz ऐप में बदलने के बाद ईमेल सहमति आइटम के उपयोग की मंज़ूरी ज़रूरी होती है	जोड़ें
Naver	`email`, `profile`, `nickname`	ऐप दर्ज करते समय दी जाने वाली जानकारी में ईमेल पता शामिल करना होता है	जोड़ें
LINE	`profile`, `email`	चैनल में ईमेल अनुमति के लिए आवेदन करके मंज़ूरी लेनी होती है	जोड़ें

साइन अप किए सदस्य देखना

ग्राहक के साइन अप करने पर उस सदस्य को Services > ServiceLogin > Users में देखा जा सकता है। यहाँ साइन अप किए सदस्यों की सूची देखी और प्रबंधित की जाती है।

अगर पहले आपने नए साइन-अप के लिए admin की मंज़ूरी ज़रूरी करें को चालू रखा था, तो नया साइन अप किया सदस्य इस स्क्रीन पर मंज़ूरी की प्रतीक्षा करता है। सदस्य को सक्रिय कर देने पर वह तभी से लॉगिन कर सकता है।

इसी स्क्रीन पर किसी सदस्य का लॉगिन रोका जा सकता है, किसी एक सदस्य को अलग अनुमति दी जा सकती है, या सदस्य को सूची से हटाया जा सकता है। इनके तरीक़े सेवा सदस्यों का प्रबंधन में बताए गए हैं।

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

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

एक Space का सदस्य लॉगिन उसी Space से चलने वाली साइट पर इस्तेमाल होता है। एक ही सदस्य लॉगिन को कई साइटों से जोड़कर एक बार में सबमें पास कराने वाला तरीका यह नहीं है। अगर आप चाहते हैं कि सदस्य एक ही बार लॉगिन करके जिन स्क्रीनों को साथ इस्तेमाल करें, तो उन स्क्रीनों को एक ही साइट में इकट्ठा करें।

आगे क्या करना है

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