मुख्य मजकुराकडे जा
मराठी

WeChat Authentication ला Guest WiFi Captive Portals सोबत समाकलित (integrate) करणे

हे मार्गदर्शक WeChat OAuth 2.0 ऑथेंटिकेशनला एंटरप्राइझ guest WiFi captive portals मध्ये कसे समाकलित करावे हे स्पष्ट करते. यामध्ये ड्युअल-प्लॅटफॉर्म नोंदणी आवश्यकता, फर्स्ट-पार्टी डेटा कॅप्चरसाठी स्कोप निवड, RADIUS Change of Authorization द्वारे नेटवर्क अंमलबजावणी आणि GDPR आणि चीनच्या PIPL चे पालन समाविष्ट आहे. हॉस्पिटॅलिटी, रिटेल आणि इव्हेंट्समधील व्हेन्यू ऑपरेटर्सना मोठ्या प्रमाणावर WeChat लॉगिन guest wifi तैनात करण्यासाठी ठोस अंमलबजावणीच्या पायऱ्या, वास्तविक-जगातील केस स्टडीज आणि सुरक्षा बळकटीकरण मार्गदर्शन मिळेल.

📖 8 मिनिट वाचन📝 1,966 शब्द🔧 2 सोडवलेली उदाहरणे❓ 4 सराव प्रश्न📚 9 महत्वाच्या व्याख्या

हे मार्गदर्शक ऐका

