मुख्य सामग्री पर जाएं
हिन्दी

Guest WiFi कैप्टिव पोर्टल के साथ WeChat ऑथेंटिकेशन को एकीकृत करना

यह गाइड बताती है कि एंटरप्राइज़ Guest WiFi कैप्टिव पोर्टल में WeChat OAuth 2.0 ऑथेंटिकेशन को कैसे एकीकृत किया जाए। इसमें डुअल-प्लेटफ़ॉर्म रजिस्ट्रेशन आवश्यकताओं, फर्स्ट-पार्टी डेटा कैप्चर के लिए स्कोप चयन, RADIUS Change of Authorization के माध्यम से नेटवर्क प्रवर्तन, और GDPR व चीन के PIPL के अनुपालन को कवर किया गया है। हॉस्पिटैलिटी, रिटेल और इवेंट्स के वेन्यू ऑपरेटरों को बड़े पैमाने पर WeChat लॉगिन Guest WiFi को तैनात करने के लिए ठोस इम्प्लीमेंटेशन चरण, वास्तविक दुनिया के केस स्टडीज़ और सुरक्षा सुदृढ़ीकरण (security hardening) मार्गदर्शन मिलेंगे।

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

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

पॉडकास्ट ट्रांसक्रिप्ट देखें
कैप्टिव पोर्टलों के लिए WECHAT OAUTH ऑथेंटिकेशन को कैसे कॉन्फ़िगर करें एक Purple तकनीकी ब्रीफिंग - लगभग 10 मिनट --- परिचय और संदर्भ (लगभग 1 मिनट) आपका स्वागत है। यदि आप किसी होटल, रिटेल श्रृंखला, स्टेडियम या सम्मेलन केंद्र में guest WiFi के लिए ज़िम्मेदार हैं जो चीनी विज़िटर्स को सेवा प्रदान करता है, तो यह ब्रीफिंग आपके लिए है। Tencent के 2024 के आंकड़ों के अनुसार, WeChat के पास 1.38 बिलियन मासिक सक्रिय उपयोगकर्ता हैं। भारी बहुमत चीन में है, लेकिन प्लेटफ़ॉर्म का एक सार्थक अंतर्राष्ट्रीय पदचिह्न भी है - संयुक्त राज्य अमेरिका में चार मिलियन उपयोगकर्ता, मलेशिया में 12 मिलियन, और दक्षिण पूर्व एशिया, यूरोप और मध्य पूर्व में बढ़ती संख्या। जब कोई चीनी अतिथि आपके WiFi से कनेक्ट होता है और केवल ईमेल, Facebook या वाउचर कोड वाला लॉगिन पेज देखता है, तो उन्हें तत्काल घर्षण का सामना करना पड़ता है। हो सकता है कि उनके पास उस डिवाइस पर स्थानीय ईमेल पता सेट न हो। उनके पास लगभग निश्चित रूप से WeChat है। इसलिए सवाल यह नहीं है कि क्या आपको WeChat लॉगिन की पेशकश करनी चाहिए - बल्कि यह है कि आप इसे सही ढंग से, सुरक्षित रूप से और इस तरह से कैसे कॉन्फ़िगर करते हैं जिससे फर्स्ट-पार्टी डेटा उत्पन्न हो जिसका आप वास्तव में उपयोग कर सकें। आज हम इसी को कवर करने जा रहे हैं। हम OAuth 2.0 फ़्लो, आपके लिए आवश्यक दो प्लेटफ़ॉर्म रजिस्ट्रेशन, स्कोप निर्णय जो यह निर्धारित करता है कि आप कौन सा डेटा एकत्र करते हैं, नेटवर्क-साइड प्रवर्तन तंत्र, और 2026 में महत्वपूर्ण अनुपालन विचारों के बारे में जानेंगे। --- तकनीकी गहन विश्लेषण (लगभग 5 मिनट) आइए आर्किटेक्चर से शुरू करें। एक कैप्टिव पोर्टल एक अनऑथेंटिकेटेड डिवाइस से HTTP ट्रैफ़िक को इंटरसेप्ट करता है और इसे लॉगिन पेज पर रीडायरेक्ट करता है। वह लॉगिन पेज एक पोर्टल सर्वर पर होस्ट किया जाता है - या तो ऑन-प्रिमाइसेस या क्लाउड में। जब आप WeChat OAuth जोड़ते हैं, तो आप उस फ़्लो में एक थर्ड-पार्टी आइडेंटिटी प्रोवाइडर डाल रहे होते हैं। यहाँ अनुक्रम है। अतिथि आपके SSID से कनेक्ट होता है। एक्सेस पॉइंट या वायरलेस कंट्रोलर यह पता लगाता है कि डिवाइस का कोई ऑथेंटिकेटेड सेशन नहीं है और सभी HTTP ट्रैफ़िक को आपके कैप्टिव पोर्टल URL पर रीडायरेक्ट करता है। पोर्टल पेज लोड होता है और लॉगिन विकल्प प्रस्तुत करता है - जिसमें WeChat भी शामिल है। अतिथि WeChat लॉगिन पर टैप करता है। आपका पोर्टल सर्वर ब्राउज़र को WeChat के ऑथराइजेशन एंडपॉइंट पर रीडायरेक्ट करता है, जिसमें आपका App ID, रीडायरेक्ट URI, कोड का रिस्पॉन्स टाइप और स्कोप पास किया जाता है। WeChat ऑथेंटिकेशन को पूरी तरह से अपने सर्वर पर संभालता है। यदि अतिथि पहले से ही अपने ब्राउज़र में WeChat में लॉग इन है, तो उन्हें एक सहमति स्क्रीन दिखाई देती है। यदि वे WeChat इन-ऐप ब्राउज़र का उपयोग कर रहे हैं, तो अनुभव snsapi base स्कोप के साथ साइलेंट हो सकता है - कोई सहमति प्रॉम्प्ट बिल्कुल नहीं। इसके बाद WeChat एक अस्थायी ऑथराइजेशन कोड के साथ आपके पोर्टल के रीडायरेक्ट URI पर वापस रीडायरेक्ट करता है। आपका पोर्टल सर्वर उस कोड को एक्सेस टोकन से बदलता है, जिसमें आपका App ID, App Secret, कोड और ऑथराइजेशन कोड का ग्रांट टाइप पास किया जाता है। WeChat एक एक्सेस टोकन, एक रिफ्रेश टोकन, उपयोगकर्ता का Open ID और स्वीकृत स्कोप लौटाता है। यदि आपने snsapi userinfo स्कोप का अनुरोध किया है, तो आप उपयोगकर्ता का उपनाम (nickname), अवतार, लिंग और शहर प्राप्त करने के लिए दूसरा 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 ऐप से स्कैन करता है। व्यवहार में, अधिकांश वेन्यू डिप्लॉयमेंट दोनों का उपयोग करते हैं। होटल के WiFi पर कोई अतिथि Chrome में पोर्टल खोल सकता है, एक QR कोड देख सकता है, उसे WeChat से स्कैन कर सकता है और ऑथेंटिकेट कर सकता है। या वे WeChat में ही किसी लिंक का अनुसरण कर सकते हैं, इन-ऐप ब्राउज़र पर पहुंच सकते हैं, और snsapi base के साथ साइलेंट रूप से ऑथेंटिकेट कर सकते हैं। आइए स्कोप चयन के बारे में बात करते हैं, क्योंकि यह एक वास्तविक निर्णय बिंदु है। snsapi base केवल Open ID लौटाता है - आपके Official Account के भीतर उस उपयोगकर्ता के लिए एक विशिष्ट पहचानकर्ता। इसके लिए किसी उपयोगकर्ता सहमति प्रॉम्प्ट की आवश्यकता नहीं होती है। ऑथेंटिकेशन उपयोगकर्ता के लिए अदृश्य होता है। यह उन लौटने वाले अतिथियों के लिए आदर्श है जिन्हें आपने पहले ही प्रोफाइल कर लिया है, या उन वेन्यू के लिए जहाँ आप शून्य घर्षण चाहते हैं। snsapi userinfo Open ID के साथ-साथ उपयोगकर्ता का WeChat उपनाम (nickname), प्रोफ़ाइल चित्र, लिंग, भाषा सेटिंग और शहर लौटाता है। इसके लिए एक स्पष्ट सहमति स्क्रीन की आवश्यकता होती है। अधिकांश उपयोगकर्ता स्वीकार करते हैं, लेकिन घर्षण होता है। सही विकल्प आपके उपयोग के मामले पर निर्भर करता है। पहली बार अतिथि रजिस्ट्रेशन के लिए जहाँ आप एक प्रोफ़ाइल बनाना चाहते हैं, snsapi userinfo का उपयोग करें और इसे अपने पोर्टल पेज पर एक GDPR-अनुपालन सहमति परत (consent layer) के साथ जोड़ें। एक लौटने वाले अतिथि के लिए जिसने पहले ही सहमति दे दी है और जिसका प्रोफ़ाइल आपके पास पहले से है, साइलेंट री-ऑथेंटिकेशन के लिए snsapi base का उपयोग करें। अब, नेटवर्क प्रवर्तन पक्ष। OAuth टोकन प्राप्त करना पहचान साबित करता है, लेकिन यह स्वचालित रूप से नेटवर्क नहीं खोलता है। आपको एक सफल ऑथेंटिकेशन को नेटवर्क एक्सेस में अनुवादित करने के लिए एक तंत्र की आवश्यकता है। दो मानक दृष्टिकोण RADIUS Change of Authorisation (जो RFC 3576 में परिभाषित है) और MAC एड्रेस बाईपास हैं। RADIUS CoA के साथ, आपका पोर्टल सर्वर सफल OAuth के बाद नेटवर्क कंट्रोलर को एक CoA अनुरोध भेजता, और कंट्रोलर डिवाइस को अनऑथेंटिकेटेड VLAN से गेस्ट VLAN में स्थानांतरित करता है। यह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, और अधिकांश एंटरप्राइज़-ग्रेड कंट्रोलर के साथ काम करता है। MAC बाईपास के साथ, पोर्टल सर्वर डिवाइस के MAC एड्रेस को एक अधिकृत क्लाइंट के रूप में पंजीकृत करता है, और कंट्रोलर इसकी अनुमति देता है। MAC बाईपास लागू करना सरल है लेकिन कम सुरक्षित है, क्योंकि MAC एड्रेस को स्पूफ किया जा सकता है। Purple का Guest WiFi प्लेटफ़ॉर्म दोनों तंत्रों को संभालता है। WeChat OAuth पूरा होने के बाद, Purple का क्लाउड ओवरले अंतर्निहित हार्डवेयर को उपयुक्त सिग्नल भेजता है - चाहे वह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, या Fortinet हो। वेन्यू ऑपरेटर को उस अनुवाद को मैन्युअल रूप से प्रबंधित करने की आवश्यकता नहीं है। --- इम्प्लीमेंटेशन सिफारिशें और कमियां (लगभग 2 मिनट) मैं आपको वे पांच चीजें बताता हूं जो WeChat OAuth कैप्टिव पोर्टल इम्प्लीमेंटेशन को विफल कर देती हैं। पहला: रीडायरेक्ट URI बेमेल। WeChat आपके द्वारा प्लेटफ़ॉर्म पर पंजीकृत अधिकृत डोमेन के विरुद्ध रीडायरेक्ट URI को सत्यापित करता है। यदि आपका पोर्टल सर्वर एक अलग सबडोमेन, एक अलग पाथ, या HTTPS के बजाय HTTP का उपयोग करता है, तो OAuth फ़्लो त्रुटि 40029 - अमान्य कोड के साथ विफल हो जाता है। स्टेजिंग वातावरण सहित आपके द्वारा उपयोग किए जाने वाले प्रत्येक डोमेन वेरिएंट को पंजीकृत करें। दूसरा: क्लाइंट साइड पर App Secret। आपका App Secret कभी भी क्लाइंट-साइड JavaScript में दिखाई नहीं देना चाहिए। यह आपके सर्वर पर होना चाहिए। यदि यह उजागर होता है, तो कोई भी आपके एप्लिकेशन का रूप धारण कर सकता है और आपकी ओर से WeChat के API को कॉल कर सकता है। तीसरा: लापता CSRF सुरक्षा। OAuth अनुरोध में state पैरामीटर विशेष रूप से क्रॉस-साइट रिक्वेस्ट फोर्जरी को रोकने के लिए मौजूद है। एक क्रिप्टोग्राफ़िक रूप से रैंडम state मान उत्पन्न करें, इसे उपयोगकर्ता के सेशन में संग्रहीत करें, और WeChat द्वारा वापस रीडायरेक्ट करने पर इसे सत्यापित करें। इसे छोड़ दें और आपके पास एक वास्तविक भेद्यता (vulnerability) होगी। चौथा: इन-ऐप ब्राउज़र डिटेक्शन गैप। WeChat का इन-ऐप ब्राउज़र एक विशिष्ट यूजर एजेंट स्ट्रिंग सेट करता है जिसमें MicroMessenger होता है। यदि आपका पोर्टल इसका पता नहीं लगाता है और सही OAuth फ़्लो नहीं परोसता है, तो उपयोगकर्ताओं को खराब अनुभव या त्रुटि मिलती है। पांचवां: GDPR और PIPL संरेखण। यदि आप यूरोपीय विज़िटर्स को सेवा प्रदान करते हैं, तो GDPR लागू होता है। यदि आप चीनी विज़िटर्स को सेवा प्रदान करते हैं, तो चीन का व्यक्तिगत सूचना सुरक्षा कानून - PIPL - लागू होता है। दोनों को प्रोसेसिंग के लिए एक कानूनी आधार, स्पष्ट उद्देश्य सीमा और डेटा न्यूनीकरण की आवश्यकता होती है। डेटा न्यूनीकरण सिद्धांतों के तहत snsapi base को सही ठहराना snsapi userinfo की तुलना में आसान है। आप जो कुछ भी एकत्र करते हैं, अपने कानूनी आधार और अपनी प्रतिधारण अवधि को प्रलेखित करें। --- रैपिड-फायर प्रश्न और उत्तर (लगभग 1 मिनट) क्या मैं ऐसे पोर्टल पर WeChat लॉगिन का उपयोग कर सकता हूँ जो ईमेल और SMS लॉगिन भी प्रदान करता है? हाँ। Purple सहित अधिकांश एंटरप्राइज़ पोर्टल प्लेटफ़ॉर्म, एक ही पोर्टल पेज पर कई ऑथेंटिकेशन विधियों का समर्थन करते हैं। क्या WeChat OAuth iOS पर काम करता है? हाँ। iOS पर Safari में WeChat लॉगिन QR कोड फ़्लो या रीडायरेक्ट फ़्लो के माध्यम से काम करता है। WeChat ऐप स्वयं ऑथेंटिकेशन को संभालता है। यदि WeChat का API अनुपलब्ध हो तो क्या होगा? एक फ़ॉलबैक लागू करें। यदि WeChat API कॉल टाइम आउट हो जाती है या कोई त्रुटि लौटाती है, तो उपयोगकर्ता को एक वैकल्पिक लॉगिन विधि पर रीडायरेक्ट करें। क्या मैं Open ID का उपयोग एक स्थायी ग्राहक पहचानकर्ता के रूप में कर सकता हूँ? अपने Official Account के भीतर, हाँ। कई संपत्तियों में क्रॉस-अकाउंट पहचान समाधान के लिए, इसके बजाय UnionID का उपयोग करें। --- सारांश और अगले कदम (लगभग 1 मिनट) संक्षेप में। कैप्टिव पोर्टलों के लिए WeChat OAuth ऑथेंटिकेशन एक दो-प्लेटफ़ॉर्म रजिस्ट्रेशन अभ्यास, एक स्कोप निर्णय, एक नेटवर्क प्रवर्तन एकीकरण और एक अनुपालन समीक्षा है। इन चार चीजों को सही करें और आपके पास एक लॉगिन विधि होगी जो शून्य पासवर्ड घर्षण के साथ एक अरब से अधिक संभावित विज़िटर्स को सेवा प्रदान करती है। व्यावहारिक अगले कदम: यह निर्धारित करें कि आपके विज़िटर्स को पोर्टल WeChat इन-ऐप ब्राउज़र के अंदर मिलता है या मानक मोबाइल ब्राउज़र में। स्कोप तय करें - लौटने वाले अतिथियों के लिए snsapi base, सहमति के साथ पहली बार रजिस्ट्रेशन के लिए snsapi userinfo। पुष्टि करें कि आपका नेटवर्क हार्डवेयर RADIUS CoA का समर्थन करता है। GDPR और PIPL के विरुद्ध अपने गोपनीयता नोटिस की समीक्षा करें। लाइव होने से पहले रीडायरेक्ट URI, state पैरामीटर सत्यापन और इन-ऐप ब्राउज़र डिटेक्शन का परीक्षण करें। यदि आप देखना चाहते हैं कि Purple एक व्यापक Guest WiFi और एनालिटिक्स प्लेटफ़ॉर्म के हिस्से के रूप में WeChat OAuth को कैसे संभालता है - 2024 में 80,000 वेन्यू और 440 मिलियन लॉगिन में - तो purple.ai पर जाएं या अपनी अकाउंट टीम से बात करें। सुनने के लिए धन्यवाद। --- स्क्रिप्ट का अंत

