मुख्य सामग्री पर जाएं

WeChat WiFi प्रमाणीकरण को एकीकृत करना: APAC ग्राहकों के लिए कैप्टिव पोर्टल ऑनबोर्डिंग

WeChat के पास 1.41 बिलियन मासिक सक्रिय उपयोगकर्ता हैं, जो इसे वैश्विक स्तर पर चीनी उपभोक्ताओं के लिए प्राथमिक डिजिटल पहचान बनाता है। यह मार्गदर्शिका बताती है कि APAC स्थानों के लिए एंटरप्राइज कैप्टिव पोर्टल्स में WeChat OAuth 2.0 प्रमाणीकरण को कैसे एकीकृत किया जाए, जिसमें प्लेटफ़ॉर्म पंजीकरण, स्कोप चयन, RADIUS Change of Authorisation प्रवर्तन, और GDPR तथा चीन के PIPL के साथ दोहरे-ढांचे का अनुपालन शामिल है। इसका उद्देश्य IT प्रबंधकों, नेटवर्क आर्किटेक्ट्स और वेन्यू ऑपरेशंस निदेशकों के लिए है जिन्हें इस तिमाही में कार्रवाई करने की आवश्यकता है।

📖 9 मिनट का पाठ📝 2,130 शब्द🔧 2 हल किए गए उदाहरण4 अभ्यास प्रश्न📚 10 मुख्य परिभाषाएं

इस गाइड को सुनें