पॉडकास्ट ट्रान्सक्रिप्ट पहा
कॅप्टिव्ह पोर्टल्ससाठी (CAPTIVE PORTALS) WECHAT OAUTH ऑथेंटिकेशन कसे कॉन्फिगर करावे एक Purple तांत्रिक माहितीपत्रक - साधारणपणे १० मिनिटे --- प्रस्तावना आणि संदर्भ (साधारणपणे १ मिनिट) स्वागत आहे. जर तुम्ही चीनी पर्यटकांना सेवा देणाऱ्या हॉटेल, रिटेल चेन, स्टेडियम किंवा कॉन्फरन्स सेंटरमधील गेस्ट WiFi साठी जबाबदार असाल, तर हे माहितीपत्रक तुमच्यासाठी आहे. Tencent च्या २०२४ च्या डेटा नुसार, WeChat चे मासिक १.३८ अब्ज सक्रिय युजर्स आहेत. यातील बहुतांश युजर्स चीनमध्ये आहेत, परंतु या प्लॅटफॉर्मचा आंतरराष्ट्रीय स्तरावरही लक्षणीय प्रभाव आहे - युनायटेड स्टेट्समध्ये ४० लाख युजर्स, मलेशियामध्ये १.२ कोटी आणि आग्नेय आशिया, युरोप आणि मध्य पूर्वेमध्ये ही संख्या सातत्याने वाढत आहे. जेव्हा एखादा चीनी पाहुणा तुमच्या WiFi शी कनेक्ट होतो आणि त्याला केवळ ईमेल, फेसबुक किंवा व्हाउचर कोड असलेला लॉगिन पेज दिसतो, तेव्हा त्यांना त्वरित अडचणीचा सामना करावा लागतो. त्यांच्या त्या डिव्हाइसवर स्थानिक ईमेल पत्ता सेट केलेला नसू शकतो. परंतु त्यांच्याकडे WeChat नक्कीच असते. त्यामुळे प्रश्न हा नाही की तुम्ही WeChat लॉगिन ऑफर केले पाहिजे की नाही - तर प्रश्न हा आहे की तुम्ही ते योग्यरित्या, सुरक्षितपणे आणि अशा प्रकारे कसे कॉन्फिगर करता ज्यामुळे तुम्हाला प्रत्यक्षात वापरता येईल असा फर्स्ट-पार्टी डेटा मिळेल. आज आपण याच विषयावर चर्चा करणार आहोत. आपण OAuth २.० फ्लो, तुम्हाला आवश्यक असणारे दोन प्लॅटफॉर्म रजिस्ट्रेशन्स, तुम्ही कोणता डेटा गोळा करता हे ठरवणारा स्कोप निर्णय, नेटवर्क-साइड एन्फोर्समेंट मेकॅनिझम आणि २०२६ मध्ये महत्त्वाचे असणारे अनुपालन (compliance) विचार या सर्व गोष्टी समजून घेणार आहोत. --- तांत्रिक सखोल विश्लेषण (साधारणपणे ५ मिनिटे) चला आर्किटेक्चरपासून सुरुवात करूया. एक Captive Portal अन-ऑथेंटिकेटेड डिव्हाइसवरून येणाऱ्या HTTP ट्रॅफिकला अडवतो आणि त्याला लॉगिन पेजवर रिडायरेक्ट करतो. ते लॉगिन पेज पोर्टल सर्व्हरवर होस्ट केलेले असते - मग ते ऑन-प्रिमाइसेस असो किंवा क्लाउडमध्ये. जेव्हा तुम्ही WeChat OAuth जोडता, तेव्हा तुम्ही त्या फ्लोमध्ये थर्ड-पार्टी आयडेंटिटी प्रोव्हाइडर समाविष्ट करत असता. याचा क्रम असा आहे. पाहुणा तुमच्या SSID शी कनेक्ट होतो. ॲक्सेस पॉइंट किंवा वायरलेस कंट्रोलरला समजते की डिव्हाइसचे कोणतेही ऑथेंटिकेटेड सेशन नाही आणि ते सर्व HTTP ट्रॅफिक तुमच्या Captive Portal URL कडे रिडायरेक्ट करते. पोर्टल पेज लोड होते आणि लॉगिनचे पर्याय दाखवते - ज्यामध्ये WeChat समाविष्ट असते. पाहुणा WeChat लॉगिनवर टॅप करतो. तुमचा पोर्टल सर्व्हर ब्राउझरला WeChat च्या ऑथरायझेशन एंडपॉइंटवर रिडायरेक्ट करतो, ज्यामध्ये तुमचा App ID, रिडायरेक्ट URI, कोडचा रिस्पॉन्स टाईप आणि स्कोप पाठवला जातो. WeChat संपूर्ण ऑथेंटिकेशन प्रक्रिया स्वतःच्या सर्व्हरवर हाताळते. जर पाहुणा त्याच्या ब्राउझरमध्ये आधीपासूनच WeChat मध्ये लॉग इन असेल, तर त्याला संमती स्क्रीन (consent screen) दिसते. जर ते WeChat इन-ॲप ब्राउझर वापरत असतील, तर snsapi बेस स्कोपसह हा अनुभव अगदी सहज आणि कोणताही संमती प्रॉम्प्ट न दाखवता पूर्ण होऊ शकतो. त्यानंतर WeChat तात्पुरत्या ऑथरायझेशन कोडसह तुमच्या पोर्टलच्या रिडायरेक्ट URI वर परत रिडायरेक्ट करते. तुमचा पोर्टल सर्व्हर तुमचा App ID, App Secret, कोड आणि ऑथरायझेशन कोडचा ग्रँट टाईप पाठवून त्या कोडच्या बदल्यात ॲक्सेस टोकन मिळवतो. WeChat एक ॲक्सेस टोकन, रिफ्रेश टोकन, युझरचा Open ID आणि मंजूर केलेला स्कोप परत पाठवते. जर तुम्ही snsapi userinfo स्कोपची विनंती केली असेल, तर तुम्ही युझरचे टोपणनाव (nickname), अवतार, लिंग आणि शहर मिळवण्यासाठी दुसरी API कॉल करू शकता.आता, दोन प्लॅटफॉर्म नोंदणी. याच ठिकाणी बहुतेक अंमलबजावणी चुकते. WeChat चे दोन स्वतंत्र डेव्हलपर प्लॅटफॉर्म आहेत. WeChat Open Platform हे वेबसाइट ॲप्लिकेशन्स आणि मोबाईल ॲप्स हाताळते. WeChat Official Accounts Platform हे पब्लिक अकाउंट्स हाताळते - ज्याची बहुतेक वेन्यूजला प्रत्यक्षात गरज असते. WeChat इन-ॲप ब्राउझरमधील पाहुण्यांना सेवा देणाऱ्या Captive Portal साठी, तुम्हाला Official Accounts Platform वर Service Account ची आवश्यकता आहे. Subscription Account काम करणार नाही - कारण त्यामध्ये OAuth वेब पेज ऑथरायझेशन परवानग्या नसतात. Service Account मध्ये त्या असतात, आणि ते snsapi base आणि snsapi userinfo या दोन्ही स्कोप्सना सपोर्ट करते. WeChat च्या बाहेरील मानक मोबाईल ब्राउझरवरून - Android वर Chrome, iOS वर Safari - ॲक्सेस केलेल्या Captive Portal साठी, तुम्हाला 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 टोपणनाव, प्रोफाईल पिक्चर, लिंग, भाषा सेटिंग आणि शहर रिटर्न करते. यासाठी स्पष्ट संमती स्क्रीन आवश्यक असते. बहुतेक युझर्स हे स्वीकारतात, परंतु यामध्ये थोडा अडथळा येतो. योग्य निवड तुमच्या युझ केसवर अवलंबून असते. पहिल्यांदा येणाऱ्या पाहुण्याच्या नोंदणीसाठी जिथे तुम्हाला प्रोफाईल तयार करायचे आहे, तिथे snsapi userinfo वापरा आणि तुमच्या पोर्टल पेजवर GDPR-सुसंगत संमती लेयरसह त्याची जोडी बनवा. आधीच संमती दिलेल्या आणि ज्यांचे प्रोफाईल तुमच्याकडे आधीपासूनच आहे अशा परत येणाऱ्या पाहुण्यासाठी, सायलेंट री-ऑथेंटिकेशनसाठी snsapi base वापरा. आता, नेटवर्क अंमलबजावणीची बाजू. OAuth टोकन मिळवणे हे ओळख सिद्ध करते, परंतु ते नेटवर्क स्वयंचलितपणे उघडत नाही. यशस्वी ऑथेंटिकेशनचे नेटवर्क ॲक्सेसमध्ये रूपांतर करण्यासाठी तुम्हाला एका यंत्रणेची आवश्यकता आहे. यासाठीचे दोन मानक दृष्टिकोन म्हणजे RFC 3576 मध्ये परिभाषित केलेले RADIUS Change of Authorisation (CoA), आणि 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 असो. वेन्यू ऑपरेटरला ते भाषांतर मॅन्युअली व्यवस्थापित करण्याची आवश्यकता नसते. --- अंमलबजावणीच्या शिफारसी आणि त्रुटी (अंदाजे २ मिनिटे) WeChat OAuth Captive Portal अंमलबजावणी अयशस्वी होण्यास कारणीभूत ठरणाऱ्या पाच गोष्टी मी तुम्हाला सांगतो. पहिली: रिडायरेक्ट URI विसंगती. तुम्ही प्लॅटफॉर्मवर नोंदणी केलेल्या अधिकृत डोमेनच्या विरूद्ध WeChat रिडायरेक्ट URI प्रमाणित करते. जर तुमचा पोर्टल सर्व्हर वेगळा सबडोमेन, वेगळा पाथ किंवा HTTPS ऐवजी HTTP वापरत असेल, तर OAuth फ्लो एरर 40029 - अवैध कोडसह अयशस्वी होतो. तुम्ही वापरत असलेल्या प्रत्येक डोमेन व्हेरिएंटची नोंदणी करा, ज्यामध्ये स्टेजिंग एन्व्हायरमेंट्सचा समावेश आहे. दुसरी: क्लायंट बाजूला App Secret. तुमचे App Secret कधीही क्लायंट-साइड JavaScript मध्ये दिसू नये. ते तुमच्या सर्व्हरवर असणे आवश्यक आहे. जर ते उघड झाले, तर कोणीही तुमच्या ॲप्लिकेशनचे सोंग घेऊ शकते आणि तुमच्या वतीने WeChat च्या API ला कॉल करू शकते. तिसरी: गहाळ CSRF संरक्षण. OAuth विनंतीमधील स्टेट पॅरामीटर विशेषतः क्रॉस-साइट रिक्वेस्ट फॉर्जरी रोखण्यासाठी अस्तित्वात आहे. एक क्रिप्टोग्राफिकली रँडम स्टेट व्हॅल्यू जनरेट करा, ती युझरच्या सेशनमध्ये स्टोअर करा आणि WeChat रिडायरेक्ट झाल्यावर ती प्रमाणित करा. हे वगळल्यास तुमच्या सिस्टीममध्ये खरी असुरक्षितता निर्माण होते. चौथी: इन-ॲप ब्राउझर डिटेक्शन गॅप. WeChat चा इन-ॲप ब्राउझर MicroMessenger समाविष्ट असलेली एक विशिष्ट युझर एजंट स्ट्रिंग सेट करतो. जर तुमच्या पोर्टलने हे शोधले नाही आणि योग्य OAuth फ्लो दाखवला नाही, तर युझर्सना खराब अनुभव येतो किंवा एरर येते. पाचवी: GDPR आणि PIPL संरेखन. तुम्ही युरोपियन अभ्यागतांना सेवा देत असल्यास, GDPR लागू होतो. तुम्ही चीनी अभ्यागतांना सेवा देत असल्यास, चीनचा वैयक्तिक माहिती संरक्षण कायदा - PIPL - लागू होतो. दोघांनाही प्रक्रियेसाठी कायदेशीर आधार, स्पष्ट उद्देश मर्यादा आणि डेटा मिनिमायझेशन आवश्यक आहे. snsapi userinfo पेक्षा डेटा मिनिमायझेशन तत्त्वांतर्गत snsapi base चे समर्थन करणे सोपे आहे. तुम्ही जे काही गोळा करता, त्याचा तुमचा कायदेशीर आधार आणि तुमचा धारणा कालावधी (retention period) दस्तऐवजीकरण करा. --- रॅपिड-फायर प्रश्न आणि उत्तरे (अंदाजे १ मिनिट) मी ईमेल आणि एसएमएस लॉगिन देखील ऑफर करणाऱ्या पोर्टलवर WeChat लॉगिन वापरू शकतो का? होय. Purple सह बहुतेक एंटरप्राइझ पोर्टल प्लॅटफॉर्म एकाच पोर्टल पेजवर एकाधिक प्रमाणीकरण पद्धतींना समर्थन देतात. WeChat OAuth हे iOS वर काम करते का? होय. iOS वरील Safari मधील WeChat लॉगिन QR कोड फ्लो किंवा रिडायरेक्ट फ्लोद्वारे काम करते. WeChat ॲप स्वतः प्रमाणीकरण हाताळते. WeChat चे API अनुपलब्ध असल्यास काय होईल? फॉलबॅक लागू करा. WeChat API कॉल टाईम आऊट झाल्यास किंवा एरर आल्यास, युझरला पर्यायी लॉगिन पद्धतीवर रिडायरेक्ट करा. मी परसिस्टंट कस्टमर आयडेंटिफायर म्हणून Open ID वापरू शकतो का? तुमच्या अधिकृत खात्यामध्ये (Official Account), होय. एकाधिक प्रॉपर्टीजमधील क्रॉस-अकाउंट आयडेंटिटी रिझोल्यूशनसाठी, त्याऐवजी UnionID वापरा. --- सारांश आणि पुढील पायऱ्या (अंदाजे १ मिनिट) थोडक्यात सांगायचे तर. Captive Portal साठी WeChat OAuth ऑथेंटिकेशन ही दोन-प्लॅटफॉर्म नोंदणी प्रक्रिया, स्कोपचा निर्णय, नेटवर्क अंमलबजावणीचे एकत्रीकरण आणि अनुपालन पुनरावलोकन आहे. या चार गोष्टी योग्य रीतीने करा आणि तुमच्याकडे एक अशी लॉगिन पद्धत असेल जी कोणत्याही पासवर्डच्या त्रासाशिवाय एक अब्जाहून अधिक संभाव्य अभ्यागतांना सेवा देईल. पुढील व्यावहारिक पावले: तुमचे अभ्यागत WeChat इन-अॅप ब्राउझरमध्ये पोर्टलवर येतात की मानक मोबाईल ब्राउझरमध्ये, हे निश्चित करा. स्कोप ठरवा - परत येणाऱ्या पाहुण्यांसाठी snsapi base, संमतीसह पहिल्यांदा नोंदणी करण्यासाठी snsapi userinfo. तुमचे नेटवर्क हार्डवेअर RADIUS CoA ला सपोर्ट करत असल्याची खात्री करा. GDPR आणि PIPL नुसार तुमच्या गोपनीयता सूचनेचे पुनरावलोकन करा. लाइव्ह जाण्यापूर्वी रिडायरेक्ट URI, स्टेट पॅरामीटर व्हॅलिडेशन आणि इन-अॅप ब्राउझर डिटेक्शनची चाचणी घ्या. जर तुम्हाला हे पाहायचे असेल की Purple एका व्यापक गेस्ट WiFi आणि अ‍ॅनालिटिक्स प्लॅटफॉर्मचा भाग म्हणून WeChat OAuth कसे हाताळते - जे २०२४ मध्ये ८०,००० हून अधिक ठिकाणांवर आणि ४४० दशलक्ष लॉगिनमध्ये वापरले गेले आहे - तर purple.ai ला भेट द्या किंवा तुमच्या अकाउंट टीमशी संपर्क साधा. ऐकल्याबद्दल धन्यवाद. --- स्क्रिप्ट समाप्त