header_image.png

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

जब कोई चीनी विज़िटर आपके एंटरप्राइज़ नेटवर्क से जुड़ता है और उसे एक कैप्टिव पोर्टल मिलता है जो केवल ईमेल, Facebook या वाउचर कोड की पेशकश करता है, तो आप तत्काल घर्षण (friction) पैदा करते हैं। Tencent के 2024 के आंकड़ों के अनुसार, WeChat के पास 1.38 बिलियन मासिक सक्रिय उपयोगकर्ता हैं। WeChat लॉगिन Guest WiFi क्षमताओं को एकीकृत करना केवल आतिथ्य (hospitality) की सुविधा नहीं है - यह बिना किसी घर्षण के इस जनसांख्यिकी (demographic) से फर्स्ट-पार्टी डेटा कैप्चर करने के लिए एक तकनीकी आवश्यकता है।

यह गाइड कैप्टिव पोर्टल में WeChat OAuth 2.0 ऑथेंटिकेशन को एकीकृत करने के लिए तकनीकी आर्किटेक्चर का विवरण देती है। यह मानक मोबाइल ब्राउज़र और WeChat इन-ऐप ब्राउज़र दोनों का समर्थन करने के लिए आवश्यक डुअल-प्लेटफ़ॉर्म रजिस्ट्रेशन के बारे में बताती है, डेटा संग्रह के लिए snsapi_base और snsapi_userinfo स्कोप के बीच के समझौतों (trade-offs) का मूल्यांकन करती है, और बताती है कि RADIUS Change of Authorization (CoA) या MAC ऑथेंटिकेशन बाईपास का उपयोग करके नेटवर्क एक्सेस को कैसे लागू किया जाए। यह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, और Fortinet इंफ्रास्ट्रक्चर पर इसे बड़े पैमाने पर तैनात करने के लिए आवश्यक सुरक्षा कॉन्फ़िगरेशन और अनुपालन आवश्यकताओं - GDPR और चीन के PIPL - को भी कवर करती है।