पॉडकास्ट ट्रांसक्रिप्ट देखें
कैप्टिव पोर्टल्स के लिए WECHAT OAUTH प्रमाणीकरण को कैसे कॉन्फ़िगर करें एक Purple तकनीकी ब्रीफिंग - लगभग 10 मिनट परिचय और संदर्भ (लगभग 1 मिनट) स्वागत है। यदि आप किसी होटल, खुदरा श्रृंखला, स्टेडियम या सम्मेलन केंद्र में गेस्ट WiFi के लिए जिम्मेदार हैं जो चीनी आगंतुकों की सेवा करता है, तो यह ब्रीफिंग आपके लिए है। Tencent के अपने डेटा के अनुसार, 2025 तक WeChat के पास 1.41 बिलियन मासिक सक्रिय उपयोगकर्ता हैं। भारी बहुमत चीन में है, लेकिन इस प्लेटफ़ॉर्म का एक महत्वपूर्ण अंतर्राष्ट्रीय पदचिह्न भी है। मलेशिया में 12 मिलियन WeChat उपयोगकर्ता हैं। जापान में 5.5 मिलियन हैं। दक्षिण कोरिया में 5 मिलियन हैं। और दक्षिण पूर्व एशिया, मध्य पूर्व और यूरोप में संख्या बढ़ रही है। जब कोई चीनी अतिथि आपके WiFi से जुड़ता है और केवल ईमेल, Facebook या वाउचर कोड वाला लॉगिन पेज देखता है, तो उन्हें तुरंत परेशानी का सामना करना पड़ता है। हो सकता है कि उनके पास उस डिवाइस पर कोई स्थानीय ईमेल पता सेट न हो। उनके पास लगभग निश्चित रूप से WeChat है। इसलिए सवाल यह नहीं है कि क्या आपको WeChat लॉगिन की पेशकश करनी चाहिए। यह है कि आप इसे सही ढंग से, सुरक्षित रूप से और इस तरह से कैसे कॉन्फ़िगर करते हैं जो फर्स्ट-पार्टी डेटा उत्पन्न करता है जिसका आप वास्तव में उपयोग कर सकते हैं। आज हम इसी को कवर करने जा रहे हैं। हम OAuth 2.0 फ़्लो, आपके लिए आवश्यक दो प्लेटफ़ॉर्म पंजीकरणों, स्कोप निर्णय जो यह निर्धारित करता है कि आप कौन सा डेटा एकत्र करते हैं, नेटवर्क-साइड प्रवर्तन तंत्र, और 2026 में महत्वपूर्ण अनुपालन विचारों के माध्यम से चलेंगे। तकनीकी गहन विश्लेषण (लगभग 5 मिनट) आइए आर्किटेक्चर से शुरू करें। एक कैप्टिव पोर्टल एक अप्रमाणित डिवाइस से HTTP ट्रैफ़िक को रोकता है और इसे लॉगिन पेज पर रीडायरेक्ट करता है। वह लॉगिन पेज पोर्टल सर्वर पर होस्ट किया जाता है, चाहे वह ऑन-प्रिमाइसेस हो या क्लाउड में। जब आप WeChat OAuth जोड़ते हैं, तो आप उस फ़्लो में एक तीसरे पक्ष के पहचान प्रदाता को शामिल कर रहे होते हैं। यहाँ अनुक्रम है। अतिथि आपके SSID से जुड़ता है। एक्सेस पॉइंट या वायरलेस कंट्रोलर यह पता लगाता है कि डिवाइस का कोई प्रमाणित सत्र नहीं है और सभी HTTP ट्रैफ़िक को आपके कैप्टिव पोर्टल URL पर रीडायरेक्ट करता है। पोर्टल पेज लोड होता है और WeChat सहित लॉगिन विकल्प प्रस्तुत करता है। अतिथि WeChat लॉगिन पर टैप करता है। आपका पोर्टल सर्वर ब्राउज़र को WeChat के प्राधिकरण एंडपॉइंट पर रीडायरेक्ट करता, जिसमें आपका AppID, रीडायरेक्ट URI, `code` का रिस्पॉन्स टाइप और स्कोप पास किया जाता है। WeChat पूरी तरह से अपने सर्वर पर प्रमाणीकरण को संभालता है। यदि अतिथि पहले से ही अपने ब्राउज़र में WeChat में लॉग इन है, तो वे एक सहमति स्क्रीन देखते हैं। यदि वे WeChat इन-ऐप ब्राउज़र का उपयोग कर रहे हैं, तो snsapi_base स्कोप के साथ अनुभव मूक हो सकता है, जिसका अर्थ है कि कोई सहमति संकेत नहीं होगा। WeChat फिर एक अस्थायी प्राधिकरण कोड के साथ आपके पोर्टल के रीडायरेक्ट URI पर वापस रीडायरेक्ट करता है। आपका पोर्टल सर्वर WeChat API को कॉल करके उस कोड को एक्सेस टोकन के लिए एक्सचेंज करता है। WeChat एक एक्सेस टोकन, एक रिफ्रेश टोकन, उपयोगकर्ता का OpenID और स्वीकृत स्कोप लौटाता है। यदि आपने snsapi_userinfo स्कोप का अनुरोध किया है, तो आप उपयोगकर्ता का उपनाम, अवतार, लिंग और शहर प्राप्त करने के लिए दूसरा API कॉल कर सकते हैं। अब, दो प्लेटफ़ॉर्म पंजीकरण। यहीं पर अधिकांश कार्यान्वयन गलत हो जाते हैं। WeChat के दो अलग-अलग डेवलपर प्लेटफ़ॉर्म हैं। WeChat Open Platform वेबसाइट अनुप्रयोगों और मोबाइल ऐप्स को संभालता है। WeChat Official Accounts Platform सार्वजनिक खातों को संभालता है, जिसकी वास्तव में अधिकांश स्थानों को आवश्यकता होती है। WeChat इन-ऐप ब्राउज़र के भीतर मेहमानों की सेवा करने वाले कैप्टिव पोर्टल के लिए, आपको Official Accounts Platform पर एक Service Account की आवश्यकता होगी। एक Subscription Account काम नहीं करेगा। इसमें OAuth वेब पेज प्राधिकरण अनुमतियां नहीं होती हैं। एक Service Account में होती हैं, और यह snsapi_base और snsapi_userinfo दोनों स्कोप का समर्थन करता है। WeChat के बाहर एक मानक मोबाइल ब्राउज़र से एक्सेस किए जाने वाले कैप्टिव पोर्टल के लिए, जैसे कि Android पर Chrome या iOS पर Safari, आपको Open Platform पर पंजीकृत एक Website Application की आवश्यकता होगी। यह snsapi_login स्कोप का उपयोग करता है और एक QR कोड प्रस्तुत करता है जिसे उपयोगकर्ता अपने WeChat ऐप से स्कैन करता है। व्यवहार में, अधिकांश स्थान परिनियोजन दोनों का उपयोग करते हैं। होटल का एक अतिथि Chrome में पोर्टल खोल सकता है, एक QR कोड देख सकता है, इसे WeChat से स्कैन कर सकता है, और प्रमाणित कर सकता है। या वे स्वयं WeChat में एक लिंक का अनुसरण कर सकते हैं, इन-ऐप ब्राउज़र में पहुंच सकते हैं, और snsapi_base के साथ चुपचाप प्रमाणित कर सकते हैं। आइए स्कोप चयन के बारे में बात करते हैं, क्योंकि यह एक वास्तविक निर्णय बिंदु है। snsapi_base स्कोप केवल OpenID लौटाता है। यह आपके Official Account के भीतर उस उपयोगकर्ता के लिए एक अद्वितीय पहचानकर्ता है। इसके लिए किसी उपयोगकर्ता सहमति संकेत की आवश्यकता नहीं होती है। प्रमाणीकरण उपयोगकर्ता के लिए अदृश्य होता है। यह उन लौटने वाले मेहमानों के लिए आदर्श है जिनकी प्रोफ़ाइल आपने पहले से बनाई हुई है, या उन स्थानों के लिए जहाँ आप शून्य नए डेटा की कीमत पर शून्य घर्षण चाहते हैं। snsapi_userinfo स्कोप OpenID के साथ उपयोगकर्ता का WeChat उपनाम, प्रोफ़ाइल चित्र, लिंग, भाषा सेटिंग और शहर लौटाता है। इसके लिए एक स्पष्ट सहमति स्क्रीन की आवश्यकता होती है। उपयोगकर्ता को एक संकेत दिखाई देता है जिसमें पूछा जाता है कि क्या वे आपके Official Account को अपनी जानकारी तक पहुँचने की अनुमति देते हैं। अधिकांश उपयोगकर्ता स्वीकार करते हैं, लेकिन घर्षण होता है। सही चुनाव आपके उपयोग के मामले पर निर्भर करता है। पहली बार आने वाले अतिथि पंजीकरण के लिए जहाँ आप एक प्रोफ़ाइल बनाना चाहते हैं, snsapi_userinfo का उपयोग करें और इसे अपने पोर्टल पेज पर GDPR-अनुपालन सहमति परत के साथ जोड़ें। लौटने वाले अतिथि के लिए जिसने पहले ही सहमति दे दी है और जिसकी प्रोफ़ाइल आपके पास पहले से है, मूक पुन: प्रमाणीकरण के लिए snsapi_base का उपयोग करें। अब, नेटवर्क प्रवर्तन पक्ष। OAuth टोकन प्राप्त करना पहचान साबित करता है, लेकिन यह स्वचालित रूप से नेटवर्क नहीं खोलता है। आपको सफल प्रमाणीकरण को नेटवर्क एक्सेस में बदलने के लिए एक तंत्र की आवश्यकता है। दो मानक दृष्टिकोण RADIUS Change of Authorisation हैं, जिन्हें RFC 3576 में परिभाषित किया गया है, और MAC address bypass। RADIUS CoA के साथ, आपका पोर्टल सर्वर सफल OAuth के बाद नेटवर्क कंट्रोलर को एक CoA अनुरोध भेजता, और कंट्रोलर डिवाइस को अप्रमाणित VLAN से गेस्ट VLAN में ले जाता है। यह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, और Fortinet के साथ काम करता है। MAC बाईपास के साथ, पोर्टल सर्वर डिवाइस के MAC पते को एक अधिकृत क्लाइंट के रूप में पंजीकृत करता है, और कंट्रोलर इसकी अनुमति देता है। MAC बाईपास को लागू करना सरल है लेकिन कम सुरक्षित है, क्योंकि MAC पतों को स्पूफ़ किया जा सकता है, और आधुनिक स्मार्टफोन तेजी से MAC एड्रेस रैंडमाइजेशन का उपयोग करते हैं, जो पुन: कनेक्शन पर तंत्र को बाधित करता है। Purple का Guest WiFi प्लेटफ़ॉर्म दोनों तंत्रों को संभालता है। WeChat OAuth पूरा होने के बाद, Purple का क्लाउड ओवरले अंतर्निहित हार्डवेयर को उपयुक्त सिग्नल भेजता है। स्थान ऑपरेटर को उस अनुवाद को मैन्युअल रूप से प्रबंधित करने की आवश्यकता नहीं होती है। कार्यान्वयन सिफारिशें और नुकसान (लगभग 2 मिनट) मुझे आपको वे पांच चीजें बताने दें जो WeChat OAuth कैप्टिव पोर्टल कार्यान्वयन को विफल करने का कारण बनती हैं। पहला: रीडायरेक्ट URI बेमेल। WeChat उस अधिकृत डोमेन के विरुद्ध रीडायरेक्ट URI को सत्यापित करता है जिसे आपने प्लेटफ़ॉर्म पर पंजीकृत किया है। यदि आपका पोर्टल सर्वर एक अलग सबडोमेन, एक अलग पथ, या HTTPS के बजाय HTTP का उपयोग करता है, तो OAuth फ़्लो त्रुटि 40029 के साथ विफल हो जाता है, जिसका अर्थ है अमान्य कोड। स्टेजिंग वातावरण सहित आपके द्वारा उपयोग किए जाने वाले प्रत्येक डोमेन संस्करण को पंजीकृत करें। दूसरा: क्लाइंट साइड पर AppSecret। आपका AppSecret कभी भी क्लाइंट-साइड JavaScript या मोबाइल ऐप बाइनरी में दिखाई नहीं देना चाहिए। यह आपके सर्वर पर होना चाहिए। यदि यह उजागर हो जाता है, तो कोई भी आपके एप्लिकेशन का प्रतिरूपण कर सकता है और आपकी ओर से WeChat के API को कॉल कर सकता है। तीसरा: गायब CSRF सुरक्षा। OAuth अनुरोध में state पैरामीटर विशेष रूप से क्रॉस-साइट अनुरोध जालसाजी को रोकने के लिए मौजूद है। एक क्रिप्टोग्राफ़िक रूप से रैंडम state मान उत्पन्न करें, इसे उपयोगकर्ता के सत्र में संग्रहीत करें, और WeChat के वापस रीडायरेक्ट करने पर इसे सत्यापित करें। इसे छोड़ दें और आपके पास एक वास्तविक भेद्यता होगी। चौथा: इन-ऐप ब्राउज़र डिटेक्शन गैप। WeChat का इन-ऐप ब्राउज़र एक विशिष्ट उपयोगकर्ता एजेंट स्ट्रिंग सेट करता है जिसमें MicroMessenger होता है। यदि आपका पोर्टल इसका पता नहीं लगाता है और सही OAuth फ़्लो प्रदान नहीं करता है, तो उपयोगकर्ताओं को एक बाधित अनुभव या त्रुटि मिलती है। पांचवां: GDPR और PIPL संरेखण। यदि आप यूरोपीय आगंतुकों की सेवा करते हैं, तो GDPR आपके द्वारा WeChat OAuth के माध्यम से एकत्र किए जाने वाले डेटा पर लागू होता है। यदि आप चीनी आगंतुकों की सेवा करते हैं, तो चीन का व्यक्तिगत सूचना संरक्षण कानून, जिसे PIPL के रूप में जाना जाता है, इस बात पर लागू होता है कि आप उनके डेटा को कैसे संसाधित करते हैं। दोनों को प्रसंस्करण के लिए एक कानूनी आधार, स्पष्ट उद्देश्य सीमा और डेटा न्यूनीकरण की आवश्यकता होती है। snsapi_base स्कोप को डेटा न्यूनीकरण सिद्धांतों के तहत snsapi_userinfo की तुलना में उचित ठहराना आसान है। आप जो भी एकत्र करते हैं, अपने कानूनी आधार और अपनी प्रतिधारण अवधि का दस्तावेजीकरण करें। रैपिड-फायर प्रश्न और उत्तर (लगभग 1 मिनट) प्रश्न: क्या मैं ऐसे पोर्टल पर WeChat लॉगिन का उपयोग कर सकता हूँ जो ईमेल और SMS लॉगिन भी प्रदान करता है? हाँ। Purple सहित अधिकांश एंटरप्राइज पोर्टल प्लेटफ़ॉर्म, एक ही पोर्टल पेज पर कई प्रमाणीकरण विधियों का समर्थन करते हैं। WeChat अन्य विकल्पों के साथ एक विकल्प के रूप में दिखाई देता है। प्रश्न: क्या WeChat OAuth iOS पर काम करता है? हाँ, लेकिन एक सूक्ष्म अंतर के साथ। Apple का App Tracking Transparency ढांचा सर्वर-साइड OAuth फ़्लो को प्रभावित नहीं करता है। iOS पर Safari में WeChat लॉगिन QR कोड फ़्लो या रीडायरेक्ट फ़्लो के माध्यम से काम करता है। WeChat ऐप स्वयं प्रमाणीकरण को संभालता है। प्रश्न: क्या होगा यदि WeChat का API अनुपलब्ध है? आपके पोर्टल को एक फ़ॉलबैक लागू करना चाहिए। यदि WeChat API कॉल टाइम आउट हो जाती है या कोई त्रुटि लौटाती है, तो उपयोगकर्ता को एक वैकल्पिक लॉगिन विधि पर रीडायरेक्ट करें। उन्हें खाली स्क्रीन के साथ न छोड़ें। प्रश्न: क्या मैं OpenID का उपयोग एक स्थायी ग्राहक पहचानकर्ता के रूप में कर सकता हूँ? आपके Official Account के भीतर, हाँ। OpenID एक दिए गए उपयोगकर्ता और एक दिए गए Official Account के लिए स्थिर है। यदि आपके पास कई Official Accounts हैं, तो एक ही उपयोगकर्ता के पास अलग-अलग OpenID होंगे। क्रॉस-अकाउंट पहचान समाधान के लिए, WeChat एक UnionID प्रदान करता है, जिसके लिए आपके खातों को Open Platform पर लिंक होना आवश्यक है। सारांश और अगले कदम (लगभग 1 मिनट) संक्षेप में। कैप्टिव पोर्टल्स के लिए WeChat OAuth प्रमाणीकरण एक दो-प्लेटफ़ॉर्म पंजीकरण अभ्यास, एक स्कोप निर्णय, एक नेटवर्क प्रवर्तन एकीकरण, और एक अनुपालन समीक्षा है। उन चार चीजों को सही करें और आपके पास एक लॉगिन विधि होगी जो शून्य पासवर्ड घर्षण के साथ एक अरब से अधिक संभावित आगंतुकों की सेवा करती है। व्यावहारिक अगले कदम ये हैं। पहला, यह निर्धारित करें कि आपके आगंतुक WeChat इन-ऐप ब्राउज़र के भीतर या मानक मोबाइल ब्राउज़र में पोर्टल का सामना करते हैं या नहीं। यह निर्धारित करता है कि आपको किस प्लेटफ़ॉर्म पंजीकरण की आवश्यकता है। दूसरा, स्कोप तय करें। लौटने वाले मेहमानों के लिए snsapi_base का उपयोग करें, और सहमति के साथ पहली बार पंजीकरण के लिए snsapi_userinfo का उपयोग करें। तीसरा, पुष्टि करें कि आपका नेटवर्क हार्डवेयर RADIUS CoA का समर्थन करता है या विकल्प के रूप में MAC बाईपास को कॉन्फ़िगर करें। चौथा, GDPR और PIPL आवश्यकताओं के विरुद्ध अपने गोपनीयता नोटिस और सहमति प्रवाह की समीक्षा करें। पांचवां, लाइव होने से पहले रीडायरेक्ट URI, state पैरामीटर सत्यापन, और इन-ऐप ब्राउज़र डिटेक्शन का परीक्षण करें। यदि आप देखना चाहते हैं कि Purple 2024 में 80,000 स्थानों और 440 मिलियन लॉगिन में एक व्यापक Guest WiFi और एनालिटिक्स प्लेटफ़ॉर्म के हिस्से के रूप में WeChat OAuth को कैसे संभालता है, तो purple.ai पर जाएं या अपनी खाता टीम से बात करें। सुनने के लिए धन्यवाद।