header_image.png

कार्यकारी सारांश (Executive summary)

जेव्हा एखादा चिनी अभ्यागत तुमच्या एंटरप्राइझ नेटवर्कशी कनेक्ट होतो आणि त्याला केवळ ईमेल, Facebook किंवा व्हाउचर कोड देणारा Captive Portal दिसतो, तेव्हा तिथे तात्काळ अडथळा निर्माण होतो. Tencent च्या २०२४ च्या डेटाच्या मते, WeChat कडे १.३८ अब्ज मासिक सक्रिय वापरकर्ते आहेत. WeChat लॉगिन guest wifi क्षमता समाकलित करणे ही केवळ आदरातिथ्याची सोय नाही - तर या लोकसंख्येचा फर्स्ट-पार्टी डेटा कोणत्याही अडथळ्याशिवाय मिळवण्यासाठी ही एक तांत्रिक आवश्यकता आहे.

हे मार्गदर्शक Captive Portals मध्ये WeChat OAuth 2.0 प्रमाणीकरण (authentication) समाकलित करण्यासाठी तांत्रिक आर्किटेक्चरचे तपशील देते. हे मानक मोबाईल ब्राउझर आणि WeChat इन-अॅप ब्राउझर या दोन्हीला सपोर्ट करण्यासाठी आवश्यक असणाऱ्या ड्युअल-प्लॅटफॉर्म नोंदणीचे स्पष्टीकरण देते, डेटा संकलनासाठी snsapi_base आणि snsapi_userinfo स्कोपमधील तडजोडींचे मूल्यांकन करते आणि RADIUS Change of Authorization (CoA) किंवा MAC प्रमाणीकरण बायपास वापरून नेटवर्क प्रवेश कसा लागू करायचा हे स्पष्ट करते. यामध्ये Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet इन्फ्रास्ट्रक्चरवर मोठ्या प्रमाणावर हे तैनात करण्यासाठी आवश्यक असणारे सुरक्षा कॉन्फिगरेशन आणि अनुपालन कायदे - GDPR आणि चीनचे PIPL - देखील समाविष्ट आहेत.

तांत्रिक सखोल विश्लेषण: WeChat OAuth 2.0 आर्किटेक्चर

एक Captive Portal अप्रमाणित डिव्हाइसवरून येणारा HTTP ट्रॅफिक अडवतो आणि पोर्टल सर्व्हरवर होस्ट केलेल्या लॉगिन पेजवर रीडायरेक्ट करतो. WeChat प्रमाणीकरण जोडल्याने OAuth 2.0 प्रोटोकॉलचा वापर करून या फ्लोमध्ये थर्ड-पार्टी आयडेंटिटी प्रोव्हाइडर समाविष्ट होतो - हा तोच मानक प्रोटोकॉल आहे जो Google, Microsoft Entra ID आणि Okta द्वारे फेडरेटेड आयडेंटिटीसाठी वापरला जातो.

oauth_flow_diagram.png

प्रमाणीकरण प्रक्रिया खालीलप्रमाणे कार्य करते. अतिथी SSID शी कनेक्ट होतो. ॲक्सेस पॉईंट किंवा वायरलेस कंट्रोलर अप्रमाणित सत्र शोधतो आणि HTTP ट्रॅफिकला Captive Portal 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 मंजूर केले गेले असेल, तर सर्व्हर वापरकर्त्याचे टोपणनाव, अवतार, लिंग आणि शहर मिळवण्यासाठी दुसरा 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 डेटा मिनिमायझेशन तत्त्वांतर्गत, snsapi_base चे समर्थन करणे सोपे आहे.

snsapi_userinfo OpenID सोबत युझरचे टोपणनाव (nickname), प्रोफाईल पिक्चर, लिंग आणि शहर रिटर्न करते. यासाठी स्पष्ट संमती स्क्रीनची आवश्यकता असते. पहिल्यांदा येणाऱ्या पाहुण्यांच्या नोंदणीसाठी हे वापरा जिथे तुम्हाला प्रोफाईल तयार करायचे आहे, आणि तुमच्या पोर्टल पेजवर सुसंगत संमती लेयरसह ते जोडा.