तकनीकी गहन विश्लेषण: WeChat OAuth 2.0 आर्किटेक्चर

एक कैप्टिव पोर्टल एक अनऑथेंटिकेटेड डिवाइस से HTTP ट्रैफ़िक को इंटरसेप्ट करता है और इसे पोर्टल सर्वर पर होस्ट किए गए लॉगिन पेज पर रीडायरेक्ट करता है। WeChat ऑथेंटिकेशन जोड़ने से OAuth 2.0 प्रोटोकॉल का उपयोग करके इस फ़्लो में एक थर्ड-पार्टी आइडेंटिटी प्रोवाइडर जुड़ जाता है - यह वही मानक है जिसका उपयोग Google, Microsoft Entra ID, और Okta द्वारा फ़ेडरेटेड आइडेंटिटी के लिए किया जाता है।

oauth_flow_diagram.png

ऑथेंटिकेशन अनुक्रम इस प्रकार काम करता है। अतिथि (guest) SSID से कनेक्ट होता है। एक्सेस पॉइंट या वायरलेस कंट्रोलर अनऑथेंटिकेटेड सेशन का पता लगाता है और HTTP ट्रैफ़िक को कैप्टिव पोर्टल URL पर रीडायरेक्ट करता है। अतिथि पोर्टल पेज पर WeChat लॉगिन चुनता है। पोर्टल सर्वर ब्राउज़र को open.weixin.qq.com पर WeChat के ऑथराइजेशन एंडपॉइंट पर रीडायरेक्ट करता है, जिसमें AppID, रीडायरेक्ट URI, code का रिस्पॉन्स टाइप और अनुरोधित स्कोप पास किया जाता है। WeChat अपने स्वयं के सर्वर पर ऑथेंटिकेशन को संभालता है। यदि अतिथि snsapi_base स्कोप के साथ WeChat इन-ऐप ब्राउज़र का उपयोग करता है, तो ऑथेंटिकेशन साइलेंट होता है - कोई सहमति प्रॉम्प्ट दिखाई नहीं देता है। यदि snsapi_userinfo का उपयोग किया जा रहा है, तो WeChat एक सहमति स्क्रीन प्रस्तुत करता है। इसके बाद WeChat एक अस्थायी ऑथराइजेशन कोड के साथ पोर्टल के रीडायरेक्ट URI पर वापस रीडायरेक्ट करता है। पोर्टल सर्वर api.weixin.qq.com/sns/oauth2/access_token को कॉल करके, AppID, AppSecret, कोड और authorization_code का ग्रांट टाइप पास करके इस कोड को एक्सेस टोकन से बदलता है। WeChat एक एक्सेस टोकन, एक रिफ्रेश टोकन, उपयोगकर्ता का OpenID और स्वीकृत स्कोप लौटाता है। यदि snsapi_userinfo स्वीकृत किया गया था, तो सर्वर उपयोगकर्ता का उपनाम (nickname), अवतार, लिंग और शहर प्राप्त करने के लिए दूसरा API कॉल करता है।