header_image.png

कार्यकारी सारांश

APAC क्षेत्र में काम करने वाले या वैश्विक स्तर पर चीनी पर्यटकों को सेवा देने वाले एंटरप्राइज स्थानों के लिए, WeChat WiFi प्रमाणीकरण अब वैकल्पिक नहीं रह गया है। 2025 तक 1.41 बिलियन मासिक सक्रिय उपयोगकर्ताओं (स्रोत: Tencent) के साथ, WeChat चीनी उपभोक्ताओं के लिए प्राथमिक डिजिटल पहचान है। एक अतिथि जो आपके SSID से जुड़ता है और केवल ईमेल या Facebook लॉगिन विकल्प देखता है, उसे तुरंत परेशानी का सामना करना पड़ता है। उनके पास लगभग निश्चित रूप से WeChat है। उनके पास लगभग निश्चित रूप से उस डिवाइस पर कोई स्थानीय ईमेल पता कॉन्फ़िगर नहीं है।

यह मार्गदर्शिका बताती है कि कैप्टिव पोर्टल में WeChat OAuth 2.0 को कैसे एकीकृत किया जाए। हम Tencent द्वारा आवश्यक दो अलग-अलग प्लेटफ़ॉर्म पंजीकरणों, स्कोप निर्णय जो यह निर्धारित करता है कि आप कौन सा फर्स्ट-पार्टी डेटा एकत्र करते हैं, और RADIUS Change of Authorisation (CoA) तंत्र को कवर करते हैं जो एक सफल OAuth एक्सचेंज को वास्तविक नेटवर्क एक्सेस में बदलता है। हम GDPR और चीन के व्यक्तिगत सूचना संरक्षण कानून (PIPL) की ओवरलैपिंग अनुपालन आवश्यकताओं को भी संबोधित करते हैं।

Purple का Guest WiFi प्लेटफ़ॉर्म Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, और Fortinet हार्डवेयर पर नेटवर्क प्रवर्तन परत को स्वचालित करता है। Purple 80,000+ लाइव स्थानों पर काम करता है और इसने 2024 में 440 मिलियन लॉगिन दर्ज किए (Purple आंतरिक डेटा)।

तकनीकी गहन विश्लेषण

OAuth 2.0 फ़्लो

एक कैप्टिव पोर्टल (एक वेब-आधारित प्रमाणीकरण गेटवे जो अप्रमाणित उपकरणों से HTTP ट्रैफ़िक को रोकता है) मेहमानों को पोर्टल सर्वर पर होस्ट किए गए लॉगिन पेज पर रीडायरेक्ट करता है, चाहे वह ऑन-प्रिमाइसेस हो या क्लाउड में। WeChat OAuth जोड़ने से उस फ़्लो में Tencent का पहचान बुनियादी ढांचा शामिल हो जाता है।

अनुक्रम इस प्रकार चलता है। अतिथि SSID से जुड़ता है। वायरलेस कंट्रोलर प्रमाणित सत्र की अनुपस्थिति का पता लगाता है और सभी HTTP ट्रैफ़िक को कैप्टिव पोर्टल URL पर रीडायरेक्ट करता है। पोर्टल पेज लोड होता है और WeChat सहित लॉगिन विकल्प प्रस्तुत करता है। अतिथि WeChat चुनता है। पोर्टल सर्वर open.weixin.qq.com पर WeChat के प्राधिकरण एंडपॉइंट पर एक रीडायरेक्ट बनाता है, जिसमें चार पैरामीटर पास किए जाते हैं: AppID, रीडायरेक्ट URI, code पर सेट रिस्पॉन्स टाइप, और अनुरोधित स्कोप।

WeChat उपयोगकर्ता को पूरी तरह से अपने बुनियादी ढांचे पर प्रमाणित करता है। यदि अतिथि पहले से ही WeChat इन-ऐप ब्राउज़र के माध्यम से साइन इन है, तो snsapi_base स्कोप बिना किसी दृश्य संकेत के मूक प्रमाणीकरण की अनुमति देता है। WeChat एक अल्पकालिक प्राधिकरण कोड के साथ पोर्टल के पंजीकृत रीडायरेक्ट URI पर वापस रीडायरेक्ट करता है। पोर्टल सर्वर AppID, AppSecret, कोड और ग्रांट टाइप के साथ api.weixin.qq.com/sns/oauth2/access_token को कॉल करके इस कोड को एक्सेस टोकन के लिए एक्सचेंज करता है। WeChat एक एक्सेस टोकन, एक रिफ्रेश टोकन, उपयोगकर्ता का OpenID और स्वीकृत स्कोप लौटाता है। यदि snsapi_userinfo का अनुरोध किया गया था, तो api.weixin.qq.com/sns/userinfo पर एक दूसरा API कॉल उपयोगकर्ता का उपनाम, प्रोफ़ाइल छवि, लिंग और शहर प्राप्त करता है।

architecture_overview.png

प्लेटफ़ॉर्म पंजीकरण: वह निर्णय जो अधिकांश परिनियोजनों को बाधित करता है

Tencent दो अलग-अलग डेवलपर प्लेटफ़ॉर्म संचालित करता है, और गलत प्लेटफ़ॉर्म का चयन करना विफल कार्यान्वयन का सबसे आम कारण है।

एक्सेस संदर्भ आवश्यक पंजीकरण प्लेटफ़ॉर्म URL समर्थित स्कोप
WeChat इन-ऐप ब्राउज़र Service Account (Official Accounts Platform) mp.weixin.qq.com snsapi_base, snsapi_userinfo
मानक मोबाइल ब्राउज़र (Chrome, Safari) Website Application (Open Platform) open.weixin.qq.com snsapi_login (QR कोड फ़्लो)