मल्टि-प्रॉपर्टी डिप्लॉयमेंटसाठी UnionID

OpenID हा युझर आणि विशिष्ट Official Account च्या कॉम्बिनेशनसाठी युनिक असतो. २० प्रॉपर्टीज असलेल्या हॉटेल ग्रुपकडे, ज्यांच्या प्रत्येकाचे स्वतःचे Official Account आहे, त्यांना एकाच पाहुण्यासाठी २० वेगवेगळे OpenID दिसतील. UnionID यावर उपाय शोधतो. हा एकच आयडेंटिफायर आहे जो एकाच Open Platform अकाउंटशी लिंक केलेल्या सर्व Official Accounts आणि ॲप्समधील युझरचे प्रतिनिधित्व करतो. तुमचे Official Accounts तुमच्या Open Platform अकाउंटशी लिंक करा, आणि OAuth रिस्पॉन्समध्ये UnionID रिटर्न केला जाईल. हा क्रॉस-प्रॉपर्टी पाहुण्यांच्या ओळखीचा पाया आहे.

अंमलबजावणी मार्गदर्शक (Implementation guide)

नेटवर्क एन्फोर्समेंट मेकॅनिझम

OAuth टोकन मिळवणे ओळख सिद्ध करते. ते नेटवर्क उघडत नाही. ट्रॅफिकला परवानगी देण्यासाठी तुम्ही कंट्रोलरला सिग्नल देणे आवश्यक आहे.

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

MAC Authentication Bypass (MAB) RADIUS डेटाबेसमध्ये अधिकृत क्लायंट म्हणून डिव्हाइसचा MAC ॲड्रेस नोंदवतो. कंट्रोलर त्या MAC च्या आधारे ॲक्सेसला परवानगी देतो. MAB ची अंमलबजावणी करणे सोपे आहे परंतु ते अविश्वसनीय आहे: आधुनिक iOS आणि Android डिव्हाइसेस डीफॉल्टनुसार MAC ॲड्रेस रँडमाइज करतात, ज्यामुळे पुन्हा कनेक्ट करताना सेशन असोसिएशन खंडित होते.

Purple चे Guest WiFi प्लॅटफॉर्म हे ट्रान्सलेशन स्वयंचलित करते. WeChat OAuth पूर्ण झाल्यानंतर, Purple चे क्लाउड ओव्हरले संबंधित हार्डवेअरला योग्य CoA किंवा MAB सिग्नल पाठवते, ज्यामुळे मॅन्युअल VLAN कॉन्फिगरेशनची आवश्यकता उरत नाही.

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

तीन कॉन्फिगरेशन्स तडजोड न करण्यायोग्य आहेत.

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

इन-अॅप ब्राउझर डिटेक्शन

WeChat चा इन-अॅप ब्राउझर MicroMessenger समाविष्ट असलेली युझर एजंट स्ट्रिंग सेट करतो. तुमच्या पोर्टलने ही स्ट्रिंग शोधून काढली पाहिजे आणि त्यानुसार मार्ग निश्चित केला पाहिजे: इन-अॅप ब्राउझरसाठी ऑफिशियल अकाउंट फ्लो, तर स्टँडर्ड ब्राउझरसाठी ओपन प्लॅटफॉर्म QR कोड फ्लो. हे शोधण्यात अयशस्वी झाल्यास युझर एक्सपिरियन्स खराब होतो किंवा ऑथेंटिकेशन एरर येतात.

hotel_wechat_wifi.png

सर्वोत्तम पद्धती आणि अनुपालन

GDPR अनुपालन

तुम्ही युरोपियन अभ्यागतांना सेवा देत असल्यास किंवा युरोपमध्ये कार्यरत असल्यास, WeChat OAuth द्वारे तुम्ही गोळा करत असलेल्या डेटाला GDPR लागू होतो. तुम्ही डेटा प्रक्रियेसाठी कायदेशीर आधार स्थापित केला पाहिजे - सामान्यतः संमती किंवा कायदेशीर हितसंबंध. ऑथेंटिकेशनपूर्वी तुम्ही Captive Portal वर स्पष्ट गोपनीयता सूचना प्रदान करणे आवश्यक आहे. तुम्ही सब्जेक्ट ॲक्सेस विनंत्या आणि डेटा हटवण्याच्या विनंत्यांचा आदर केला पाहिजे. तपशीलवार अनुपालन फ्रेमवर्कसाठी, The Compliance Playbook: GDPR and Guest WiFi Data Privacy पहा.

PIPL अनुपालन

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

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

VLAN सेगमेंटेशनचा वापर करून तुमच्या कॉर्पोरेट नेटवर्कपासून गेस्ट WiFi ट्रॅफिक वेगळे करा. WeChat द्वारे ऑथेंटिकेट झालेले पाहुणे केवळ इंटरनेट ॲक्सेस असलेल्या समर्पित गेस्ट VLAN मध्येच गेले पाहिजेत - अंतर्गत सिस्टम्समध्ये त्यांना कोणताही प्रवेश नसावा. हे कार्डधारक डेटा एन्व्हायर्नमेंट आयसोलेशन आणि सामान्य एंटरप्राइझ सुरक्षा पद्धतीसाठीच्या PCI DSS आवश्यकतांशी सुसंगत आहे. सेगमेंटेशन आर्किटेक्चरबद्दल अधिक माहितीसाठी, Bandwidth Management: A Practical Guide for 2026 पहा.

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

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

वास्तविक-जगातील केस स्टडीज

हॉस्पिटॅलिटी: लक्झरी हॉटेल ग्रुप

लंडन मधील एका ४०० खोल्यांच्या लक्झरी हॉटेलमध्ये मुख्य भूप्रदेश चीनमधील पाहुण्यांचे प्रमाण लक्षणीय आहे. त्यांच्या सध्याच्या Captive Portal ला ईमेल पत्ता आणि SMS पडताळणीची आवश्यकता होती. चिनी मोबाईल क्रमांकांवर युरोपियन प्रदात्यांकडून वारंवार SMS प्राप्त होत नाहीत आणि अनेक पाहुण्यांच्या डिव्हाइसवर स्थानिक ईमेल कॉन्फिगर केलेला नसतो. याचा परिणाम असा झाला की पोर्टलवर ड्रॉप-ऑफ दर ६०% पर्यंत पोहोचला.

हॉटेलने अधिकृत खाते प्लॅटफॉर्मवर (Official Accounts Platform) एक सर्व्हिस अकाउंट आणि ओपन प्लॅटफॉर्मवर (Open Platform) एक वेबसाइट ॲप्लिकेशन नोंदणीकृत केले. पोर्टल MicroMessenger युझर एजंट शोधून काढते आणि इन-ॲप ब्राउझर वापरकर्त्यांसाठी snsapi_base ट्रिगर करते - ज्यामुळे कोणत्याही संमती स्क्रीनशिवाय तीन सेकंदांपेक्षा कमी वेळात ते कनेक्ट होतात. Chrome किंवा Safari द्वारे येणाऱ्या पाहुण्यांना QR कोड दिसतो. त्यानंतरच्या मुक्कामादरम्यान, तोच OpenID ओळखला जातो आणि पाहुण्यांचे सायलेंटली पुन्हा प्रमाणीकरण केले जाते. हॉटेलचे CRM परत आलेल्या भेटीची नोंद करते, ज्यामुळे आगमनापूर्वीच्या लक्ष्यित संवादांना मदत होते. हॉस्पिटॅलिटी वातावरणात WiFi तैनात करण्याबद्दल अधिक माहितीसाठी, Hospitality पहा.

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