डुअल-प्लेटफ़ॉर्म रजिस्ट्रेशन की आवश्यकता

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

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

WeChat इन-ऐप ब्राउज़र के अंदर पोर्टल पर जाने वाले अतिथियों के लिए, आपको Official Accounts Platform पर एक Service Account की आवश्यकता होगी। एक Subscription Account काम नहीं करेगा - इसमें OAuth वेब पेज ऑथराइजेशन अनुमतियों की कमी होती है। Android पर Chrome या iOS पर Safari से पोर्टल पर जाने वाले अतिथियों के लिए, आपको Open Platform पर एक Website Application की आवश्यकता होगी, जो snsapi_login स्कोप का उपयोग करता है और उपयोगकर्ता को स्कैन करने के लिए एक QR कोड प्रस्तुत करता है।

व्यवहार में, अधिकांश वेन्यू डिप्लॉयमेंट दोनों का उपयोग करते हैं। एक होटल में कोई अतिथि Chrome में पोर्टल खोल सकता है, एक QR कोड देख सकता है, उसे WeChat से स्कैन कर सकता है और ऑथेंटिकेट कर सकता है। या वे WeChat में ही किसी लिंक का अनुसरण कर सकते हैं, इन-ऐप ब्राउज़र पर पहुंच सकते हैं, और snsapi_base के साथ साइलेंट रूप से ऑथेंटिकेट कर सकते हैं।

स्कोप चयन: डेटा कैप्चर बनाम घर्षण

scope_comparison.png

आपके द्वारा अनुरोधित स्कोप यह निर्धारित करता है कि आप कौन सा डेटा एकत्र करते हैं और अतिथि को किस घर्षण का अनुभव होता है। यह अनुपालन निहितार्थों के साथ एक वास्तविक निर्णय बिंदु है।

snsapi_base केवल OpenID लौटाता है - आपके Official Account के भीतर उस उपयोगकर्ता के लिए एक विशिष्ट पहचानकर्ता। इसके लिए किसी उपयोगकर्ता सहमति प्रॉम्प्ट की आवश्यकता नहीं होती है। ऑथेंटिकेशन अतिथि के लिए अदृश्य होता है। इसका उपयोग उन लौटने वाले अतिथियों के लिए करें जिनके प्रोफ़ाइल आपके पास पहले से हैं, या जब आप घर्षण-मुक्त एक्सेस को प्राथमिकता देते हैं। GDPR और PIPL डेटा न्यूनीकरण (data minimisation) सिद्धांतों के तहत, snsapi_base को सही ठहराना आसान है।

snsapi_userinfo OpenID के साथ-साथ उपयोगकर्ता का उपनाम (nickname), प्रोफ़ाइल चित्र, लिंग और शहर लौटाता है। इसके लिए एक स्पष्ट सहमति स्क्रीन की आवश्यकता होती है। इसका उपयोग पहली बार आने वाले अतिथियों के रजिस्ट्रेशन के लिए करें जहाँ आपको एक प्रोफ़ाइल बनाने की आवश्यकता होती है, जिसे आपके पोर्टल पेज पर एक अनुपालन सहमति परत (consent layer) के साथ जोड़ा गया हो।

मल्टी-प्रॉपर्टी डिप्लॉयमेंट के लिए UnionID

OpenID एक उपयोगकर्ता और एक विशिष्ट Official Account के संयोजन के लिए अद्वितीय होता है। 20 संपत्तियों (properties) वाला एक होटल समूह, जिनमें से प्रत्येक का अपना Official Account है, एक ही अतिथि के लिए 20 अलग-अलग OpenID देखेगा। UnionID इसे हल करता है। यह एक एकल पहचानकर्ता है जो एक ही Open Platform अकाउंट से जुड़े सभी Official Accounts और ऐप्स में एक उपयोगकर्ता का प्रतिनिधित्व करता है। अपने Official Accounts को अपने Open Platform अकाउंट से लिंक करें, और OAuth रिस्पॉन्स में UnionID वापस मिल जाएगा। यह क्रॉस-प्रॉपर्टी अतिथि पहचान का आधार है।

इम्प्लीमेंटेशन गाइड

नेटवर्क प्रवर्तन (Enforcement) तंत्र

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

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

MAC Authentication Bypass (MAB) डिवाइस के MAC एड्रेस को RADIUS डेटाबेस में एक अधिकृत क्लाइंट के रूप में पंजीकृत करता है। कंट्रोलर उस MAC के आधार पर एक्सेस की अनुमति देता है। MAB को लागू करना सरल है लेकिन यह अविच्छिन्न रूप से अविश्वसनीय है: आधुनिक iOS और Android डिवाइस डिफ़ॉल्ट रूप से MAC एड्रेस को रैंडमाइज़ करते हैं, जिससे दोबारा कनेक्ट होने पर सेशन एसोसिएशन टूट जाता है।

Purple का Guest WiFi प्लेटफ़ॉर्म इस अनुवाद को स्वचालित करता है। WeChat OAuth पूरा होने के बाद, Purple का क्लाउड ओवरले अंतर्निहित हार्डवेयर को उपयुक्त CoA या MAB सिग्नल भेजता है, जिससे मैन्युअल VLAN कॉन्फ़िगरेशन की आवश्यकता समाप्त हो जाती है।