Official Accounts Platform पर एक Subscription Account काम नहीं करेगा। इसमें OAuth वेब पेज प्राधिकरण अनुमतियों का अभाव होता है। केवल एक Service Account में वे अनुमतियाँ होती हैं।

Hospitality और Retail में अधिकांश एंटरप्राइज परिनियोजन दोनों पंजीकरणों को लागू करते हैं। होटल का एक अतिथि Chrome में पोर्टल खोल सकता है, WeChat के साथ एक QR कोड स्कैन कर सकता है, और Open Platform फ़्लो के माध्यम से प्रमाणित कर सकता है। या वे WeChat के भीतर ही एक लिंक का अनुसरण कर सकते हैं, इन-ऐप ब्राउज़र में पहुंच सकते हैं, और Official Accounts फ़्लो के माध्यम से चुपचाप प्रमाणित कर सकते हैं। दोनों रास्तों को संभालना आवश्यक है।

स्कोप चयन और डेटा संग्रह

OAuth स्कोप एक वास्तविक आर्किटेक्चरल निर्णय है, न कि केवल एक कॉन्फ़िगरेशन विवरण। यह निर्धारित करता है कि उपयोगकर्ता को कितनी परेशानी का सामना करना पड़ता है और आपके WiFi Analytics प्लेटफ़ॉर्म को क्या डेटा प्राप्त होता है।

snsapi_base केवल OpenID लौटाता है - जो आपके Official Account के भीतर उस उपयोगकर्ता के लिए एक स्थिर, अद्वितीय पहचानकर्ता है। इसके लिए किसी उपयोगकर्ता सहमति संकेत की आवश्यकता नहीं होती है। प्रमाणीकरण अदृश्य होता है। इसका उपयोग उन लौटने वाले मेहमानों के लिए करें जिनकी प्रोफ़ाइल आपके पास पहले से है, या स्टेडियमों और परिवहन केंद्रों जैसे उच्च-थ्रूपुट वातावरण के लिए करें जहाँ कनेक्शन की गति प्राथमिकता है।

snsapi_userinfo OpenID के साथ उपनाम, प्रोफ़ाइल छवि, लिंग, भाषा सेटिंग और शहर लौटाता है। यह एक स्पष्ट सहमति स्क्रीन को ट्रिगर करता है। पहली बार आने वाले मेहमानों के पंजीकरण के लिए इसका उपयोग एक फर्स्ट-पार्टी डेटा प्रोफ़ाइल बनाने के लिए करें, जिसे पोर्टल पेज पर PIPL-अनुपालन और GDPR-अनुपालन सहमति परत के साथ जोड़ा गया हो।

व्यावहारिक नियम: गति के लिए snsapi_base का उपयोग करें, डेटा के लिए snsapi_userinfo का। आप यह जाँच कर दोनों को लागू कर सकते हैं कि उपयोगकर्ता का OpenID आपके डेटाबेस में पहले से मौजूद है या नहीं। यदि ऐसा है, तो snsapi_base का अनुरोध करें। यदि नहीं है, तो snsapi_userinfo का अनुरोध करें।

नेटवर्क प्रवर्तन: RADIUS CoA और MAC बाईपास

एक OAuth टोकन पहचान साबित करता है। यह नेटवर्क नहीं खोलता है। एक अलग तंत्र को सफल प्रमाणीकरण को नेटवर्क नीति परिवर्तन में बदलना होगा।

RADIUS Change of Authorisation (CoA), जिसे RFC 3576 में परिभाषित किया गया है, मानक दृष्टिकोण है। पोर्टल सर्वर को एक वैध OAuth टोकन प्राप्त होने के बाद, यह वायरलेस कंट्रोलर को एक CoA अनुरोध भेजता है। कंट्रोलर सत्र को अपडेट करता है, डिवाइस को वॉल्ड गार्डन VLAN (एक प्रतिबंधित नेटवर्क खंड जो केवल पोर्टल ट्रैफ़िक की अनुमति देता है) से पूर्ण गेस्ट VLAN में स्थानांतरित करता है। यह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, और Fortinet के साथ काम करता है।

MAC address bypass सफल OAuth के बाद डिवाइस के MAC पते को एक अधिकृत क्लाइंट के रूप में पंजीकृत करता है। इसके बाद कंट्रोलर बिना किसी अतिरिक्त चुनौती के उस पते से ट्रैफ़िक की अनुमति देता है। इसे लागू करना सरल है लेकिन इसमें दो जोखिम हैं: MAC पतों को स्पूफ़ किया जा सकता है, और iOS 14 तथा Android 10 के बाद से डिफ़ॉल्ट रूप से MAC एड्रेस रैंडमाइजेशन का उपयोग किया जाता है, जो पुन: कनेक्शन पर तंत्र को बाधित करता है।

किसी भी परिनियोजन के लिए जहाँ सुरक्षा मायने रखती है, RADIUS CoA सही विकल्प है। गेस्ट नेटवर्क को सुरक्षित करने के बारे में अधिक जानकारी के लिए, What Is Secure WiFi: Essential Guide for Business 2026 और Enterprise WiFi Security: A Complete Guide for 2026 देखें।

कार्यान्वयन मार्गदर्शिका

परिनियोजन-पूर्व चेकलिस्ट

कॉन्फ़िगरेशन की एक भी लाइन लिखने से पहले, इन पांच चरणों को पूरा करें।

पहला, एक्सेस संदर्भ निर्धारित करें। अपने स्थान का सर्वेक्षण करें और पहचानें कि क्या मेहमानों को WeChat इन-ऐप ब्राउज़र के भीतर, एक मानक मोबाइल ब्राउज़र में, या दोनों में पोर्टल का सामना करना पड़ेगा। उत्तर आपकी प्लेटफ़ॉर्म पंजीकरण आवश्यकताओं को निर्धारित करता है।

दूसरा, सही प्लेटफ़ॉर्म पर पंजीकरण करें। इन-ऐप ब्राउज़र एक्सेस के लिए, WeChat Official Accounts Platform पर एक Service Account बनाएं। मानक ब्राउज़र एक्सेस के लिए, WeChat Open Platform पर एक Website Application पंजीकृत करें। प्रत्येक के लिए अपना AppID और AppSecret नोट करें।

तीसरा, अपने रीडायरेक्ट URI को कॉन्फ़िगर करें। आपके पोर्टल द्वारा उपयोग किए जाने वाले प्रत्येक डोमेन और सबडोमेन को पंजीकृत करें, जिसमें स्टेजिंग वातावरण भी शामिल हैं। WeChat सटीक-मिलान सत्यापन लागू करता है। बेमेल होने पर त्रुटि 40029 मिलती है।

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

पांचवां, CSRF सुरक्षा के लिए state पैरामीटर लागू करें। एक क्रिप्टोग्राफ़िक रूप से रैंडम मान उत्पन्न करें, इसे उपयोगकर्ता के सत्र में संग्रहीत करें, इसे OAuth अनुरोध में पास करें, और वापस आने पर इसे सत्यापित करें।

Ruckus SmartZone के लिए कॉन्फ़िगरेशन चरण

Ruckus SmartZone चलाने वाले स्थानों के लिए, WeChat पोर्टल कॉन्फ़िगरेशन Services and Profiles, फिर Hotspots and Portals, फिर WeChat टैब के अंतर्गत होता है। आप Authentication URL (आपके पोर्टल सर्वर का WeChat कॉलबैक एंडपॉइंट), DNAT Destination (वह सर्वर जो अप्रमाणित क्लाइंट रीडायरेक्ट को संभालता है), और Grace Period (वह समय सीमा जिसके दौरान हाल ही में डिस्कनेक्ट हुआ उपयोगकर्ता बिना पुन: प्रमाणित किए फिर से जुड़ सकता है, जो डिफ़ॉल्ट रूप से 60 मिनट है) को कॉन्फ़िगर करते हैं। आप प्रमाणीकरण चरण के दौरान WeChat के API एंडपॉइंट्स पर ट्रैफ़िक की अनुमति देने के लिए वॉल्ड गार्डन व्हाइटलिस्ट को भी कॉन्फ़िगर करते हैं। समान कंट्रोलर कॉन्फ़िगरेशन पैटर्न के लिए Step-by-Step Guide: Configuring Ruijie Wireless Controllers for Guest WiFi Captive Portals भी देखें।

इन-ऐप ब्राउज़र डिटेक्शन

WeChat का इन-ऐप ब्राउज़र एक उपयोगकर्ता एजेंट स्ट्रिंग सेट करता है जिसमें MicroMessenger होता है। आपके पोर्टल को इस स्ट्रिंग का पता लगाना चाहिए और उपयुक्त OAuth फ़्लो प्रदान करना चाहिए। यदि MicroMessenger मौजूद है, तो Official Accounts फ़्लो का उपयोग करें। यदि अनुपस्थित है, तो Open Platform QR कोड फ़्लो का उपयोग करें। इसका सही ढंग से पता लगाने में विफलता से अनुभव बाधित हो सकता है या प्रमाणीकरण त्रुटियां हो सकती हैं।