एका मोठ्या रिटेल मॉलला भाडेकरूंचे मिश्रण आणि विपणन निर्णय सुलभ करण्यासाठी चिनी खरेदीदारांकडून लोकसंख्याशास्त्रीय (demographic) डेटा मिळवायचा आहे. त्यांना मूळ शहर, लिंग आणि भेटीची वारंवारता हवी आहे. snsapi_base अपुरे आहे - त्यांना snsapi_userinfo ची आवश्यकता आहे. पोर्टल संपूर्ण userinfo स्कोपची विनंती करते. पाहुण्यांना WeChat संमती स्क्रीन दिसते आणि ते Allow वर टॅप करतात. मॉलचे ॲनालिटिक्स प्लॅटफॉर्म, जे Purple च्या WiFi Analytics शी समाकलित आहे, त्यांना सत्यापित लोकसंख्याशास्त्रीय डेटाचा प्रवाह प्राप्त होतो. शनिवारच्या दुपारी, ४०% WiFi वापरकर्ते एका विशिष्ट प्रदेशातील असतात. तो डेटा थेट पॉप-अप इव्हेंटसाठी कोणत्या ब्रँड्सशी संपर्क साधायचा हे ठरवण्यास मदत करतो. रिटेल WiFi तैनातीबद्दल अधिक माहितीसाठी, Retail पहा.

त्रुटी निवारण आणि जोखीम कमी करणे

WeChat OAuth Captive Portal तैनातीमधील पाच सर्वात सामान्य अपयशाचे प्रकार खालीलप्रमाणे आहेत.

Redirect URI विसंगती (त्रुटी 40029). WeChat नोंदणीकृत डोमेनच्या विरूद्ध redirect URI सत्यापित करते. कोणताही सबडोमेन, पाथ किंवा प्रोटोकॉल विसंगती कोड एक्सचेंज अयशस्वी करते. स्टेजिंग वातावरणासह प्रत्येक व्हेरिएंटची नोंदणी करा.

AppSecret उघड होणे. क्लायंट-साइड कोडमध्ये AppSecret एम्बेड करणे ही सर्वात गंभीर सुरक्षा त्रुटी आहे. सर्व टोकन एक्सचेंज लॉजिक सर्व्हरवर हलवा.

CSRF संरक्षणाचा अभाव. state पॅरामीटर पडताळणी वगळल्याने पोर्टल क्रॉस-साइट रिक्वेस्ट फॉर्जरीसाठी असुरक्षित राहते. प्रति सत्र एक क्रिप्टोग्राफिकली रँडम व्हॅल्यू जनरेट करा आणि कॉलबॅकवर ती सत्यापित करा.

इन-ॲप ब्राउझर शोधण्यात अपयश. युझर एजंटमध्ये MicroMessenger न शोधल्यास इन-ॲप ब्राउझर वापरकर्त्यांना चुकीचा OAuth फ्लो दाखवला जातो, ज्यामुळे त्रुटी निर्माण होतात. MAC address randomisation breaking MAB sessions. आधुनिक मोबाईल ऑपरेटिंग सिस्टीम्स MAC addresses रँडमाइज (यादृच्छिक) करतात. MAB-आधारित अंमलबजावणी वापरणारे अतिथी पुन्हा कनेक्ट झाल्यावर त्यांचे सेशन गमावतील. विश्वसनीय सेशन व्यवस्थापनासाठी RADIUS CoA वर अपग्रेड करा. सुरक्षित WiFi कॉन्फिगरेशनच्या मार्गदर्शनासाठी, What Is Secure WiFi: Essential Guide for Business 2026 पहा.

ROI आणि व्यावसायिक प्रभाव

WeChat लॉगिन guest wifi कार्यक्षमता लागू करण्याचे तीन मोजता येण्याजोगे प्रभाव आहेत.

ऑथेंटिकेशन दरांमध्ये वाढ. SMS पडताळणी अयशस्वी होण्याचा टप्पा आणि ईमेल प्रविष्ट करण्याची आवश्यकता काढून टाकल्याने यशस्वीरित्या कनेक्ट होणाऱ्या चिनी पर्यटकांची टक्केवारी वाढते. WeChat सपोर्ट नसलेल्या पोर्टल्ससाठी ६०% ड्रॉप-ऑफ दर हा एक वास्तववादी बेसलाइन आहे.

फर्स्ट-पार्टी डेटा गुणवत्ता. WeChat-ऑथेंटिकेटेड प्रोफाईल्समध्ये सत्यापित OpenID समाविष्ट असतो आणि snsapi_userinfo सह थेट सोशल प्लॅटफॉर्मवरून घेतलेले डेमोग्राफिक गुणधर्म मिळतात. हा डेटा थर्ड-पार्टी कुकीजवर अवलंबून न राहता लक्ष्यित मार्केटिंग चालवण्यासाठी ॲनालिटिक्स प्लॅटफॉर्ममध्ये फीड केला जातो.

सपोर्ट ओव्हरहेडमध्ये घट. घर्षणरहित लॉगिनमुळे आंतरराष्ट्रीय अतिथींकडून कनेक्शनच्या समस्यांचे निवारण करण्यासाठी फ्रंट-डेस्क आणि आयटी सपोर्टला येणारे कॉल्स कमी होतात.

Purple ८०,०००+ पेक्षा जास्त ठिकाणी कार्यरत आहे आणि २०२४ मध्ये ४४० दशलक्ष लॉगिन प्रक्रियेतून गेले आहेत (Purple अंतर्गत डेटा). हा प्लॅटफॉर्म ISO 27001 प्रमाणित, GDPR आणि CCPA सुसंगत आहे आणि ९९.९९९% अपटाइम राखतो. Retail आणि Hospitality मधील ठिकाणांसाठी, WeChat ऑथेंटिकेशन नेटवर्कला एका खर्च केंद्रातून एका विश्वसनीय फर्स्ट-पार्टी डेटा संपादन चॅनेलमध्ये रूपांतरित करते.

महत्वाच्या व्याख्या

Captive portal

एक वेब पेज जे अनधिकृत डिव्हाइसवरील HTTP ट्रॅफिक अडवते आणि नेटवर्क ॲक्सेस देण्यापूर्वी वापरकर्त्याला त्याच्याशी संवाद साधणे आवश्यक करते.

मुख्य इंटरफेस जिथे पाहुण्यांना WeChat लॉगिनचा पर्याय दाखवला जातो. पोर्टल सर्व्हर या पेजचे यजमानपद भूषवतो आणि OAuth प्रवाहाचे संचालन करतो.

OAuth 2.0

एक उद्योग-मानक ऑथरायझेशन प्रोटोकॉल (RFC 6749) जो वापरकर्त्याच्या वतीने थर्ड-पार्टी ॲप्लिकेशनला HTTP सेवेमध्ये मर्यादित प्रवेश मिळवण्याची परवानगी देतो.

