सेवा सदस्य लॉगिन
अंतिम अपडेट: 3 जुलाई 2026
मान लीजिए आप एक कपड़ों की दुकान का ऑनलाइन शॉपिंग साइट चलाते हैं। कई बार आप चाहते हैं कि ग्राहक खुद सदस्य के रूप में साइन अप करें, और केवल सदस्य ही समीक्षाएं लिख सकें या श्रेणी के अनुसार लाभ पा सकें। इसके लिए आपको एक ऐसी "सदस्यता प्रणाली" चाहिए जिसमें ग्राहक खुद साइन अप करके लॉगिन करें। इस सदस्यता प्रणाली को आपकी साइट से जोड़ने वाली Space सुविधा है ServiceLogin (आपकी सेवा में ग्राहक खुद साइन अप करके इस्तेमाल करते हैं, वह लॉगिन सेटिंग)।
ServiceLogin को चालू करने पर ग्राहक Google जैसे सोशल खाते से कोई भी सीधे साइन अप कर सकता है। साइन अप करने वाला हर एक ग्राहक एक ServiceUser (आपकी सेवा में साइन अप किया हुआ सदस्य) बन जाता है। लॉगिन की प्रक्रिया और लॉगिन की स्थिति बनाए रखने का काम WEEGLOO आपकी ओर से संभालता है, इसलिए आपको पासवर्ड खुद संग्रहीत करने या सोशल लॉगिन को शुरू से बनाने की ज़रूरत नहीं होती।
इस पेज पर पहले हम देखेंगे कि ServiceLogin क्या है और यह संचालन टीम के खातों से कैसे अलग है, उसके बाद कपड़ों की दुकान वाले Space में ServiceLogin को खुद चालू करके सेट करेंगे।
सदस्य संचालन टीम से अलग होते हैं
WEEGLOO में लॉगिन करने वाले दो तरह के लोग होते हैं। यह आसानी से उलझा सकता है, इसलिए पहले सीमा खींच लेते हैं।
- संचालन टीम/टीम वे लोग हैं जो उत्पाद दर्ज करते हैं और साइट का प्रबंधन करते हैं। वे ग्राहकों की तरह ServiceLogin से साइन अप नहीं करते, बल्कि WEEGLOO खाते से इस Space के सदस्य बनकर आते हैं (पहले से अंदर मौजूद किसी व्यक्ति के आमंत्रण और भूमिका सौंपने से)। संचालन टीम के अधिकार भूमिका और अधिकार में बताए गए हैं।
- ServiceUser वह ग्राहक/सदस्य है जो उस साइट का उपयोग करता है। यह वह व्यक्ति है जिसने आपकी चलाई हुई कपड़ों की दुकान वाली साइट पर सोशल खाते से सीधे साइन अप किया है। यह संचालन टीम से बिल्कुल अलग लॉगिन है।
संक्षेप में, संचालन टीम "दुकान चलाने वाले लोग" हैं, और ServiceUser "दुकान पर आए हुए ग्राहक" हैं। ServiceLogin इन ग्राहकों के आने-जाने के लिए एक दरवाज़ा बनाने का काम है।
साथ चलने वाली तीन चीज़ें
सदस्यता प्रणाली में तीन चीज़ें एक-दूसरे से जुड़कर चलती हैं।
- ServiceLogin: यह लॉगिन सेटिंग ही है। कौन सा सोशल लॉगिन इस्तेमाल करना है, साइन अप किए सदस्य को डिफ़ॉल्ट रूप से कौन से अधिकार देने हैं, जैसी बातें यहीं तय होती हैं।
- ServiceUserRole: सदस्य को दिए जाने वाले अधिकारों का समूह है। यह तय करता है कि सदस्य क्या देख सकता है और क्या लिख सकता है।
- ServiceUser: साइन अप किया हुआ हर एक सदस्य है। हर बार जब कोई ग्राहक साइन अप करता है, एक नया बनता है।
यह पेज दरवाज़ा खोलने वाली ServiceLogin सेटिंग पर केंद्रित है। सदस्य असल में क्या देख और इस्तेमाल कर सकता है (अधिकार), यह तय करने वाली ServiceUserRole सदस्य भूमिका और अधिकार में अलग से बताई गई है। नीचे की सेटिंग में चुनी जाने वाली Default Role ही उस पेज पर बनाई जाने वाली भूमिका है।
ServiceLogin चालू करना
कपड़ों की दुकान वाले Space में सदस्य लॉगिन चालू करके देखते हैं।
सदस्य लॉगिन सेटिंग एक Space में एक ही होती है। इसे कई बार नया नहीं बनाया जाता, बल्कि इसी एक को चालू रखकर ज़रूरत पड़ने पर सुधारते हुए इस्तेमाल किया जाता है।
ServiceLogin शुरुआत में बंद रहती है। सेटिंग स्क्रीन खोलने पर "ServiceLogin is disabled" वाली सूचना के साथ Activate बटन दिखता है। सूचना में लिखा होता है कि "Activate ServiceLogin to enable social login (Google, etc.) on your site. Weegloo handles OAuth and sessions for you."।
- बाईं ओर के मेनू में Services को फैलाकर ServiceLogin पर क्लिक करें।
- मूल जानकारी स्क्रीन में Activate बटन पर क्लिक करें।
Activate पर क्लिक करने पर सेटिंग फ़ॉर्म खुलता है। इस फ़ॉर्म में कम से कम एक सोशल लॉगिन चालू करके सहेजें करना होता है, तभी सदस्य लॉगिन असल में काम करता है।
सेटिंग फ़ॉर्म भरना
सेटिंग फ़ॉर्म मूल जानकारी और सोशल लॉगिन सेटिंग में बँटा होता है। पहले मूल जानकारी भरते हैं।
| आइटम | क्या लिखना है |
|---|---|
| Service name | लॉगिन करते समय ग्राहक को दिखने वाला सेवा का नाम है। कपड़ों की दुकान हो तो दुकान का नाम लिखें। |
| Contact email | लॉगिन में समस्या आने पर (उदाहरण के लिए जब साइन अप की सीमा भर जाए) ग्राहक को दिखाने वाला संपर्क है। |
| Callback URI | ग्राहक के लॉगिन पूरा करने के बाद वापस लौटने वाली आपकी साइट का पता है। |
| Default Role | नए साइन अप किए ग्राहक को अपने आप मिलने वाला अधिकारों का समूह है। बगल में दिए Manage Roles पर क्लिक करने से अधिकार बनाने वाली स्क्रीन पर पहुँच जाते हैं। |
- Service name में ग्राहक को दिखने वाला नाम दर्ज करें। कपड़ों की दुकान हो तो
कोज़ी क्लोज़ेटजैसा दुकान का नाम लिखें। - Contact email में पूछताछ प्राप्त करने वाला पता दर्ज करें। उदाहरण:
help@cozy-closet.com. - Callback URI में लॉगिन के बाद ग्राहक के वापस लौटने वाली आपकी साइट का पता दर्ज करें। उदाहरण:
https://cozy-closet.com/auth/callback. - Default Role में नए सदस्य को देने वाला अधिकार चुनें। अगर अभी तक कोई अधिकार नहीं बनाया है, तो बगल के Manage Roles में पहले बनाकर वापस आएं।
Default Role में क्या चुनना है, सदस्य को कौन से अधिकार देने हैं, यह सदस्य भूमिका और अधिकार में बताया गया है।
साइन अप स्वीकार करने से पहले अगर संचालन टीम एक बार जाँचना चाहती है, तो नए साइन-अप के लिए admin की मंजूरी ज़रूरी है को चालू रखा जा सकता है। इस विकल्प को चालू करने पर नया साइन अप किया ग्राहक तुरंत लॉगिन नहीं कर पाता, बल्कि संचालन टीम के मंज़ूरी देने तक प्रतीक्षा करता है। पहले से साइन अप किए सदस्यों पर इसका कोई असर नहीं होता।
- साइन अप करते ही कोई भी लॉगिन कर सके, इसके लिए नए साइन-अप के लिए admin की मंजूरी ज़रूरी है को बंद रखें। हर साइन अप को एक-एक करके जाँचना चाहते हैं तो चालू रखें।
सोशल लॉगिन चालू करना
ग्राहक किस खाते से साइन अप करेगा, यह 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 को भी उसी तरह चालू करके मान दर्ज करें, उसके बाद सहेजें पर क्लिक करें।
चालू किया हुआ सोशल लॉगिन सूची में चालू स्थिति में दिखे और सहेजें भी पूरा हो जाए, तब ग्राहक उस खाते से लॉगिन कर सकता है।
हर provider में जो अलग है: स्कोप और ईमेल
जोड़ने की प्रक्रिया हर provider के लिए ऊपर जैसी ही है। रीडायरेक्ट पता दर्ज करने वाले खाने का नाम हर provider में थोड़ा-थोड़ा अलग होता है (Authorized redirect URI, Callback URL, Redirect URI आदि)। नाम अलग होने पर भी, मान के रूप में provider को चालू करने पर आने वाले निर्देश के Step 1 में दिख रहे पते को वैसे का वैसा चिपका देना ही काफ़ी है।
नीचे की तालिका के स्कोप (लॉगिन करते समय ग्राहक से माँगी जाने वाली जानकारी का दायरा) वे मान हैं जिन्हें WEEGLOO लॉगिन के समय provider से माँगता है। Google, GitHub और Facebook के लिए कंसोल में पहले से कुछ तय करने की ज़रूरत नहीं है; ग्राहक लॉगिन करते समय सहमति दे दे, इतना काफ़ी है। बाकी provider के मामले में कुछ चीज़ें कंसोल में पहले से चालू रखनी होती हैं, इसलिए तालिका में देख लें।
WEEGLOO साइन अप किए सदस्यों की पहचान ईमेल से करता है। इसलिए अगर provider ईमेल नहीं देता, तो उस खाते से लॉगिन नहीं हो पाता। OAuth ऐप बनाने की विस्तृत प्रक्रिया के लिए हर provider के आधिकारिक दस्तावेज़ का पालन करें।
| provider | WEEGLOO जो स्कोप माँगता है | provider कंसोल में पहले से क्या चालू रखें | आधिकारिक दस्तावेज़ |
|---|---|---|---|
email, profile | कुछ नहीं | Google दस्तावेज़ | |
| GitHub | read:user, user:email | कुछ नहीं | GitHub दस्तावेज़ |
email, public_profile | कुछ नहीं | Facebook दस्तावेज़ | |
| GitLab | read_user | ऐप बनाते समय स्कोप में read_user को चेक करना होता है | GitLab दस्तावेज़ |
| Kakao | profile_nickname, profile_image, account_email | Biz ऐप में बदलने के बाद ईमेल सहमति आइटम के उपयोग की मंज़ूरी ज़रूरी होती है | Kakao दस्तावेज़ |
| Naver | email, profile, nickname | ऐप दर्ज करते समय दी जाने वाली जानकारी में ईमेल पता शामिल करना होता है | Naver दस्तावेज़ |
| LINE | profile, email | चैनल में ईमेल अनुमति के लिए आवेदन करके मंज़ूरी लेनी होती है | LINE दस्तावेज़ |
साइन अप किए सदस्य देखना
ग्राहक के साइन अप करने पर उस सदस्य को Services > ServiceLogin > Users में देखा जा सकता है। यहाँ साइन अप किए सदस्यों की सूची देखी और प्रबंधित की जाती है।
अगर पहले आपने नए साइन-अप के लिए admin की मंजूरी ज़रूरी है को चालू रखा था, तो नया साइन अप किया सदस्य इस स्क्रीन पर मंज़ूरी की प्रतीक्षा करता है। सदस्य को सक्रिय कर देने पर वह तभी से लॉगिन कर सकता है।
जब आपकी कई साइटें हों, तब सदस्य लॉगिन
एक ही व्यक्ति कई अलग-अलग सेवाएं भी चलाता है। मान लीजिए आप कपड़ों की दुकान कोज़ी क्लोज़ेट चलाते हुए, बिल्कुल अलग क्षेत्र की एक मोहल्ले की बेकरी की साइट भी साथ में चलाते हैं। दोनों साइटों पर आने वाले ग्राहक भी अलग हैं, और जो चीज़ें वे दिखाती हैं वे भी अलग हैं। कपड़ों की दुकान पर साइन अप किए ग्राहक के बेकरी का सदस्य होने की कोई वजह नहीं है।
सदस्य लॉगिन एक Space में एक ही रखा जाता है। इसलिए इस तरह अलग-अलग साइटें अपने-अपने Space बनाती हैं, और उस Space में सदस्य लॉगिन अलग से सेट करती हैं। सदस्यों की सूची भी हर Space के हिसाब से बँट जाती है, और कपड़ों की दुकान के सदस्य तथा बेकरी के सदस्य अलग-अलग सदस्यों के रूप में प्रबंधित होते हैं।
एक Space का सदस्य लॉगिन उसी Space से चलने वाली साइट पर इस्तेमाल होता है। एक ही सदस्य लॉगिन को कई साइटों से जोड़कर एक बार में सबमें पास कराने वाला तरीका यह नहीं है। अगर आप चाहते हैं कि सदस्य एक ही बार लॉगिन करके जिन स्क्रीनों को साथ इस्तेमाल करें, तो उन स्क्रीनों को एक ही साइट में इकट्ठा करें।
आगे क्या करना है
- सदस्य भूमिका और अधिकार: साइन अप किया सदस्य क्या देख और इस्तेमाल कर सकता है, यह तय करने वाली ServiceUserRole बनाएं, और ऊपर चुनी Default Role से जोड़ें।
- API रेफ़रेंस: साइन अप किए सदस्य के लॉगिन को आपकी साइट के कोड से जोड़ने के लिए आधिकारिक क्लाइंट SDK और अनुरोध प्रारूप जैसी तकनीकी विशिष्टियाँ चाहिए होती हैं। सदस्य जो कंटेंट देखता और इस्तेमाल करता है, उसे प्रोग्राम से सीधे संभालने की विशिष्टियाँ भी यहीं बताई गई हैं।