सुरक्षा कॉन्फ़िगरेशन

तीन कॉन्फ़िगरेशन गैर-परक्राम्य (non-negotiable) हैं।

  1. AppSecret को सुरक्षित रखें। AppSecret कभी भी क्लाइंट-साइड JavaScript में दिखाई नहीं देना चाहिए। इसे आपके सर्वर पर ही रहना चाहिए। यदि यह उजागर होता है, तो हमलावर आपके एप्लिकेशन का रूप धारण कर सकते हैं और आपकी ओर से WeChat API को कॉल कर सकते हैं।
  2. CSRF सुरक्षा लागू करें। एक क्रिप्टोग्राफ़िक रूप से रैंडम state मान उत्पन्न करें, इसे उपयोगकर्ता के सेशन में संग्रहीत करें, और WeChat द्वारा वापस रीडायरेक्ट करने पर इसे सत्यापित करें। यह RFC 6749 में परिभाषित क्रॉस-साइट रिक्वेस्ट फोर्जरी हमलों को रोकता है।
  3. सभी रीडायरेक्ट URI वेरिएंट पंजीकृत करें। WeChat आपके पंजीकृत डोमेन के विरुद्ध रीडायरेक्ट URI को सत्यापित करता है। त्रुटि 40029 (अमान्य कोड) को रोकने के लिए स्टेजिंग वातावरण सहित आपके द्वारा उपयोग किए जाने वाले प्रत्येक सबडोमेन और पाथ वेरिएंट को पंजीकृत करें।

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

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

hotel_wechat_wifi.png

सर्वोत्तम अभ्यास और अनुपालन

GDPR अनुपालन

यदि आप यूरोपीय विज़िटर्स को सेवा प्रदान करते हैं या यूरोप में काम करते हैं, तो आपके द्वारा WeChat OAuth के माध्यम से एकत्र किए जाने वाले डेटा पर GDPR लागू होता है। आपको प्रोसेसिंग के लिए एक कानूनी आधार स्थापित करना होगा - आमतौर पर सहमति या वैध हित। आपको ऑथेंटिकेशन से पहले कैप्टिव पोर्टल पर एक स्पष्ट गोपनीयता नोटिस प्रदान करना होगा। आपको विषय एक्सेस अनुरोधों (subject access requests) और हटाने के अनुरोधों का सम्मान करना होगा। विस्तृत अनुपालन ढांचे के लिए, The Compliance Playbook: GDPR and Guest WiFi Data Privacy देखें।

PIPL अनुपालन

जब आप चीनी नागरिकों के व्यक्तिगत डेटा को प्रोसेस करते हैं तो चीन का व्यक्तिगत सूचना सुरक्षा कानून (Personal Information Protection Law - PIPL) लागू होता है। GDPR की तरह, PIPL के लिए स्पष्ट उद्देश्य सीमा, डेटा न्यूनीकरण और एक प्रलेखित कानूनी आधार की आवश्यकता होती है। डेटा न्यूनीकरण के तहत snsapi_userinfo की तुलना में snsapi_base को सही ठहराना आसान है। आप जो कुछ भी एकत्र करते हैं, लाइव होने से पहले अपने कानूनी आधार और प्रतिधारण अवधि (retention period) को प्रलेखित करें।

नेटवर्क सेगमेंटेशन

VLAN सेगमेंटेशन का उपयोग करके अपने कॉर्पोरेट नेटवर्क से guest WiFi ट्रैफ़िक को अलग करें। WeChat के माध्यम से ऑथेंटिकेट होने वाले अतिथियों को केवल इंटरनेट एक्सेस के साथ एक समर्पित गेस्ट VLAN में जाना चाहिए - आंतरिक प्रणालियों तक कोई पहुंच नहीं होनी चाहिए। यह कार्डधारक डेटा वातावरण अलगाव और सामान्य एंटरप्राइज़ सुरक्षा अभ्यास के लिए PCI-DSS आवश्यकताओं के अनुरूप है। सेगमेंटेशन आर्किटेक्चर के बारे में अधिक जानने के लिए, Bandwidth Management: A Practical Guide for 2026 देखें।

फ़ॉलबैक ऑथेंटिकेशन

यदि WeChat का API अनुपलब्ध है, तो आपके पोर्टल को एक वैकल्पिक लॉगिन विधि पर रीडायरेक्ट करना चाहिए। अतिथियों को खाली स्क्रीन के साथ न छोड़ें। ईमेल या SMS का फ़ॉलबैक निरंतरता सुनिश्चित करता है। यह विशेष रूप से Transport और Healthcare वातावरण के वेन्यू के लिए महत्वपूर्ण है जहाँ कनेक्टिविटी एक सेवा दायित्व है।

वास्तविक दुनिया के केस स्टडीज़

हॉस्पिटैलिटी: लक्ज़री होटल समूह

लंदन में एक 400 कमरों वाले लक्ज़री होटल में मुख्य भूमि चीन के अतिथियों के एक महत्वपूर्ण हिस्से को सेवा प्रदान की जाती है। उनके मौजूदा कैप्टिव पोर्टल को एक ईमेल पते और SMS सत्यापन की आवश्यकता थी। चीनी मोबाइल नंबर अक्सर यूरोपीय प्रदाताओं से SMS प्राप्त करने में विफल रहते हैं, और कई अतिथियों के डिवाइस पर स्थानीय ईमेल कॉन्फ़िगर नहीं होता है। इसका परिणाम पोर्टल पर 60% ड्रॉप-ऑफ दर के रूप में मिला।

होटल ने Official Accounts Platform पर एक Service Account और Open Platform पर एक Website Application पंजीकृत किया। पोर्टल MicroMessenger यूजर एजेंट का पता लगाता है और इन-ऐप ब्राउज़र उपयोगकर्ताओं के लिए snsapi_base को ट्रिगर करता है - जिससे वे बिना किसी सहमति स्क्रीन के तीन सेकंड से भी कम समय में कनेक्ट हो जाते हैं। Chrome या Safari के माध्यम से आने वाले अतिथियों को एक QR कोड दिखाई देता है। बाद के प्रवासों पर, उसी OpenID की पहचान की जाती है और अतिथि को साइलेंट रूप से दोबारा ऑथेंटिकेट किया जाता है। होटल का CRM वापसी यात्रा को लॉग करता है, जिससे लक्षित आगमन-पूर्व संचार सक्षम होता है। हॉस्पिटैलिटी वातावरण में WiFi तैनात करने के बारे में अधिक जानने के लिए, Hospitality देखें।

रिटेल: शॉपिंग मॉल एनालिटिक्स