सर्वोत्तम प्रथाएं

डेटा न्यूनीकरण और दोहरे-ढांचे का अनुपालन

GDPR (यूरोपीय आगंतुकों पर लागू) और PIPL (चीनी नागरिकों पर लागू) दोनों को व्यक्तिगत डेटा के प्रसंस्करण के लिए एक कानूनी आधार, स्पष्ट उद्देश्य सीमा और डेटा न्यूनीकरण की आवश्यकता होती है। snsapi_base स्कोप को डेटा न्यूनीकरण सिद्धांतों के तहत snsapi_userinfo की तुलना में उचित ठहराना आसान है। जब आप snsapi_userinfo के माध्यम से जनसांख्यिकीय डेटा एकत्र करते हैं, तो अपने कानूनी आधार, अपनी प्रतिधारण अवधि और Tencent के साथ अपने डेटा प्रसंस्करण समझौते का दस्तावेजीकरण करें।

PIPL, जो नवंबर 2021 से लागू है, संवेदनशील व्यक्तिगत जानकारी के लिए स्पष्ट सहमति की आवश्यकता रखता है और यह आदेश देता है कि चीन के बाहर के डेटा प्रोसेसर समकक्ष सुरक्षा मानकों को लागू करें। यदि आपका पोर्टल सर्वर मुख्य भूमि चीन से बाहर है, तो आपको यह आकलन करना होगा कि क्या आपके द्वारा प्राप्त WeChat OpenID और प्रोफ़ाइल डेटा पर सीमा पार डेटा स्थानांतरण नियम लागू होते हैं।

बहु-संपत्ति परिनियोजनों के लिए UnionID

OpenID प्रति उपयोगकर्ता प्रति Official Account अद्वितीय होता है। यदि आप संपत्तियों में कई Official Accounts संचालित करते हैं, तो एक ही अतिथि के पास प्रत्येक में अलग-अलग OpenID होंगे। WeChat एक UnionID प्रदान करता है जो एक ही Open Platform पंजीकरण से जुड़े सभी खातों में सुसंगत रहता है। होटल श्रृंखलाओं, खुदरा समूहों, या हवाई अड्डा ऑपरेटरों के लिए जो कई स्थानों का प्रबंधन कर रहे हैं, शुरू से ही UnionID-आधारित पहचान समाधान लागू करें।

सुरक्षा सुदृढ़ीकरण

AppSecret को एक एनवायरनमेंट वेरिएबल या सीक्रेट्स मैनेजर में स्टोर करें, सोर्स कोड में कभी नहीं। यदि आपको इसके उजागर होने का संदेह है, तो इसे तुरंत रोटेट करें। दुरुपयोग को रोकने के लिए अपने टोकन एक्सचेंज एंडपॉइंट पर रेट लिमिटिंग लागू करें। सभी OAuth त्रुटियों को लॉग करें, विशेष रूप से 40029 (अमान्य कोड) और 40163 (कोड समाप्त), क्योंकि ये या तो गलत कॉन्फ़िगरेशन या सक्रिय जांच का संकेत देते हैं।

गेस्ट नेटवर्क सुरक्षा आर्किटेक्चर के व्यापक दृष्टिकोण के लिए, Why Consumer WiFi Gear Doesn't Belong on Your Guest Network देखें।

केस स्टडीज

लक्जरी होटल श्रृंखला, सिंगापुर

सिंगापुर में एक 350 कमरों वाले लक्जरी होटल ने, जो मुख्य रूप से चीनी व्यावसायिक यात्रा क्षेत्र की सेवा करता है, अपने मौजूदा ईमेल लॉगिन विकल्प के साथ WeChat WiFi प्रमाणीकरण लागू किया। कार्यान्वयन से पहले, फ्रंट-डेस्क कर्मचारियों ने WiFi लॉगिन कठिनाइयों के बारे में प्रति दिन औसतन 15 अतिथि शिकायतों की सूचना दी थी। चीनी मेहमान उन ईमेल पतों का उपयोग करने का प्रयास कर रहे थे जिन्हें उन्होंने अपने यात्रा उपकरणों पर कॉन्फ़िगर नहीं किया था।

होटल ने WeChat Official Accounts Platform पर एक Service Account और Open Platform पर एक Website Application पंजीकृत किया। उन्होंने पहली बार जुड़ने वालों के लिए snsapi_userinfo और MAC पते द्वारा पहचाने जाने वाले लौटने वाले मेहमानों के लिए snsapi_base कॉन्फ़िगर किया। सत्र प्रचार को संभालने के लिए HPE Aruba कंट्रोलर को RADIUS CoA के लिए कॉन्फ़िगर किया गया था।

30 दिनों के भीतर, अतिथि WiFi लॉगिन शिकायतें घटकर प्रति दिन दो से कम हो गईं। होटल के WiFi Analytics डेटाबेस में पहले महीने में 4,200 सत्यापित फर्स्ट-पार्टी प्रोफाइल की वृद्धि हुई, जिसमें शहर-स्तरीय जनसांख्यिकीय डेटा ने लक्षित पोस्ट-स्टे संचार को सक्षम बनाया।

अंतर्राष्ट्रीय खुदरा मॉल, कुआलालंपुर

कुआलालंपुर में एक प्रीमियम खुदरा मॉल को, जिसके अकेले मलेशिया में 12 मिलियन WeChat उपयोगकर्ता हैं, एक ऐसे WiFi ऑनबोर्डिंग अनुभव की आवश्यकता थी जो उसके खरीदार आधार की डिजिटल अपेक्षाओं से मेल खाता हो। मॉल ने 180,000 वर्ग मीटर के खुदरा क्षेत्र में Cisco Meraki एक्सेस पॉइंट संचालित किए।

इस परिनियोजन ने क्लाउड ओवरले के रूप में Purple के Guest WiFi प्लेटफ़ॉर्म का उपयोग किया, जिसमें WeChat OAuth प्राथमिक प्रमाणीकरण विधि के रूप में और SMS OTP फ़ॉलबैक के रूप में था। Purple के हार्डवेयर-अज्ञेयवादी आर्किटेक्चर ने कस्टम विकास की आवश्यकता के बिना Cisco Meraki के साथ RADIUS CoA एकीकरण को संभाला।

मॉल ने परिनियोजन के बाद पहली तिमाही में WiFi सत्र शुरू होने में 34% की वृद्धि दर्ज की, जिसका श्रेय WeChat उपयोगकर्ताओं के लिए कम ऑनबोर्डिंग घर्षण को दिया गया। snsapi_userinfo सहमति प्रवाह के माध्यम से एकत्र किए गए फर्स्ट-पार्टी डेटा ने मॉल की मार्केटिंग टीम को लक्षित अभियान वितरण के लिए गृह शहर द्वारा खरीदारों को विभाजित करने में सक्षम बनाया।

retail_venue_wechat_wifi.png

समस्या निवारण और जोखिम न्यूनीकरण

त्रुटि कारण समाधान
40029 अमान्य कोड रीडायरेक्ट URI बेमेल या कोड का पुन: उपयोग सत्यापित करें कि पंजीकृत URI बिल्कुल मेल खाते हैं; कोड एकल-उपयोग वाले हैं
40163 कोड समाप्त टोकन एक्सचेंज में 5 मिनट से अधिक की देरी सर्वर-साइड प्रोसेसिंग समय कम करें; पुनः प्रयास तर्क लागू करें
प्रमाणीकरण के बाद खाली स्क्रीन RADIUS CoA कॉन्फ़िगर नहीं है या विफल हो रहा है कंट्रोलर CoA सेटिंग्स और UDP पोर्ट 3799 पर फ़ायरवॉल नियमों की जाँच करें
MAC रैंडमाइजेशन लौटने वाले अतिथि फ़्लो को बाधित करता है iOS/Android MAC रैंडमाइजेशन OpenID-आधारित सत्र सत्र ट्रैकिंग पर माइग्रेट करें; केवल-MAC पहचान से बचें
snsapi_userinfo खाली फ़ील्ड लौटाता है उपयोगकर्ता ने WeChat गोपनीयता प्रतिबंध सेट किए हैं शून्य (null) फ़ील्ड को सुचारू रूप से संभालें; एक्सेस के लिए प्रोफ़ाइल डेटा की आवश्यकता न रखें

ROI और व्यावसायिक प्रभाव

WeChat WiFi प्रमाणीकरण का व्यावसायिक मामला तीन मापने योग्य परिणामों पर आधारित है।