वापरकर्त्याची क्रेडेन्शियल्स उघड न करता पोर्टल सर्व्हरकडे ऑथेंटिकेशन टोकन्स पाठवण्यासाठी WeChat वापरत असलेला मूळ प्रोटोकॉल. Microsoft Entra ID, Okta आणि Google Workspace द्वारे वापरला जाणारा हाच प्रोटोकॉल आहे.

OpenID

विशिष्ट अधिकृत खात्यासाठी (Official Account) विशिष्ट WeChat वापरकर्त्याला नियुक्त केलेला एक युनिक अल्फान्यूमेरिक आयडेंटिफायर.

WiFi ॲनालिटिक्स डेटाबेसमध्ये परत येणाऱ्या पाहुण्यांची ओळख पटवण्यासाठी प्राथमिक की म्हणून वापरले जाते. प्रत्येक अधिकृत खात्यानुसार (Official Account) बदलते - क्रॉस-प्रॉपर्टी ओळखीसाठी UnionID वापरा.

UnionID

एकच WeChat आयडेंटिफायर जो एकाच ओपन प्लॅटफॉर्म खात्याशी लिंक केलेल्या सर्व अधिकृत खात्यांमध्ये (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 व्याप्ती (scope) जी केवळ वापरकर्त्याचा OpenID परत करते आणि वापरकर्त्याकडून कोणत्याही संमतीची (consent) आवश्यकता नसते.

परत येणाऱ्या पाहुण्यांच्या पुन्हा-ऑथेंटिकेशनसाठी शिफारस केलेली व्याप्ती (scope). GDPR आणि PIPL डेटा मिनिमायझेशन तत्त्वांतर्गत याचे समर्थन करणे सोपे आहे.

snsapi_userinfo

एक WeChat OAuth व्याप्ती (scope) जी वापरकर्त्याचा OpenID, टोपणनाव, अवतार, लिंग आणि शहर परत करते आणि यासाठी स्पष्ट संमती स्क्रीनची आवश्यकता असते.

पहिल्यांदा येणाऱ्या पाहुण्यांच्या नोंदणीसाठी वापरले जाते जिथे ॲनालिटिक्ससाठी डेमोग्राफिक डेटा आवश्यक असतो. GDPR आणि PIPL अंतर्गत दस्तऐवजीकरण केलेल्या कायदेशीर आधाराची आवश्यकता असते.

PIPL (Personal Information Protection Law)

चीनचा सर्वसमावेशक डेटा गोपनीयता कायदा, नोव्हेंबर २०२१ पासून लागू, जो चीनमध्ये असलेल्या नैसर्गिक व्यक्तींच्या वैयक्तिक माहितीच्या प्रक्रियेचे नियमन करतो.

जेव्हा ठिकाणे WeChat OAuth द्वारे चीनी नागरिकांच्या डेटावर प्रक्रिया करतात तेव्हा लागू होते. स्पष्ट संमती, उद्देश मर्यादा, डेटा मिनिमायझेशन आणि डेटा हटवण्याची यंत्रणा आवश्यक आहे.

AppSecret

ॲप्लिकेशन नोंदणीदरम्यान WeChat द्वारे जारी केलेली एक गोपनीय क्रिप्टोग्राफिक की, जी पोर्टल सर्व्हरवरील API कॉल्स ऑथेंटिकेट करण्यासाठी वापरली जाते.

केवळ सर्व्हरच्या बाजूला सुरक्षितपणे साठवले जाणे आवश्यक आहे. क्लायंट-साइड JavaScript मध्ये उघड झाल्यास हल्लेखोर ॲप्लिकेशनचे सोंग घेऊ शकतात आणि दुर्भावनायुक्त हेतूने WeChat APIs कॉल करू शकतात.

सोडवलेली उदाहरणे

लंडनमधील एका ४०० खोल्यांच्या लक्झरी हॉटेलमध्ये मुख्य भूप्रदेश चीनमधील पाहुण्यांमध्ये ६०% पोर्टल ड्रॉप-ऑफ दर आहे. सध्याच्या पोर्टलसाठी ईमेल आणि SMS पडताळणी आवश्यक आहे. IT डायरेक्टरला GDPR चे पालन आणि नेटवर्क सुरक्षा राखून WeChat ऑथेंटिकेशन लागू करणे आवश्यक आहे.

पायरी १: WeChat Official Accounts Platform (mp.weixin.qq.com) वर सर्व्हिस अकाउंट आणि WeChat Open Platform (open.weixin.qq.com) वर वेबसाइट ॲप्लिकेशनची नोंदणी करा. पायरी २: MicroMessenger युझर एजंट स्ट्रिंग शोधण्यासाठी पोर्टल कॉन्फिगर करा. आढळल्यास, सायलेंट ऑथेंटिकेशनसाठी snsapi_base OAuth फ्लो ट्रिगर करा. न आढळल्यास, QR कोड फ्लो सादर करा. पायरी ३: WeChat लॉगिन बटण सक्रिय होण्यापूर्वी पोर्टल पेजवर GDPR-सुसंगत गोपनीयता सूचना आणि संमती चेकबॉक्स जोडा. सूचनेमध्ये हे नमूद केले पाहिजे: गोळा केलेला डेटा (केवळ OpenID), उद्देश (guest WiFi ॲक्सेस आणि रिटर्न व्हिजिट ओळखणे), आणि धारणा कालावधी. पायरी ४: यशस्वी OAuth टोकन एक्सचेंज नंतर, पोर्टल सर्व्हर Cisco Meraki कंट्रोलरला RADIUS CoA विनंती पाठवतो, ज्यामुळे गेस्ट डिव्हाइस प्री-ऑथ VLAN मधून सेगमेंट केलेल्या गेस्ट VLAN मध्ये हलवले जाते. पायरी ५: गेस्ट डेटाबेसमध्ये डिव्हाइस MAC ॲड्रेसच्या विरूद्ध OpenID स्टोअर करा. त्यानंतरच्या भेटींवर, परत येणारा OpenID सायलेंट री-ऑथेंटिकेशन ट्रिगर करतो.

परीक्षकाचे भाष्य: हा दृष्टिकोन तांत्रिक आणि अनुपालन दोन्ही आवश्यकतांना योग्यरित्या संबोधित करतो. snsapi_base चा वापर GDPR डेटा मिनिमायझेशन तत्त्वांशी सुसंगत आहे, ज्यामुळे SMS पडताळणी अयशस्वी होण्याचा बिंदू काढून टाकताना कायदेशीर धोका कमी होतो. RADIUS CoA सुरक्षित, स्वयंचलित नेटवर्क विभाजन सुनिश्चित करते. संमती चेकबॉक्स दस्तऐवजीकरण केलेल्या कायदेशीर आधारासाठी GDPR आवश्यकता पूर्ण करतो. मुख्य निर्णय snsapi_userinfo ऐवजी snsapi_base चा आहे - हॉटेलला या वापराच्या केससाठी डेमोग्राफिक डेटाची आवश्यकता नाही, म्हणून तो गोळा केल्याने अनावश्यक अनुपालन दायित्वे निर्माण होतील.

एका रिटेल मॉलला त्यांच्या ॲनालिटिक्स प्लॅटफॉर्ममध्ये फीड करण्यासाठी guest WiFi द्वारे चीनी खरेदीदारांकडून लिंग आणि शहर डेटा कॅप्चर करायचा आहे. ते सध्या HPE Aruba हार्डवेअरवर चालणाऱ्या त्यांच्या विद्यमान पोर्टलसाठी MAC Authentication Bypass वापरतात.

पायरी १: WeChat Official Accounts Platform वर सर्व्हिस अकाउंटची नोंदणी करा. पायरी २: लिंग आणि शहर मिळवण्यासाठी snsapi_userinfo स्कोप वापरण्यासाठी पोर्टल कॉन्फिगर करा. पायरी ३: मूल्य देवाणघेवाण स्पष्ट करणारी एक स्पष्ट संमती स्क्रीन जोडा: प्रोफाइल डेटा ॲक्सेसच्या बदल्यात विनामूल्य WiFi. GDPR आणि PIPL दोन्ही अंतर्गत संमती स्पष्ट आणि तपशीलवार असणे आवश्यक आहे. पायरी ४: ऑथेंटिकेशननंतर, पोर्टल सर्व्हर RADIUS डेटाबेसमध्ये डिव्हाइसचा MAC ॲड्रेस नोंदवतो. HPE Aruba कंट्रोलर MAB द्वारे प्रवेशास अनुमती देतो. पायरी ५: डेटा प्रोसेसिंग रजिस्टरमध्ये कायदेशीर आधार (संमती), उद्देश (व्हेन्यू ॲनालिटिक्स आणि मार्केटिंग), आणि धारणा कालावधी (२४ महिने) दस्तऐवज करा. डेटा हटवण्याची यंत्रणा प्रदान करा.

परीक्षकाचे भाष्य: snsapi_userinfo स्कोप आवश्यक डेमोग्राफिक डेटा योग्यरित्या मिळवतो. तथापि, MAB वर अवलंबून राहण्यामुळे एक महत्त्वपूर्ण ऑपरेशनल धोका निर्माण होतो: iOS 14+ आणि Android 10+ डीफॉल्टनुसार MAC ॲड्रेस यादृच्छिक (randomise) करतात, ज्याचा अर्थ असा आहे की पाहुणे पुन्हा कनेक्ट केल्यावर त्यांचे ऑथेंटिकेटेड सेशन गमावतील आणि त्यांना पुन्हा ऑथेंटिकेट करण्यास भाग पाडले जाईल. मॉलने याचे निराकरण करण्यासाठी HPE Aruba वर RADIUS CoA वर स्थलांतरित करण्याची योजना आखली पाहिजे. PIPL अनुपालन दस्तऐवजीकरण पर्यायी नाही - व्हेन्यू कुठेही असले तरीही, चीनी नागरिकांच्या डेटावर प्रक्रिया करण्यासाठी ही कायदेशीर आवश्यकता आहे.

सराव प्रश्न

Q1. तुम्ही एका स्टेडियममध्ये Captive Portal तैनात करत आहात. ज्यांनी आधी ऑथेंटिकेट केले आहे अशा परत येणाऱ्या सीझन तिकीट धारकांनी पुढील भेटींमध्ये लॉगिन स्क्रीन न पाहता आपोआप कनेक्ट व्हावे अशी तुमची इच्छा आहे. री-ऑथेंटिकेशन प्रवाहासाठी तुम्ही कोणते WeChat OAuth scope लागू केले पाहिजे आणि का?

टीप: कोणती व्याप्ती (scope) प्रत्येक भेटीदरम्यान वापरकर्त्याला संमती न विचारता सायलेंट ऑथेंटिकेशनची परवानगी देते याचा विचार करा.

नमुना उत्तर पहा

snsapi_base वापरा. ही व्याप्ती (scope) केवळ वापरकर्त्याचा OpenID परत करते आणि यासाठी कोणत्याही संमतीच्या प्रॉम्प्टची आवश्यकता नसते, ज्यामुळे सायलेंट री-ऑथेंटिकेशन सक्षम होते. पहिल्या भेटीदरम्यान, तुम्ही चाहत्याच्या प्रोफाइलमध्ये OpenID स्टोअर करता. पुढील भेटींवर, पोर्टल snsapi_base द्वारे परत येणारा OpenID शोधते, जुळणीची पुष्टी करते आणि प्रवेश मंजूर करण्यासाठी RADIUS CoA जारी करते - हे सर्व चाहत्याला लॉगिन स्क्रीन न दाखवता होते. हे GDPR डेटा मिनिमायझेशन तत्त्वांशी देखील सुसंगत आहे, कारण तुम्ही ऑथेंटिकेशन कार्यासाठी आवश्यक असलेल्या डेटाव्यतिरिक्त अतिरिक्त डेटा गोळा करत नाही.

Q2. चाचणी दरम्यान, तुमचे पोर्टल यशस्वीरित्या WeChat वर रिडायरेक्ट होते, वापरकर्ता संमती देतो आणि WeChat पुन्हा तुमच्या पोर्टलवर रिडायरेक्ट करते. तथापि, पोर्टल सर्व्हर लॉग्स OAuth त्रुटी 40029 (अवैध कोड) दर्शवतात. सर्वात संभाव्य कॉन्फिगरेशन त्रुटी कोणती आहे आणि तुम्ही ती कशी सोडवाल?

टीप: WeChat ज्या गंतव्यस्थानावर (destination) ऑथरायझेशन कोड पाठवते, त्याची नोंदणीकृत सूचीसह काटेकोरपणे पडताळणी करते.

नमुना उत्तर पहा

सर्वात संभाव्य कारण म्हणजे रिडायरेक्ट URI विसंगती (mismatch). WeChat प्लॅटफॉर्मवर नोंदणीकृत अधिकृत डोमेनसह OAuth विनंतीमधील रिडायरेक्ट URI ची पडताळणी करते. जर पोर्टल सर्व्हर वेगळा सबडोमेन, वेगळा पाथ किंवा HTTPS ऐवजी HTTP वापरत असेल, तर कोड एक्सचेंज त्रुटी 40029 सह अपयशी ठरते. उपाय: WeChat डेव्हलपर प्लॅटफॉर्मवर लॉग इन करा, तुमच्या सर्व्हिस अकाउंट किंवा वेबसाइट ॲप्लिकेशन सेटिंग्जवर जा आणि तुम्ही वापरत असलेले प्रत्येक रिडायरेक्ट URI व्हेरिएंट जोडा - ज्यामध्ये स्टेजिंग सबडोमेन, वेगवेगळे पाथ आणि HTTPS आवृत्त्या समाविष्ट आहेत. तुमच्या OAuth विनंतीमधील redirect_uri पॅरामीटर नोंदणीकृत URI पैकी एकाशी तंतोतंत जुळत असल्याची खात्री करा, ज्यामध्ये URL एन्कोडिंग समाविष्ट आहे.

Q3. एक IT व्यवस्थापक थेट क्लायंट ब्राउझरमधून टोकन एक्सचेंज प्रक्रियेचा वेग वाढवण्यासाठी Captive Portal च्या फ्रंट-एंड JavaScript मध्ये WeChat AppSecret एम्बेड करण्याचा प्रस्ताव देतो. तुम्ही हा प्रस्ताव का नाकारला पाहिजे आणि योग्य आर्किटेक्चर काय आहे?

टीप: सार्वजनिकरित्या प्रवेश करण्यायोग्य कोडमध्ये क्रिप्टोग्राफिक की उघड करण्याच्या सुरक्षा परिणामांचा विचार करा.

नमुना उत्तर पहा

हा प्रस्ताव नाकारा. AppSecret ही एक गोपनीय क्रिप्टोग्राफिक की आहे. क्लायंट-साइड JavaScript मध्ये ती एम्बेड केल्याने ती पेज सोर्स पाहणाऱ्या किंवा नेटवर्क ट्रॅफिक दरम्यान अडवणाऱ्या कोणालाही उघडी पडते. एखादा हल्ला करणारा AppSecret मिळवू शकतो आणि ॲप्लिकेशनचे सोंग घेऊन, वेन्यूच्या वतीने WeChat API कॉल करू शकतो, वापरकर्त्याच्या डेटामध्ये प्रवेश करू शकतो आणि संपूर्ण अधिकृत खाते धोक्यात आणू शकतो. योग्य आर्किटेक्चर: क्लायंट-साइड पोर्टल पेजला WeChat कडून ऑथरायझेशन कोड मिळतो आणि तो सर्व्हर-साइड API कॉलद्वारे पोर्टल सर्व्हरकडे पाठवतो. पोर्टल सर्व्हर सुरक्षित एन्व्हायर्नमेंट व्हेरिएबलमध्ये AppSecret ठेवतो आणि WeChat च्या API सह टोकन एक्सचेंज करतो. AppSecret सर्व्हर कधीही सोडत नाही.

Q4. युरोपमधील 15 प्रॉपर्टीज असलेल्या एका हॉटेल समूहाला एक युनिफाइड गेस्ट प्रोफाइल तयार करायचे आहे, जेणेकरून तोच चीनी पाहुणा वेगवेगळ्या प्रॉपर्टीजमध्ये राहतो तेव्हा त्याची ओळख पटेल. प्रत्येक प्रॉपर्टीचे स्वतःचे WeChat अधिकृत खाते आहे. त्यांनी कोणते WeChat आयडेंटिफायर वापरावे आणि कोणते कॉन्फिगरेशन आवश्यक आहे?

टीप: OpenID हे खाते-विशिष्ट (account-specific) असते. क्रॉस-अकाउंट ओळखीसाठी डिझाइन केलेले एक वेगळे आयडेंटिफायर आहे.

नमुना उत्तर पहा

UnionID वापरा. प्रत्येक अधिकृत खात्यानुसार OpenID बदलतो, त्यामुळे एकाच पाहुण्याचे 15 खात्यांमध्ये 15 वेगवेगळे OpenID असतील. UnionID हे एक स्थिर आयडेंटिफायर आहे जे एकाच ओपन प्लॅटफॉर्म खात्याशी लिंक केलेल्या सर्व अधिकृत खात्यांवर आणि ॲप्सवर वापरकर्त्याचे प्रतिनिधित्व करते. आवश्यक कॉन्फिगरेशन: सर्व 15 अधिकृत खाती एकाच WeChat ओपन प्लॅटफॉर्म खात्याशी लिंक करा. एकदा लिंक केल्यावर, वापरकर्त्याने लिंक केलेल्या खात्यांपैकी किमान एका खात्याला अधिकृत केले की OAuth प्रतिसादात UnionID परत केला जातो. क्रॉस-प्रॉपर्टी प्रोफाइल तयार करण्यासाठी आणि पाहुणे कोणत्या प्रॉपर्टीला भेट देतात याकडे दुर्लक्ष करून परत येणाऱ्या पाहुण्यांना ओळखण्यासाठी गेस्ट CRM मध्ये प्राथमिक की (primary key) म्हणून UnionID वापरा.

या मालिकेमध्ये पुढे वाचा

Starlink वर Captive Portal कसे सेट करावे: दुर्गम आणि सागरी ठिकाणांसाठी एक मार्गदर्शिका

ही मार्गदर्शिका मूळ Starlink हार्डवेअरला बायपास कसे करावे आणि एंटरप्राइझ राउटिंग उपकरणांचा वापर करून क्लाउड-व्यवस्थापित captive portal कसे समाकलित करावे याबद्दल तपशीलवार माहिती देते. तुम्ही CGNAT मर्यादांवर मात कशी करावी, VLAN विभाजन कसे लागू करावे, सॅटेलाइट बँडविड्थ मर्यादा कशा व्यवस्थापित कराव्यात आणि नियामक अनुपालन कसे सुनिश्चित करावे हे शिकाल.

मार्गदर्शिका वाचा →

Captive Portal सर्वोत्तम पद्धती: उच्च रूपांतरण आणि अनुपालनासाठी डिझाइन

हे तांत्रिक मार्गदर्शक IT व्यवस्थापक, नेटवर्क आर्किटेक्ट्स आणि वेन्यू ऑपरेशन्स डायरेक्टर्सना नेटवर्क सुरक्षा आणि उच्च युझर रूपांतरण यांचा समतोल राखणारे captive portals तैनात करण्यासाठी एक संपूर्ण ब्ल्यूप्रिंट प्रदान करते. यामध्ये VLAN विभागणी आणि RADIUS प्रमाणीकरणापासून ते GDPR-सुसंगत संमती डिझाइन आणि प्रमाणीकरण पद्धत निवडीपर्यंतच्या संपूर्ण आर्किटेक्चरचा समावेश आहे. २०२४ मधील ८०,०००+ वेन्यू आणि ४४० दशलक्ष लॉगइन्सवरील Purple च्या ऑपरेशनल अनुभवातून घेतलेली, प्रत्येक शिफारस प्रत्यक्ष उपयोजन (deployment) डेटावर आधारित आहे.

मार्गदर्शिका वाचा →

कमाल नेटवर्क सुरक्षा आणि युझर कन्व्हर्जनसाठी Captive Portals कसे ऑप्टिमाइझ करावे

हे मार्गदर्शक एंटरप्राइझ ठिकाणांवर captive portals ऑप्टिमाइझ करण्यासाठी संपूर्ण तांत्रिक ब्ल्यूप्रिंट प्रदान करते, ज्यामध्ये नेटवर्क सेगमेंटेशन आर्किटेक्चर, ऑथेंटिकेशन पद्धतीची निवड, GDPR-सुसंगत संमती डिझाइन आणि कन्व्हर्जन ऑप्टिमायझेशन समाविष्ट आहे. हे हॉटेल्स, रिटेल चेन्स, स्टेडियम आणि सार्वजनिक क्षेत्रातील संस्थांमधील आयटी मॅनेजर्स, नेटवर्क आर्किटेक्ट्स आणि CTOs साठी लिहिले गेले आहे ज्यांना नेटवर्क सुरक्षा आणि फर्स्ट-पार्टी डेटा कॅप्चर यामध्ये समतोल राखायचा आहे. Purple हे २०२४ मध्ये ४४ कोटींहून अधिक लॉगिनसह ८०,०००+ पेक्षा जास्त ठिकाणी captive portal इन्फ्रास्ट्रक्चर चालवते आणि येथील फ्रेमवर्क तो ऑपरेशनल अनुभव दर्शवतात.

मार्गदर्शिका वाचा →