एक बड़ा रिटेल मॉल किरायेदार मिश्रण (tenant mix) और विपणन निर्णयों को सूचित करने के लिए चीनी खरीदारों से जनसांख्यिकीय डेटा कैप्चर करना चाहता है। उन्हें मूल शहर, लिंग और विज़िट आवृत्ति की आवश्यकता है। snsapi_base अपर्याप्त है - उन्हें snsapi_userinfo की आवश्यकता है। पोर्टल पूर्ण userinfo स्कोप का अनुरोध करता है। अतिथि को एक WeChat सहमति स्क्रीन दिखाई देती है और वह अनुमति दें (Allow) पर टैप करता है। मॉल का एनालिटिक्स प्लेटफ़ॉर्म, जो Purple के WiFi Analytics के साथ एकीकृत है, सत्यापित जनसांख्यिकीय डेटा का एक प्रवाह प्राप्त करता है। शनिवार की दोपहर को, 40% WiFi उपयोगकर्ता एक विशिष्ट क्षेत्र से आते हैं। वह डेटा सीधे तौर पर यह सूचित करता है कि पॉप-अप इवेंट के लिए किन ब्रांडों से संपर्क किया जाए। रिटेल WiFi डिप्लॉयमेंट के बारे में अधिक जानने के लिए, Retail देखें।

समस्या निवारण और जोखिम शमन

WeChat OAuth कैप्टिव पोर्टल डिप्लॉयमेंट में पांच सबसे आम विफलता मोड इस प्रकार हैं।

रीडायरेक्ट URI बेमेल (त्रुटि 40029)। WeChat पंजीकृत डोमेन के विरुद्ध रीडायरेक्ट URI को सत्यापित करता है। कोई भी सबडोमेन, पाथ या प्रोटोकॉल बेमेल होने पर कोड एक्सचेंज विफल हो जाता है। स्टेजिंग वातावरण सहित प्रत्येक वेरिएंट को पंजीकृत करें।

AppSecret एक्सपोज़र। क्लाइंट-साइड कोड में AppSecret को एम्बेड करना सबसे गंभीर सुरक्षा त्रुटि है। सभी टोकन एक्सचेंज लॉजिक को सर्वर पर ले जाएं।

लापता CSRF सुरक्षा। state पैरामीटर सत्यापन को छोड़ने से पोर्टल क्रॉस-साइट रिक्वेस्ट फोर्जरी के प्रति संवेदनशील हो जाता है। प्रति सेशन एक क्रिप्टोग्राफ़िक रूप से रैंडम मान उत्पन्न करें और कॉलबैक पर इसे सत्यापित करें।

इन-ऐप ब्राउज़र डिटेक्शन विफलता। यूजर एजेंट में MicroMessenger का पता न लगाने का मतलब है कि इन-ऐप ब्राउज़र उपयोगकर्ताओं को गलत OAuth फ़्लो परोस दिया जाता है, जिससे त्रुटियां उत्पन्न होती हैं।

MAC एड्रेस रैंडमाइजेशन से MAB सेशन का टूटना। आधुनिक मोबाइल ऑपरेटिंग सिस्टम MAC एड्रेस को रैंडमाइज़ करते हैं। MAB-आधारित प्रवर्तन का उपयोग करने वाले अतिथि दोबारा कनेक्ट होने पर अपना सेशन खो देंगे। विश्वसनीय सेशन प्रबंधन के लिए RADIUS CoA पर अपग्रेड करें। सुरक्षित WiFi कॉन्फ़िगरेशन पर मार्गदर्शन के लिए, What Is Secure WiFi: Essential Guide for Business 2026 देखें।

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

WeChat लॉगिन Guest WiFi कार्यक्षमता को तैनात करने के तीन मापने योग्य प्रभाव हैं।

बढ़ी हुई ऑथेंटिकेशन दरें। SMS सत्यापन विफलता बिंदु और ईमेल प्रविष्टि की आवश्यकता को हटाने से सफलतापूर्वक कनेक्ट होने वाले चीनी विज़िटर्स का प्रतिशत बढ़ जाता है। WeChat समर्थन के बिना पोर्टलों के लिए 60% ड्रॉप-ऑफ दर एक वास्तविक बेसलाइन है।

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

कम सपोर्ट ओवरहेड। घर्षण-मुक्त लॉगिन कनेक्शन समस्याओं का निवारण करने वाले अंतर्राष्ट्रीय अतिथियों से फ्रंट-डेस्क और IT सपोर्ट कॉल को कम करता है।

Purple 80,000+ से अधिक वेन्यू में काम करता है और उसने 2024 में 440 million लॉगिन प्रोसेस किए (Purple आंतरिक डेटा)। प्लेटफ़ॉर्म ISO 27001 प्रमाणित, GDPR और CCPA अनुपालन है, और 99.999% अपटाइम बनाए रखता है। Retail और Hospitality के वेन्यू के लिए, WeChat ऑथेंटिकेशन नेटवर्क को लागत केंद्र (cost centre) से एक विश्वसनीय फर्स्ट-पार्टी डेटा अधिग्रहण चैनल में बदल देता है।

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

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

एक वेब पेज जो एक अनऑथेंटिकेटेड डिवाइस से HTTP ट्रैफ़िक को इंटरसेप्ट करता है और नेटवर्क एक्सेस दिए जाने से पहले उपयोगकर्ता को इसके साथ इंटरैक्ट करने की आवश्यकता होती है।

प्राथमिक इंटरफ़ेस जहाँ अतिथि को WeChat लॉगिन विकल्प प्रस्तुत किया जाता है। पोर्टल सर्वर इस पेज को होस्ट करता है और OAuth फ़्लो को संचालित करता है।

OAuth 2.0

एक उद्योग-मानक ऑथराइजेशन प्रोटोकॉल (RFC 6749) जो एक थर्ड-पार्टी एप्लिकेशन को उपयोगकर्ता की ओर से HTTP सेवा तक सीमित पहुंच प्राप्त करने की अनुमति देता है।

अंतर्निहित प्रोटोकॉल जिसका उपयोग WeChat उपयोगकर्ता क्रेडेंशियल को उजागर किए बिना पोर्टल सर्वर पर ऑथेंटिकेशन टोकन पास करने के लिए करता है। वही प्रोटोकॉल जिसका उपयोग Microsoft Entra ID, Okta, और Google Workspace द्वारा किया जाता है।

OpenID

एक विशिष्ट Official Account के लिए एक विशिष्ट WeChat उपयोगकर्ता को सौंपा गया एक अद्वितीय अल्फ़ान्यूमेरिक पहचानकर्ता।

WiFi एनालिटिक्स डेटाबेस में लौटने वाले अतिथियों की पहचान करने के लिए प्राथमिक कुंजी (primary key) के रूप में उपयोग किया जाता है। प्रत्येक Official Account के अनुसार बदलता है - क्रॉस-प्रॉपर्टी पहचान के लिए UnionID का उपयोग करें।

UnionID

एक एकल WeChat पहचानकर्ता जो एक ही Open Platform अकाउंट से जुड़े सभी Official Accounts और ऐप्स में एक उपयोगकर्ता का प्रतिनिधित्व करता है।

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

RADIUS CoA (Change of Authorization)