फर्स्ट-पार्टी डेटा अधिग्रहण। प्रत्येक snsapi_userinfo प्रमाणीकरण जनसांख्यिकीय डेटा के साथ एक सत्यापित अतिथि प्रोफ़ाइल उत्पन्न करता है। 70% ऑक्यूपेंसी पर चलने वाले 200 कमरों वाले होटल के लिए जिसमें 40% चीनी मेहमान हैं, यह प्रति वर्ष लगभग 20,000 नए सत्यापित प्रोफाइल का प्रतिनिधित्व करता है, जिनमें से प्रत्येक एक WeChat पहचान से जुड़ा है जो निरंतर पुन: जुड़ाव का समर्थन करता है।

कम सहायता बोझ। लॉगिन घर्षण अतिथि WiFi सहायता कॉलों का प्राथमिक चालक है। जो स्थान मौजूदा विकल्पों के साथ WeChat प्रमाणीकरण जोड़ते हैं, वे लगातार WiFi से संबंधित फ्रंट-डेस्क प्रश्नों में कमी की रिपोर्ट करते हैं, जिससे उच्च-मूल्य वाले इंटरैक्शन के लिए कर्मचारियों का समय बचता है।

मार्केटिंग पहुंच। WeChat Official Accounts स्थानों को अनुयायियों को सूचनाएं भेजने की अनुमति देते हैं। एक अतिथि जो आपके Official Account के माध्यम से प्रमाणित होता है, उसे इसका अनुसरण करने के लिए प्रेरित किया जा सकता है, जिससे एक सीधा संचार चैनल बनता है जो WeChat के पारिस्थितिकी तंत्र के भीतर काम करता है, जहाँ चीनी उपभोक्ता प्रति दिन औसतन 82 मिनट बिताते हैं (स्रोत: Walk the Chat)।

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

मुख्य परिभाषाएं

कैप्टिव पोर्टल

एक वेब-आधारित प्रमाणीकरण गेटवे जो एक अप्रमाणित डिवाइस से HTTP ट्रैफ़िक को रोकता है और नेटवर्क एक्सेस देने से पहले इसे लॉगिन पेज पर रीडायरेक्ट करता है।

वह तंत्र जिसके माध्यम से मेहमानों को WiFi प्रमाणीकरण प्रस्तुत किया जाता है। WeChat OAuth उन कई प्रमाणीकरण विधियों में से एक है जो एक कैप्टिव पोर्टल प्रदान कर सकता है।

OAuth 2.0

एक उद्योग-मानक प्राधिकरण प्रोटोकॉल जो किसी तीसरे पक्ष के एप्लिकेशन (कैप्टिव पोर्टल) को उपयोगकर्ता की ओर से किसी वेब सेवा (WeChat) तक सीमित पहुंच प्राप्त करने की अनुमति देता है, बिना उपयोगकर्ता द्वारा तीसरे पक्ष के साथ अपना पासवर्ड साझा किए।

अंतर्निहित ढांचा जो WeChat लॉगिन को संभव बनाता है। पोर्टल कभी भी उपयोगकर्ता के WeChat क्रेडेंशियल नहीं देखता है; इसे केवल एक टोकन प्राप्त होता है जो पुष्टि करता है कि WeChat ने उन्हें प्रमाणित किया है।

RADIUS CoA

Change of Authorisation. RFC 3576 में परिभाषित एक तंत्र जो एक RADIUS सर्वर को सक्रिय नेटवर्क क्लाइंट के सत्र प्राधिकरण विशेषताओं को गतिशील रूप से संशोधित करने की अनुमति देता है, जैसे कि VLAN असाइनमेंट बदलना।

नेटवर्क प्रवर्तन तंत्र जो एक सफल WeChat OAuth एक्सचेंज को वास्तविक नेटवर्क एक्सेस में बदलता है। CoA के बिना, अतिथि प्रमाणित तो हो जाता है लेकिन कंट्रोलर को नेटवर्क खोलने का पता नहीं चलता है।

OpenID

एक विशिष्ट Official Account या Website Application के लिए एक विशिष्ट उपयोगकर्ता को WeChat द्वारा सौंपा गया एक अद्वितीय पहचानकर्ता। यह सत्रों में स्थिर रहता है लेकिन विभिन्न खातों में भिन्न होता है।

आपके WiFi एनालिटिक्स डेटाबेस में अतिथि की पहचान करने के लिए उपयोग की जाने वाली प्राथमिक कुंजी। यदि आप कई Official Accounts संचालित करते हैं और आपको क्रॉस-अकाउंट पहचान समाधान की आवश्यकता है तो इसके बजाय UnionID का उपयोग करें।

snsapi_base

एक WeChat OAuth स्कोप जो मूक प्रमाणीकरण को सक्षम बनाता है, सहमति संकेत प्रदर्शित किए बिना केवल उपयोगकर्ता का OpenID लौटाता है।

लौटने वाले मेहमानों या उच्च-थ्रूपुट वातावरण के लिए उपयोग करें जहाँ कनेक्शन की गति प्राथमिकता है। OpenID के अलावा कोई जनसांख्यिकीय डेटा नहीं लौटाता है।

snsapi_userinfo

एक WeChat OAuth स्कोप जो उपयोगकर्ता का OpenID, उपनाम, प्रोफ़ाइल छवि, लिंग, भाषा और शहर लौटाता है, जिसके लिए एक स्पष्ट उपयोगकर्ता सहमति स्क्रीन की आवश्यकता होती है।

फर्स्ट-पार्टी डेटा प्रोफ़ाइल बनाने के लिए पहली बार आने वाले मेहमानों के पंजीकरण के लिए उपयोग करें। इसे GDPR और PIPL-अनुपालन सहमति परत के साथ जोड़ा जाना चाहिए।

PIPL

Personal Information Protection Law. नवंबर 2021 से लागू चीन का व्यापक डेटा गोपनीयता कानून, जो यह नियंत्रित करता है कि चीनी नागरिकों के व्यक्तिगत डेटा को कैसे एकत्र, संसाधित और स्थानांतरित किया जाना चाहिए।

WeChat OAuth के माध्यम से चीनी नागरिकों से डेटा एकत्र करने वाले किसी भी स्थान पर लागू होता है, चाहे वह स्थान कहीं भी स्थित हो। इसके लिए स्पष्ट सहमति, उद्देश्य सीमा और डेटा न्यूनीकरण की आवश्यकता होती है।

AppSecret

WeChat द्वारा जारी की गई एक गोपनीय क्रिप्टोग्राफ़िक कुंजी जो आपके एप्लिकेशन को प्रमाणित करती है जब यह WeChat के टोकन एक्सचेंज API को कॉल करता है।

केवल सर्वर साइड पर ही संग्रहीत किया जाना चाहिए। क्लाइंट-साइड कोड में उजागर होने से कोई भी पक्ष आपके एप्लिकेशन का प्रतिरूपण कर सकता है और WeChat को अनधिकृत API कॉल कर सकता है।

VLAN

Virtual Local Area Network. एक तार्किक नेटवर्क खंड जो डेटा लिंक परत पर ट्रैफ़िक को अलग करता है, जिससे एक एकल भौतिक नेटवर्क कई अलग-अलग ट्रैफ़िक धाराओं को ले जा सकता है।

कैप्टिव पोर्टल परिनियोजनों में अप्रमाणित उपकरणों (वॉल्ड गार्डन VLAN) को प्रमाणित मेहमानों (गेस्ट VLAN) से अलग करने के लिए उपयोग किया जाता है। सफल प्रमाणीकरण पर RADIUS CoA डिवाइस को VLAN के बीच स्थानांतरित करता है।

UnionID

एक WeChat पहचानकर्ता जो एक ही Open Platform पंजीकरण से जुड़े सभी Official Accounts और Website Applications में किसी दिए गए उपयोगकर्ता के लिए सुसंगत रहता है।

होटल श्रृंखलाओं, खुदरा समूहों और बहु-स्थान ऑपरेटरों के लिए आवश्यक है जिन्हें कई संपत्तियों में एक ही अतिथि को पहचानने की आवश्यकता होती, जिनमें से प्रत्येक का अपना Official Account होता है।

हल किए गए उदाहरण

सिंगापुर में एक 200 कमरों वाला लक्जरी होटल HPE Aruba कंट्रोलर्स का उपयोग करता है और बड़ी संख्या में चीनी व्यावसायिक यात्रियों की सेवा करता है। वे पहली बार आने वाले मेहमानों से जनसांख्यिकीय डेटा एकत्र करना चाहते हैं और यह सुनिश्चित करना चाहते हैं कि लौटने वाले मेहमान पोर्टल को दोबारा देखे बिना स्वचालित रूप से कनेक्ट हों। उन्हें WeChat OAuth एकीकरण को कैसे कॉन्फ़िगर करना चाहिए?