RADIUS प्रोटोकॉल (RFC 3576) का एक विस्तार जो एक RADIUS सर्वर को सक्रिय सेशन के ऑथराइजेशन विशेषताओं को गतिशील रूप से बदलने की अनुमति देता है।

सफल WeChat लॉगिन के बाद एक अतिथि डिवाइस को एक अलग प्री-ऑथेंटिकेशन VLAN से सक्रिय इंटरनेट VLAN में स्थानांतरित करने के लिए उपयोग की जाने वाली सुरक्षित विधि। Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, और Fortinet द्वारा समर्थित।

snsapi_base

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

लौटने वाले अतिथि के दोबारा ऑथेंटिकेशन के लिए अनुशंसित स्कोप। GDPR और PIPL डेटा न्यूनीकरण सिद्धांतों के तहत सही ठहराना आसान है।

snsapi_userinfo

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

पहली बार अतिथि रजिस्ट्रेशन के लिए उपयोग किया जाता है जहाँ एनालिटिक्स के लिए जनसांख्यिकीय डेटा की आवश्यकता होती है। GDPR और PIPL के तहत प्रलेखित कानूनी आधार की आवश्यकता होती है।

PIPL (Personal Information Protection Law)

चीन का व्यापक डेटा गोपनीयता कानून, जो नवंबर 2021 से प्रभावी है, चीन में स्थित प्राकृतिक व्यक्तियों की व्यक्तिगत जानकारी के प्रसंस्करण को नियंत्रित करता है।

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

AppSecret

एप्लिकेशन रजिस्ट्रेशन के दौरान WeChat द्वारा जारी की गई एक गोपनीय क्रिप्टोग्राफ़िक कुंजी, जिसका उपयोग पोर्टल सर्वर से API कॉल को ऑथेंटिकेट करने के लिए किया जाता है।

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

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

लंदन में एक 400 कमरों वाले लक्ज़री होटल में मुख्य भूमि चीन के अतिथियों के बीच 60% पोर्टल ड्रॉप-ऑफ दर है। वर्तमान पोर्टल को ईमेल और SMS सत्यापन की आवश्यकता होती है। IT डायरेक्टर को GDPR अनुपालन और नेटवर्क सुरक्षा बनाए रखते हुए WeChat ऑथेंटिकेशन लागू करने की आवश्यकता है।

चरण 1: WeChat Official Accounts Platform (mp.weixin.qq.com) पर एक Service Account और WeChat Open Platform (open.weixin.qq.com) पर एक Website Application पंजीकृत करें। चरण 2: MicroMessenger यूजर एजेंट स्ट्रिंग का पता लगाने के लिए पोर्टल को कॉन्फ़िगर करें। यदि पता चलता है, तो साइलेंट ऑथेंटिकेशन के लिए snsapi_base OAuth फ़्लो को ट्रिगर करें। यदि पता नहीं चलता है, तो QR कोड फ़्लो प्रस्तुत करें। चरण 3: WeChat लॉगिन बटन सक्रिय होने से पहले पोर्टल पेज पर एक GDPR-अनुपालन गोपनीयता नोटिस और सहमति चेकबॉक्स जोड़ें। नोटिस में यह स्पष्ट होना चाहिए: एकत्र किया गया डेटा (केवल OpenID), उद्देश्य (guest WiFi एक्सेस और वापसी यात्रा की पहचान), और प्रतिधारण अवधि। चरण 4: सफल OAuth टोकन एक्सचेंज के बाद, पोर्टल सर्वर Cisco Meraki कंट्रोलर को एक RADIUS CoA अनुरोध जारी करता है, जिससे अतिथि डिवाइस प्री-ऑथ VLAN से सेगमेंटेड गेस्ट VLAN में स्थानांतरित हो जाता है। चरण 5: अतिथि डेटाबेस में डिवाइस MAC एड्रेस के विरुद्ध OpenID संग्रहीत करें। बाद की यात्राओं पर, लौटने वाला OpenID साइलेंट री-ऑथेंटिकेशन को ट्रिगर करता है।

परीक्षक की टिप्पणी: यह दृष्टिकोण तकनीकी और अनुपालन दोनों आवश्यकताओं को सही ढंग से संबोधित करता है। snsapi_base का उपयोग करना GDPR डेटा न्यूनीकरण सिद्धांतों के अनुरूप है, जो SMS सत्यापन विफलता बिंदु को समाप्त करते हुए कानूनी जोखिम को कम करता है। RADIUS CoA सुरक्षित, स्वचालित नेटवर्क सेगमेंटेशन सुनिश्चित करता है। सहमति चेकबॉक्स एक प्रलेखित कानूनी आधार के लिए GDPR आवश्यकता को पूरा करता है। मुख्य निर्णय snsapi_userinfo पर snsapi_base का चयन करना है - होटल को इस उपयोग के मामले के लिए जनसांख्यिकीय डेटा की आवश्यकता नहीं है, इसलिए इसे एकत्र करने से अनावश्यक अनुपालन दायित्व पैदा होंगे।

एक रिटेल मॉल अपने एनालिटिक्स प्लेटफ़ॉर्म में फीड करने के लिए guest WiFi के माध्यम से चीनी खरीदारों से लिंग और शहर का डेटा कैप्चर करना चाहता है। वे वर्तमान में HPE Aruba हार्डवेयर पर चलने वाले अपने मौजूदा पोर्टल के लिए MAC Authentication Bypass का उपयोग करते हैं।

चरण 1: WeChat Official Accounts Platform पर एक Service Account पंजीकृत करें। चरण 2: लिंग और शहर प्राप्त करने के लिए snsapi_userinfo स्कोप का उपयोग करने के लिए पोर्टल को कॉन्फ़िगर करें। चरण 3: मूल्य विनिमय (value exchange) को समझाने वाली एक स्पष्ट सहमति स्क्रीन जोड़ें: प्रोफ़ाइल डेटा एक्सेस के बदले मुफ्त WiFi। सहमति GDPR और PIPL दोनों के तहत स्पष्ट और विस्तृत (granular) होनी चाहिए। चरण 4: ऑथेंटिकेशन के बाद, पोर्टल सर्वर RADIUS डेटाबेस में डिवाइस के MAC एड्रेस को पंजीकृत करता है। HPE Aruba कंट्रोलर MAB के माध्यम से एक्सेस की अनुमति देता है। चरण 5: डेटा प्रोसेसिंग रजिस्टर में कानूनी आधार (सहमति), उद्देश्य (वेन्यू एनालिटिक्स और मार्केटिंग), और प्रतिधारण अवधि (24 महीने) को प्रलेखित करें। डेटा हटाने का तंत्र प्रदान करें।

परीक्षक की टिप्पणी: snsapi_userinfo स्कोप आवश्यक जनसांख्यिकीय डेटा को सही ढंग से प्राप्त करता है। हालांकि, MAB पर भरोसा करना एक महत्वपूर्ण परिचालन जोखिम पैदा करता है: iOS 14+ और Android 10+ डिफ़ॉल्ट रूप से MAC एड्रेस को रैंडमाइज़ करते हैं, जिसका अर्थ है कि अतिथि दोबारा कनेक्ट होने पर अपना ऑथेंटिकेटेड सेशन खो देंगे और उन्हें फिर से ऑथेंटिकेट करने के लिए मजबूर होना पड़ेगा। मॉल को इसे हल करने के लिए HPE Aruba पर RADIUS CoA में माइग्रेट करने की योजना बनानी चाहिए। PIPL अनुपालन प्रलेखन वैकल्पिक नहीं है - यह चीनी नागरिकों के डेटा को प्रोसेस करने के लिए एक कानूनी आवश्यकता है, चाहे वेन्यू कहीं भी स्थित हो।

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

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

संकेत: विचार करें कि कौन सा स्कोप प्रत्येक विज़िट पर उपयोगकर्ता से सहमति मांगे बिना साइलेंट ऑथेंटिकेशन की अनुमति देता है।

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

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

Q2. परीक्षण के दौरान, आपका पोर्टल सफलतापूर्वक WeChat पर रीडायरेक्ट करता है, उपयोगकर्ता सहमति देता है, और WeChat आपके पोर्टल पर वापस रीडायरेक्ट करता है। हालांकि, पोर्टल सर्वर लॉग OAuth त्रुटि 40029 (अमान्य कोड) दिखाते हैं। सबसे संभावित कॉन्फ़िगरेशन त्रुटि क्या है, और आप इसे कैसे हल करते हैं?

संकेत: WeChat उस गंतव्य को सख्ती से सत्यापित करता है जिस पर वह ऑथराइजेशन कोड भेजता है, एक पंजीकृत सूची के विरुद्ध।

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

सबसे संभावित कारण रीडायरेक्ट URI बेमेल (mismatch) होना है। WeChat प्लेटफ़ॉर्म पर पंजीकृत अधिकृत डोमेन के विरुद्ध OAuth अनुरोध में रीडायरेक्ट URI को सत्यापित करता है। यदि पोर्टल सर्वर एक अलग सबडोमेन, एक अलग पाथ, या HTTPS के बजाय HTTP का उपयोग करता है, तो कोड एक्सचेंज त्रुटि 40029 के साथ विफल हो जाता है। समाधान: WeChat डेवलपर प्लेटफ़ॉर्म पर लॉग इन करें, अपने Service Account या Website Application सेटिंग्स पर जाएं, और आपके द्वारा उपयोग किए जाने वाले प्रत्येक रीडायरेक्ट URI वेरिएंट को जोड़ें - जिसमें स्टेजिंग सबडोमेन, विभिन्न पाथ और HTTPS संस्करण शामिल हैं। सुनिश्चित करें कि आपके OAuth अनुरोध में redirect_uri पैरामीटर पंजीकृत URI में से किसी एक से बिल्कुल मेल खाता हो, जिसमें URL एन्कोडिंग भी शामिल है।

Q3. एक IT मैनेजर टोकन एक्सचेंज प्रक्रिया को सीधे क्लाइंट ब्राउज़र से तेज़ करने के लिए कैप्टिव पोर्टल के फ्रंट-एंड JavaScript में WeChat AppSecret को एम्बेड करने का प्रस्ताव करता है। आपको इस प्रस्ताव को क्यों अस्वीकार करना चाहिए, और सही आर्किटेक्चर क्या है?

संकेत: सार्वजनिक रूप से सुलभ कोड में क्रिप्टोग्राफ़िक कुंजियों को उजागर करने के सुरक्षा निहितार्थों पर विचार करें।

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

इस प्रस्ताव को अस्वीकार करें। AppSecret एक गोपनीय क्रिप्टोग्राफ़िक कुंजी है। इसे क्लाइंट-साइड JavaScript में एम्बेड करने से यह किसी भी व्यक्ति के सामने उजागर हो जाता है जो पेज सोर्स देखता है या नेटवर्क ट्रैफ़िक को इंटरसेप्ट करता है। एक हमलावर AppSecret निकाल सकता है और एप्लिकेशन का रूप धारण कर सकता, वेन्यू की ओर से WeChat API को कॉल कर सकता है, उपयोगकर्ता डेटा तक पहुंच सकता है, और संभावित रूप से पूरे Official Account से समझौता कर सकता है। सही आर्किटेक्चर: क्लाइंट-साइड पोर्टल पेज WeChat से ऑथराइजेशन कोड प्राप्त करता है और इसे सर्वर-साइड API कॉल के माध्यम से पोर्टल सर्वर पर भेजता है। पोर्टल सर्वर एक सुरक्षित वातावरण चर (environment variable) में AppSecret रखता है और WeChat के API के साथ टोकन एक्सचेंज करता है। AppSecret कभी भी सर्वर से बाहर नहीं जाता है।

Q4. यूरोप भर में 15 संपत्तियों वाला एक होटल समूह एक एकीकृत अतिथि प्रोफ़ाइल बनाना चाहता है जो यह पहचान सके कि कब एक ही चीनी अतिथि विभिन्न संपत्तियों में ठहरता है। प्रत्येक संपत्ति का अपना WeChat Official Account है। उन्हें किस WeChat पहचानकर्ता का उपयोग करना चाहिए, और किस कॉन्फ़िगरेशन की आवश्यकता है?

संकेत: OpenID अकाउंट-विशिष्ट है। क्रॉस-अकाउंट पहचान के लिए डिज़ाइन किया गया एक अलग पहचानकर्ता है।

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

UnionID का उपयोग करें। OpenID प्रत्येक Official Account के अनुसार बदलता है, इसलिए एक ही अतिथि के पास 15 खातों में 15 अलग-अलग OpenID होंगे। UnionID एक स्थिर पहचानकर्ता है जो एक ही Open Platform अकाउंट से जुड़े सभी Official Accounts और ऐप्स में एक उपयोगकर्ता का प्रतिनिधित्व करता है। आवश्यक कॉन्फ़िगरेशन: सभी 15 Official Accounts को एक ही WeChat Open Platform अकाउंट से लिंक करें। एक बार लिंक होने के बाद, जब उपयोगकर्ता ने लिंक किए गए खातों में से कम से कम एक को अधिकृत किया हो, तो OAuth रिस्पॉन्स में UnionID वापस मिल जाता है। क्रॉस-प्रॉपर्टी प्रोफ़ाइल बनाने और लौटने वाले अतिथियों को पहचानने के लिए अतिथि CRM में प्राथमिक कुंजी के रूप में UnionID का उपयोग करें, चाहे वे किसी भी संपत्ति पर जाएं।

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

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

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

गाइड पढ़ें →

होटल गेस्ट WiFi प्रबंधन: PMS, पोर्टल और ब्रांड मानकों को एकीकृत करना

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

गाइड पढ़ें →

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

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

गाइड पढ़ें →