चरण 1: WeChat इन-ऐप ब्राउज़र के भीतर पोर्टल तक पहुँचने वाले मेहमानों को संभालने के लिए WeChat Official Accounts Platform (mp.weixin.qq.com) पर एक Service Account पंजीकृत करें। मानक मोबाइल ब्राउज़र पर मेहमानों के लिए WeChat Open Platform (open.weixin.qq.com) पर एक Website Application पंजीकृत करें。

चरण 2: MicroMessenger उपयोगकर्ता एजेंट स्ट्रिंग का पता लगाने के लिए कैप्टिव पोर्टल को कॉन्फ़िगर करें। इन-ऐप ब्राउज़र उपयोगकर्ताओं के लिए Official Accounts OAuth फ़्लो और मानक ब्राउज़र उपयोगकर्ताओं के लिए Open Platform QR कोड फ़्लो प्रदान करें。

चरण 3: पहली बार कनेक्शन के लिए (डेटाबेस में कोई मौजूदा OpenID नहीं है), snsapi_userinfo स्कोप का अनुरोध करें। OAuth रीडायरेक्ट से पहले एक PIPL-अनुपालन सहमति स्क्रीन प्रस्तुत करें। लौटे हुए OpenID, उपनाम, शहर और लिंग को अतिथि प्रोफ़ाइल डेटाबेस में संग्रहीत करें。

चरण 4: लौटने वाले मेहमानों के लिए (डेटाबेस में OpenID मौजूद है), snsapi_base स्कोप का अनुरोध करें। यह बिना किसी उपयोगकर्ता-दृश्य संकेत के चुपचाप प्रमाणित करता है。

चरण 5: UDP पोर्ट 3799 पर RADIUS CoA के लिए HPE Aruba कंट्रोलर को कॉन्फ़िगर करें। सफल OAuth के बाद, पोर्टल सर्वर डिवाइस को वॉल्ड गार्डन VLAN से गेस्ट VLAN में बढ़ावा देने के लिए एक CoA अनुरोध भेजता है。

चरण 6: लौटने वाले अतिथि का पता लगाने के लिए OpenID के साथ MAC एड्रेस लॉगिंग लागू करें। ध्यान दें कि MAC रैंडमाइजेशन के लिए प्राथमिक पहचानकर्ता के रूप में OpenID की आवश्यकता होती है, न कि केवल MAC पते की।

परीक्षक की टिप्पणी: यह दृष्टिकोण एक्सेस संदर्भ द्वारा दो प्लेटफ़ॉर्म पंजीकरणों को सही ढंग से अलग करता है, डेटा संग्रह के खिलाफ घर्षण को संतुलित करने के लिए स्कोप चयन का उपयोग करता है, और सुरक्षित नेटवर्क प्रवर्तन के लिए RADIUS CoA लागू करता है। प्राथमिक लौटने वाले अतिथि पहचानकर्ता के रूप में OpenID का उपयोग MAC रैंडमाइजेशन के लिए सही प्रतिक्रिया है। चीनी नागरिक डेटा के लिए PIPL सहमति परत गैर-परक्राम्य है।

एक खुदरा श्रृंखला की IT टीम तीन मॉल स्थानों पर WeChat WiFi लॉगिन के लिए उच्च विफलता दर की रिपोर्ट करती है। उपयोगकर्ता WeChat में प्रमाणित होते हैं लेकिन एक त्रुटि के साथ पोर्टल पेज पर वापस आ जाते हैं। पोर्टल लॉग त्रुटि 40029 दिखाते हैं। संभावित कारण क्या है और आप इसे कैसे हल करते हैं?

त्रुटि 40029 का अर्थ है कि WeChat ने टोकन एक्सचेंज के दौरान प्राधिकरण कोड को अस्वीकार कर दिया। दो सबसे आम कारण रीडायरेक्ट URI बेमेल और कोड का पुन: उपयोग हैं。

चरण 1: Official Accounts Platform और Open Platform दोनों के लिए WeChat डेवलपर कंसोल में लॉग इन करें। OAuth सेटिंग्स पर जाएं और सभी पंजीकृत रीडायरेक्ट URI सूचीबद्ध करें。

चरण 2: तीनों स्थानों पर उत्पादन में आपके पोर्टल सर्वर द्वारा उपयोग किए जाने वाले वास्तविक रीडायरेक्ट URI के साथ इनकी तुलना करें। सबडोमेन अंतर (portal.brand.com बनाम brand.com), प्रोटोकॉल अंतर (HTTP बनाम HTTPS), और पथ अंतर (/callback बनाम /wechat/callback) की जाँच करें。

चरण 3: WeChat कंसोल में प्रत्येक संस्करण को पंजीकृत करें। WeChat सटीक-मिलान सत्यापन करता है, न कि उपसर्ग मिलान。

चरण 4: यदि URI मेल खाते हैं, तो जांचें कि क्या आपका पोर्टल सर्वर प्राधिकरण कोड का पुन: उपयोग करने का प्रयास कर रहा है। WeChat कोड एकल-उपयोग वाले होते हैं और पांच मिनट के बाद समाप्त हो जाते हैं। यदि आपका सर्वर उसी कोड के साथ टोकन एक्सचेंज का पुनः प्रयास करता है, तो उसे दूसरे प्रयास में 40029 प्राप्त होगा。

चरण 5: डुप्लिकेट अनुरोधों को रोकने के लिए टोकन एक्सचेंज एंडपॉइंट में इडेम्पोटेंसी (idempotency) लागू करें।

परीक्षक की टिप्पणी: त्रुटि 40029 WeChat OAuth परिनियोजनों में सबसे आम त्रुटि है और यह लगभग हमेशा रीडायरेक्ट URI बेमेल के कारण होती है। बहु-स्थान परिनियोजन विशेष रूप से संवेदनशील होते हैं क्योंकि प्रत्येक स्थान एक अलग सबडोमेन या लोड बैलेंसर पते का उपयोग कर सकता है। द्वितीयक कारण, कोड का पुन: उपयोग, कम आम है लेकिन यदि URI पंजीकरण सही होने की पुष्टि हो जाती है तो इसकी जांच करना उचित है।

अभ्यास प्रश्न

Q1. आप एक 60,000 की क्षमता वाले स्टेडियम के लिए एक कैप्टिव पोर्टल तैनात कर रहे हैं जो महत्वपूर्ण चीनी प्रशंसक आधार के साथ अंतर्राष्ट्रीय कार्यक्रमों की मेजबानी करता है। सेलुलर भीड़ को कम करने के लिए दरवाजे खुलने के पहले 15 मिनट के भीतर सभी उपस्थित लोगों को ऑनलाइन लाना प्राथमिकता है। मार्केटिंग डेटा संग्रह एक माध्यमिक उद्देश्य है। आपको कौन सा WeChat OAuth स्कोप कॉन्फ़िगर करना चाहिए, और क्यों?

संकेत: पोर्टल सर्वर पर एक साथ 15,000 उपयोगकर्ताओं को प्रदर्शित होने वाली सहमति स्क्रीन के प्रभाव पर विचार करें।

मॉडल उत्तर देखें

snsapi_base स्कोप को कॉन्फ़िगर करें। यह बिना किसी उपयोगकर्ता सहमति संकेत के मूक प्रमाणीकरण को सक्षम बनाता है, जिससे सबसे तेज़ संभव ऑनबोर्डिंग अनुभव मिलता है। स्टेडियम के पैमाने पर, एक सहमति स्क्रीन घर्षण जोड़ती है जो हजारों समवर्ती कनेक्शनों में गुणा हो जाती है और पोर्टल सर्वर लोड स्पाइक्स का कारण बन सकती है। snsapi_base केवल OpenID लौटाता है, जो सत्र को लॉग करने और लौटने वाले प्रशंसकों की पहचान करने के लिए पर्याप्त है। पहली बार आने वाले प्रशंसकों के लिए जहाँ आप जनसांख्यिकीय डेटा चाहते हैं, आप प्रमाणीकरण गेट के बजाय कनेक्शन के बाद के सर्वेक्षण के माध्यम से प्रोफ़ाइल पूरा करने के लिए प्रेरित कर सकते हैं।

Q2. आपकी टीम का एक नेटवर्क आर्किटेक्ट सीधे ब्राउज़र से टोकन एक्सचेंज कॉल करके सर्वर राउंड-ट्रिप को कम करने के लिए कैप्टिव पोर्टल के क्लाइंट-साइड JavaScript में WeChat AppSecret को संग्रहीत करने का प्रस्ताव करता है। बताएं कि यह दृष्टिकोण एक गंभीर सुरक्षा विफलता क्यों है और सही आर्किटेक्चर क्या है।

संकेत: विचार करें कि क्लाइंट-साइड कोड कौन देख सकता है और AppSecret उन्हें क्या करने की अनुमति देता है।

मॉडल उत्तर देखें

क्लाइंट-साइड JavaScript में AppSecret को संग्रहीत करना इसे किसी भी ऐसे व्यक्ति के सामने उजागर करता है जो पेज स्रोत देखता है या नेटवर्क ट्रैफ़िक को रोकता है। AppSecret आपके एप्लिकेशन को WeChat के API के लिए प्रमाणित करता है। इसके साथ, एक दुर्भावनापूर्ण कर्ता आपके एप्लिकेशन का प्रतिरूपण कर सकता है, किसी भी वैध प्राधिकरण कोड के साथ WeChat के टोकन एक्सचेंज एंडपॉइंट को कॉल कर सकता है, उपयोगकर्ता OpenID और प्रोफ़ाइल डेटा प्राप्त कर सकता है, और संभावित रूप से आपकी API दर सीमाओं को समाप्त कर सकता है। सही आर्किटेक्चर एक सर्वर-साइड टोकन एक्सचेंज एंडपॉइंट है। ब्राउज़र WeChat से प्राधिकरण कोड प्राप्त करता है और इसे आपके सर्वर पर पास करता है। आपका सर्वर, एनवायरनमेंट वेरिएबल या सीक्रेट्स मैनेजर में संग्रहीत AppSecret का उपयोग करके, टोकन के लिए कोड का आदान-प्रदान करता है और केवल वही डेटा लौटाता है जिसकी पोर्टल को आवश्यकता होती है। AppSecret आपके सर्वर को कभी नहीं छोड़ता है।

Q3. आपका स्थान विभिन्न शहरों में तीन होटल संपत्तियों का संचालन करता है, जिनमें से प्रत्येक का अपना WeChat Official Account है। एक लॉयल्टी कार्यक्रम का सदस्य जिसने तीनों संपत्तियों पर प्रमाणित किया है, उसके पास आपके डेटाबेस में तीन अलग-अलग OpenID हैं। आप इसे एकल अतिथि पहचान में कैसे हल करते हैं?

संकेत: WeChat क्रॉस-अकाउंट पहचान समाधान के लिए एक तंत्र प्रदान करता है जिसके लिए एक विशिष्ट प्लेटफ़ॉर्म कॉन्फ़िगरेशन की आवश्यकता होती है।

मॉडल उत्तर देखें

WeChat के UnionID तंत्र को लागू करें। तीनों Official Accounts को open.weixin.qq.com पर एक ही Open Platform पंजीकरण से लिंक करें। एक बार लिंक होने के बाद, WeChat snsapi_userinfo प्रतिक्रिया में OpenID के साथ एक UnionID लौटाता है। UnionID एक ही Open Platform पंजीकरण से जुड़े सभी खातों में किसी दिए गए उपयोगकर्ता के लिए सुसंगत रहता है। क्रॉस-प्रॉपर्टी रिकॉर्ड के लिए प्राथमिक अतिथि पहचानकर्ता के रूप में UnionID का उपयोग करने के लिए अपने डेटाबेस को माइग्रेट करें, खाता-विशिष्ट API कॉल के लिए प्रति-खाता OpenID को बनाए रखें। UnionID लागू होने से पहले प्रमाणित मेहमानों के लिए, UnionID को कैप्चर करने के लिए उनकी अगली यात्रा पर snsapi_userinfo के साथ पुन: प्रमाणीकरण ट्रिगर करें।

Q4. Cisco Meraki एक्सेस पॉइंट चलाने वाले एक खुदरा स्थान पर WeChat WiFi प्रमाणीकरण तैनात करने के बाद, मेहमान रिपोर्ट करते हैं कि वे WeChat लॉगिन सफलतापूर्वक पूरा करते हैं लेकिन पोर्टल पेज पर वापस आ जाते हैं और इंटरनेट ब्राउज़ नहीं कर सकते हैं। पोर्टल सर्वर लॉग सफल टोकन पुनर्प्राप्ति दिखाते हैं। सबसे संभावित कारण क्या है और आप इसका निदान कैसे करते हैं?

संकेत: पोर्टल ने पहचान सत्यापित कर ली है। अभी तक क्या नहीं हुआ है?

मॉडल उत्तर देखें

RADIUS Change of Authorisation (CoA) पूरा नहीं हो रहा है। पोर्टल सर्वर ने WeChat OAuth के माध्यम से अतिथि की पहचान सत्यापित कर ली है, लेकिन Cisco Meraki कंट्रोलर को डिवाइस को वॉल्ड गार्डन VLAN से गेस्ट VLAN में ले जाने का सफलतापूर्वक निर्देश नहीं दिया है। जाँच करके निदान करें: (1) क्या Meraki कंट्रोलर में RADIUS CoA सक्षम है और पोर्टल सर्वर का IP एक अधिकृत CoA क्लाइंट के रूप में सूचीबद्ध है; (2) क्या पोर्टल सर्वर और कंट्रोलर के बीच UDP पोर्ट 3799 खुला है; (3) CoA अनुरोध त्रुटियों या टाइमआउट के लिए पोर्टल सर्वर लॉग; और (4) क्या दोनों पक्षों पर कॉन्फ़िगर किया गया साझा रहस्य (shared secret) मेल खाता है। यदि आपके Meraki लाइसेंस टियर में CoA समर्थित नहीं है, तो MAC address bypass फ़ॉलबैक है, हालांकि इसमें गाइड में उल्लिखित MAC रैंडमाइजेशन जोखिम शामिल है।

इस श्रृंखला में आगे पढ़ें

Starlink पर कैप्टिव पोर्टल कैसे सेटअप करें: दूरस्थ और समुद्री स्थानों के लिए एक गाइड

यह गाइड विवरण देती है कि मूल Starlink हार्डवेयर को कैसे बायपास करें और एंटरप्राइज़ राउटिंग उपकरणों का उपयोग करके क्लाउड-प्रबंधित कैप्टिव पोर्टल को कैसे एकीकृत करें। आप सीखेंगे कि CGNAT सीमा को कैसे पार करें, VLAN सेगमेंटेशन लागू करें, सैटेलाइट बैंडविड्थ बाधाओं को प्रबंधित करें और नियामक अनुपालन सुनिश्चित करें।

गाइड पढ़ें →

कैप्टिव पोर्टल सर्वोत्तम प्रथाएं: उच्च रूपांतरण और अनुपालन के लिए डिज़ाइन करना

यह तकनीकी गाइड IT प्रबंधकों, नेटवर्क आर्किटेक्ट्स और स्थान संचालन निदेशकों को कैप्टिव पोर्टल तैनात करने के लिए एक संपूर्ण खाका देती है जो उच्च उपयोगकर्ता रूपांतरण के साथ नेटवर्क सुरक्षा को संतुलित करता है। यह VLAN सेगमेंटेशन और RADIUS प्रमाणीकरण से लेकर GDPR-अनुपालक सहमति डिज़ाइन और प्रमाणीकरण विधि चयन तक के संपूर्ण आर्किटेक्चर को कवर करता है। 2024 में 80,000+ स्थानों और 440 मिलियन लॉगिन में Purple के परिचालन अनुभव से ली गई, प्रत्येक सिफारिश वास्तविक परिनियोजन डेटा पर आधारित है।

गाइड पढ़ें →

अधिकतम नेटवर्क सुरक्षा और यूजर कन्वर्शन के लिए कैप्टिव पोर्टल को कैसे ऑप्टिमाइज़ करें

यह गाइड एंटरप्राइज स्थानों पर कैप्टिव पोर्टल को ऑप्टिमाइज़ करने के लिए एक संपूर्ण तकनीकी ब्लूप्रिंट प्रदान करती है, जिसमें नेटवर्क सेगमेंटेशन आर्किटेक्चर, ऑथेंटिकेशन मेथड का चयन, GDPR-अनुरूप सहमति डिज़ाइन और कन्वर्शन ऑप्टिमाइज़ेशन शामिल हैं। यह गाइड होटलों, रिटेल चेन, स्टेडियमों और सार्वजनिक क्षेत्र के संगठनों के IT प्रबंधकों, नेटवर्क आर्किटेक्ट्स और CTOs के लिए लिखी गई है, जिन्हें फर्स्ट-पार्टी डेटा कैप्चर के साथ नेटवर्क सुरक्षा को संतुलित करने की आवश्यकता है। Purple 2024 में 440 मिलियन लॉगिन के साथ 80,000+ से अधिक स्थानों पर कैप्टिव पोर्टल इन्फ्रास्ट्रक्चर का संचालन करता है, और यहाँ दिए गए फ्रेमवर्क उसी परिचालन अनुभव को दर्शाते हैं।

गाइड पढ़ें →