WiFi के लिए कैप्टिव पोर्टल: यह कैसे काम करता है और किसे इसकी आवश्यकता है
जानें कि WiFi के लिए कैप्टिव पोर्टल क्या है, स्थान इसका उपयोग कैसे करते हैं, कौन से सहमति नियम लागू होते हैं, और कौन से एकीकरण विकल्प आपके नेटवर्क के अनुकूल हैं।
यदि कोई गेस्ट आपके WiFi से जुड़ सकता है और तुरंत ब्राउज़ कर सकता है, तो वास्तव में उन्होंने किस बात से सहमति जताई, और आपने उनके बारे में क्या सीखा? यह वही अंतर है जिसे WiFi के लिए एक कैप्टिव पोर्टल भरता है, लेकिन केवल तभी जब आप तीन ऐसे कार्यों को अलग करते हैं जो अक्सर एक ही स्क्रीन में बंडल किए जाते हैं। एक कार्य नेटवर्क एक्सेस को नियंत्रित करता है। दूसरा आपकी उपयोग की शर्तों की स्वीकृति दर्ज करता है। तीसरा मार्केटिंग सहमति मांगता है, और यह अन्य दो के समान नहीं है।
एक फ्रंट डेस्क किसी को अंदर आने दे सकता है, घर के नियम समझा सकता है, और उन्हें मेलिंग सूची में शामिल होने के लिए आमंत्रित कर सकता है। वे आपस में जुड़े हुए हैं, लेकिन वे एक ही निर्णय नहीं हैं। जब स्थान उन्हें एक ही टिक बॉक्स के रूप में देखते हैं, तो अतिथि भ्रमित हो जाते हैं, सहमति कमजोर हो जाती है, और कभी भी ब्राउज़र न खोलने वाले डिवाइस आगे निकल सकते हैं या अटक सकते हैं।
विषय सूची
- कैप्टिव पोर्टल चरण-दर-चरण कैसे काम करता है
- स्थान कैप्टिव पोर्टल का उपयोग कहाँ करते हैं
- अतिथि डेटा, सहमति और क्या मांगना है
- प्रयास और डेटा के आधार पर लॉगिन विधियों की तुलना
- कैप्टिव पोर्टल क्यों विफल होते हैं और इसे कैसे रोकें
- आपके मौजूदा नेटवर्क के साथ एकीकरण विकल्प
- वह पोर्टल सेटअप चुनें जिसकी आपके स्थान को आवश्यकता है
कैप्टिव पोर्टल चरण-दर-चरण कैसे काम करता है
होटल रिसेप्शन के बारे में सोचें। कमरे की चाबी लेने से पहले हर मेहमान डेस्क से होकर गुजरता है, और पोर्टल WiFi से जुड़ने और इंटरनेट तक पहुंचने के बीच उसी तरह काम करता है। मेहमान पहले नेटवर्क से जुड़ता है, लेकिन केवल वही कनेक्शन अप्रतिबंधित ब्राऊज़िंग की अनुमति नहीं देता है।
मान लीजिए कि कैफे में कोई अतिथि आपके नेटवर्क नाम पर टैप करता है। उसका फोन किसी एक्सेस प्वाइंट से एसोसिएट होता है और स्थानीय नेटवर्क सेटिंग्स प्राप्त करता है, फिर भी गेटवे उसे एक प्रतिबंधित स्थिति में रखता है। जब वह ब्राउज़ करने का प्रयास करती है, तो उस अनुरोध को इंटरसेप्ट कर लिया जाता है और उसे उसके द्वारा मांगे गए साइट के बजाय आपके पोर्टल पेज पर रीडायरेक्ट कर दिया जाता है।
यह वही ट्रांजैक्शन है जिसका विवरण Advantech कैप्टिव पोर्टल दस्तावेज़ में दिया गया है, जहां कोई उपयोगकर्ता किसी ओपन या सेमी-ओपन नेटवर्क से जुड़ता है और उसे एक ऐसे पोर्टल पर रीडायरेक्ट किया जाता है जो एक्सेस दिए जाने से पहले क्रेडेंशियल, भुगतान, पंजीकरण, या शर्तों की स्वीकृति का अनुरोध कर सकता है। इसके बाद वह शर्तों को स्वीकार करके, ईमेल दर्ज करके या भुगतान करके प्रमाणित (authenticate) करती है। जब वह उस चरण को पूरा कर लेती है, तो नेटवर्क उसके डिवाइस को अधिकृत (authorise) करता है और सामान्य ट्रैफिक को अनुमति देता है।
| चरण | क्या होता है |
|---|---|
| 1. एसोसिएशन | डिवाइस गेस्ट नेटवर्क से जुड़ता है |
| 2. इंटरसेप्शन | ब्राउज़र अनुरोध को पोर्टल पेज पर रीडायरेक्ट किया जाता है |
| 3. प्रमाणीकरण (Authentication) | गेस्ट ईमेल दर्ज करता है, शर्तों को स्वीकार करता है या भुगतान करता है |
| 4. प्राधिकरण (Authorisation) | नेटवर्क डिवाइस को इंटरनेट एक्सेस प्रदान करता है |
| 5. सत्र (Session) समाप्त | टाइमर समाप्त हो जाता है और डिवाइस पोर्टल पर वापस आ जाता है |
यही फ़्लो किसी हवाई अड्डे या किसी छोटे कैफे में भी लागू होता है क्योंकि पोर्टल वह जगह है जहाँ आपकी नेटवर्क पॉलिसी तय करती है कि कौन ऑनलाइन होगा। जब टाइमर समाप्त हो जाता है, तो ऑथराइजेशन समाप्त हो जाता है और डिवाइस वापस पोर्टल पर आ जाता है।
यह परीक्षण करके देखें: एक फोन को अपने गेस्ट नेटवर्क से कनेक्ट करें, एक प्लेन HTTP पेज खोलें, और पुष्टि करें कि कोई भी ब्राउज़िंग शुरू होने से पहले लॉगिन पेज दिखाई देता है।
स्थान कैप्टिव पोर्टल का उपयोग कहाँ करते हैं
किसी के द्वारा स्क्रीन डिज़ाइन करने से पहले आपके स्थान के प्रकार के अनुसार पोर्टल का काम तय होना चाहिए। एक कैफे, एक होटल और एक अस्पताल को एक ही लॉगिन चरण की आवश्यकता नहीं होती है, और तीनों पर एक ही टेम्पलेट को जबरन लागू करने से अलग-अलग स्थानों पर बाधाएं पैदा होती हैं।
| स्थान का प्रकार | लक्ष्य | लॉगिन चरण | सामान्य सेशन की अवधि |
|---|---|---|---|
| कैफे और रेस्तरां | तेज साइन-इन और गेस्ट लिस्ट | शर्तें और वैकल्पिक ईमेल | 1 से 2 घंटे |
| होटल और आवास | कमरे या बुकिंग से जुड़़ा एक्सेस | बुकिंग या कमरा जांच, वाउचर या एक्सेस कोड | रहने की अवधि |
| रिटेल सेंटर | दोबारा आने वाले विजिटर्स को मापें | ईमेल या अकाउंट साइन-इन जो दोबारा आने वाले मेहमानों को पहचानता है | 2 से 4 घंटे |
| इवेंट, कोवर्किंग या अस्पताल | समय-सीमित एक्सेस | वाउचर या एक्सेस कोड | इवेंट का दिन या बुक किया गया स्लॉट |
कैफ़े, होटल और रिटेल सेंटर
मान लीजिए कि एक कैफे गेस्ट ऑर्डर देने और बैठने के बीच WiFi से जुड़ती है। उसे शर्तों और एक वैकल्पिक ईमेल बॉक्स वाली एक स्क्रीन दिखाई देती है, वह कनेक्ट पर टैप करती है, और कुछ ही सेकंड में ऑनलाइन हो जाती है। इसमें पांच और फ़ील्ड जोड़ें और वह इसके बजाय मोबाइल डेटा पर स्विच कर लेगी।
एक होटल में विपरीत जोखिम होता है। यदि पोर्टल किसी कमरे या बुकिंग की जांच नहीं करता है, तो लॉबी या बाहर सड़क पर मौजूद कोई भी व्यक्ति भुगतान करने वाले अतिथियों के लिए निर्धारित बैंडविड्थ का उपयोग कर सकता है। रिटेल सेंटरों को मापन संबंधी समस्या का सामना करना पड़ता है। ऐसी लॉजिक के बिना जो किसी लौटने वाले डिवाइस या खाते को पहचान सके, हर विज़िट पहली विज़िट जैसी लगती है और बार-बार आने वाले विज़िट को मापा नहीं जा सकता है।
इवेंट, को-वर्किंग स्पेस और अस्पताल
ये स्थान फॉर्म की तुलना में सेशन टाइमर और एक्सेस कोड की अधिक परवाह करते हैं। एक डे पास, अपॉइंटमेंट या इवेंट टिकट यह परिभाषित करता है कि एक्सेस कितने समय तक चलना चाहिए। जब वह अवधि समाप्त हो जाती है, तो कर्मचारियों द्वारा मैन्युअल रूप से डिवाइस को हटाए बिना एक्सेस सुचारू रूप से समाप्त हो जानी चाहिए।
आपकी सेटिंग चाहे जो भी हो, इससे पहले कि आप यह मान लें कि केवल एक लॉगिन पेज ही अतिथियों को सुरक्षित बनाता है, इन सार्वजनिक WiFi कमियों के बारे में जानना उपयोगी होगा। प्रबंधित कुंजी से सुरक्षित केवल कर्मचारियों वाले नेटवर्क को पोर्टल से कोई लाभ नहीं होता है। यह केवल एक ऐसा चरण जोड़ता है जिसकी आपकी टीम को आवश्यकता नहीं है।
उस एकमात्र परिणाम को लिखें जो आपके गेस्ट नेटवर्क द्वारा प्रदान किया जाना आवश्यक है। वह एक वाक्य आपकी लॉगिन विधि को उन फ़ील्ड की सूची की तुलना में कहीं बेहतर तरीके से तय करता है जिन्हें आप एकत्र करना चाहते हैं।
अतिथि डेटा, सहमति और क्या मांगना है
क्या ऑनलाइन होने का मतलब व्यक्तिगत डेटा सौंपना ही है? कई स्थान हाँ मान लेते हैं, और जितना संभव हो सके उतना लंबा फॉर्म बनाते हैं। साक्ष्य कहते हैं कि यह एक विकल्प है, कोई आवश्यकता नहीं।
67 सार्वजनिक WiFi हॉटस्पॉट के 2019 के एक अकादमिक अध्ययन में, 27 हॉटस्पॉट, नमूने का 40.3%, व्यक्तिगत जानकारी एकत्र करने के लिए सोशल लॉगिन या पंजीकरण पृष्ठ का उपयोग करते थे, और 19 मामलों में इंटरनेट एक्सेस के लिए उस प्रक्रिया को पूरा करना अनिवार्य था। उसी अध्ययन में पाया गया कि 40 हॉटस्पॉट, या 59.7%, स्पष्ट व्यक्तिगत डेटा का अनुरोध किए बिना इंटरनेट एक्सेस की अनुमति देते थे। इसलिए पोर्टल का मतलब स्वतः मार्केटिंग पंजीकरण नहीं होता है।
एक ही स्क्रीन पर तीन कार्य
अपने डिज़ाइन और अपने रिकॉर्ड में इन्हें स्पष्ट रूप से अलग करें।
- नेटवर्क एक्सेस को नियंत्रित करना: गेटवे यह तय करता है कि यह डिवाइस इंटरनेट तक पहुँच सकता है या नहीं।
- उपयोग की शर्तें दिखाना: अतिथि कनेक्शन के लिए स्वीकार्य-उपयोग की शर्तों को स्वीकार करता है।
- मार्केटिंग सहमति प्राप्त करना: अतिथि बाद में मैसेज प्राप्त करने के लिए सहमत होता है, जो एक अलग निर्णय है।
यहाँ वह बात है जिसे पाठक सबसे अधिक बार भूल जाते हैं। केवल एक स्पष्ट ऑप्ट-इन को ही मार्केटिंग सहमति माना जाता है; शर्तों को स्वीकार करने से WiFi मार्केटिंग सहमति नहीं मिलती है। जिस अतिथि ने ऑनलाइन आने के लिए किसी बॉक्स पर टिक किया है, उसने आपके न्यूज़लेटर के लिए सहमति नहीं दी है। उस टिक को अनुमति मानने से आपकी सूची और आपकी प्रतिष्ठा जोखिम में पड़ जाती है।
एक ऐसा लेआउट जिसे अतिथि आसानी से समझ सकें
स्वीकार्य-उपयोग (acceptable-use) वाले शब्दों के बगल में आवश्यक शर्तों का टिक लगाएं। इसके नीचे, अपने स्वयं के स्पष्ट वाक्य के साथ एक अलग, बिना टिक वाला मार्केटिंग चेकबॉक्स रखें, जैसे ईमेल द्वारा ऑफ़र प्राप्त करने का निमंत्रण। एक दृश्यमान गोपनीयता नोटिस लिंक जोड़ें जो अतिथि द्वारा कुछ भी सबमिट करने से पहले खुलता हो, न कि साइन-इन के बाद छुपा हुआ हो।
वह पृथक्करण स्थानों के लिए इस GDPR अनुपालन योग्य ईमेल मार्केटिंग चेकलिस्ट में व्यावहारिक जांचों के साथ संरेखित होता है। यह अतिथियों को एक वास्तविक विकल्प भी देता है। कोई व्यक्ति मार्केटिंग को अस्वीकार कर सकता है और फिर भी ऑनलाइन आ सकता है, ठीक इसी तरह इसे काम करना चाहिए।
अधिक फ़ील्ड का अर्थ अधिक मूल्य नहीं है। प्रत्येक अतिरिक्त प्रश्न से पूर्णता में कमी आती है और वह ऐसा डेटा जोड़ता है जिसे सुरक्षित रखने की जिम्मेदारी आपकी है।
जब कोई अतिथि ऑप्ट-इन करता है, तो पोर्टल उनकी ईमेल, विजिट की तारीख और पसंदीदा लोकेशन को एक केंद्रीय रिकॉर्ड में स्टोर कर सकता है। जब कोई अतिथि अपने ईमेल एड्रेस या सोशल प्रोफाइल का उपयोग करके कनेक्ट और लॉग इन करता है, तो हम उस डेटा को कैप्चर करते हैं और एक केंद्रीकृत CRM में स्टोर करते हैं। इस तरह कोई स्थान किसी प्लेटफॉर्म की ऑडियंस पर निर्भर रहने के बजाय अपने स्वामित्व वाला फर्स्ट-पार्टी डेटा बनाता है।
लॉन्च से पहले तीन सवालों के जवाब दें। एक्सेस प्रदान करने के लिए strictly किस डेटा की आवश्यकता है? आप पहचान और डिवाइस रिकॉर्ड कितने समय तक रखेंगे? क्या कोई अतिथि मार्केटिंग को अस्वीकार कर सकता है और फिर भी ऑनलाइन आ सकता है? यदि कोई उत्तर अस्पष्ट है, तो डिज़ाइन ठीक करने से पहले फ़ॉर्म को ठीक करें।
प्रयास और डेटा के आधार पर लॉगिन विधियों की तुलना
प्रत्येक लॉगिन विधि गेस्ट के प्रयास, कैप्चर किए गए डेटा और विभिन्न डिवाइसों पर विश्वसनीयता के बीच संतुलन बनाती है। तालिका को ऊपर से नीचे तक पढ़ें और आप देखेंगे कि यह ट्रेड-ऑफ कदम दर कदम बढ़ता जाता है।
| लॉगिन विधि | एकत्रित डेटा | अतिथि का प्रयास | सर्वोत्तम उपयुक्त |
|---|---|---|---|
| केवल शर्तों पर क्लिक-थ्रू | केवल डिवाइस रिकॉर्ड | बहुत कम | तेज़ पहुंच चाहने वाले कैफे |
| वाउचर या एक्सेस कोड | केवल कोड रिडेम्पशन | कम | प्रिंटेड या सशुल्क पहुंच वाले होटल और कार्यक्रम |
| ईमेल पंजीकरण | ईमेल पता और मार्केटिंग ऑप्ट-इन | मध्यम | अतिथि सूची बनाने वाले स्थान |
| सोशल लॉगिन | प्रोफ़ाइल डेटा जो प्रदाता अनुमति देता है | कम | वन-टैप साइन-इन पसंद करने वाले अतिथि |
| SMS वन-टाइम कोड | मोबाइल नंबर | मध्यम | सत्यापित पहचान की आवश्यकता वाले स्थान |
| Passpoint या प्रमाणपत्र-आधारित प्रमाणीकरण | डिवाइस क्रेडेंशियल, कोई पोर्टल पृष्ठ नहीं | सेटअप के बाद बहुत कम | प्रबंधित उपकरणों वाले बड़े स्थान |
सबसे कम डेटा से सबसे अधिक डेटा तक
केवल शर्तों का क्लिक-थ्रू सिर्फ एक टैप मांगता है और केवल एक डिवाइस रिकॉर्ड बनाता है। यह तेज़ है, लेकिन यह मेहमानों की सूची नहीं बना सकता। वाउचर या एक्सेस कोड बिना यह पूछे नियंत्रण जोड़ता है कि मेहमान कौन है, जो मुद्रित होटल कार्ड और इवेंट पास के लिए उपयुक्त है।
ईमेल पंजीकरण में अधिक प्रयास की आवश्यकता होती है और यह एक उपयोगी संपर्क प्रदान करता है, बशर्ते मार्केटिंग ऑप्ट-इन अलग रहे। यदि आप अन्य कैप्चर तरीकों के साथ इसकी तुलना कर रहे हैं, तो QR कोड साइन-अप बनाम ईमेल कैप्चर के लिए WiFi लॉगिन की यह तुलना आपको डेटा गुणवत्ता के मुकाबले प्रयास का आकलन करने में मदद करती है।
सोशल लॉगिन एक टैप जैसा लगता है, लेकिन यह एक थर्ड-पार्टी रीडायरेक्ट जोड़ता है। कुछ ब्राउज़र और WiFi के लिए उपयोग किए जाने वाले फोन की छोटी साइन-इन विंडो उन रीडायरेक्ट को ठीक से संभाल नहीं पाती हैं, और अतिथियों को वह पासवर्ड याद नहीं भी हो सकता है जो उन्होंने वर्षों से टाइप नहीं किया है। SMS वन-टाइम कोड एक नंबर को सत्यापित करते हैं, फिर भी वे इस बात पर निर्भर करते हैं कि अतिथि के पास मोबाइल सिग्नल हो और एक ऐसा नंबर हो जो मैसेज स्वीकार करता हो।
Passpoint या प्रमाणपत्र-आधारित प्रमाणीकरण सेटअप के बाद पोर्टल पेज को हटा देता है। इसके लिए डिवाइस पर एक प्रबंधित प्रोफ़ाइल की आवश्यकता होती है, इसलिए यह आपके नेटवर्क से पहली बार मिलने वाले नए आगंतुकों की तुलना में कर्मचारियों और नियमित रूप से लौटने वाले मेहमानों के लिए अधिक उपयुक्त है।
निर्णय का नियम: लॉगिन चरण को उस एकल परिणाम से मिलाएँ जिसकी आपको आवश्यकता है, न कि फ़ील्ड के उस सबसे बड़े सेट से जिसे आप एकत्र कर सकते हैं।
अभी दो विधियों को शॉर्टलिस्ट करें। आप एक को चुनने से पहले अपने हार्डवेयर और विफलता जाँचों के विरुद्ध दोनों का परीक्षण करेंगे।
कैप्टिव पोर्टल क्यों विफल होते हैं और इसे कैसे रोकें
एक पोर्टल केवल एक ब्रांडेड पेज नहीं है। लॉगिन से पहले, गेटवे प्रत्येक डिवाइस को एक प्रतिबंधित स्थिति में रखता है और केवल डिस्कवरी, लॉगिन और पोर्टल ट्रैफ़िक की अनुमति देता है। अधिकांश विफलताओं का कारण यह है कि उस होल्डिंग क्षेत्र का निर्माण या परीक्षण खराब तरीके से किया गया है।
चार लक्षण जो अतिथि देखते हैं
पोर्टल कभी दिखाई नहीं देता। अधिकांश साइटें अब HTTPS का उपयोग करती हैं, और ब्राउज़र प्रतिस्थापित प्रमाणपत्रों को अस्वीकार कर देते हैं, इसलिए पुराना HTTP इंटरसेप्शन आपके पेज को विश्वसनीय रूप से नहीं दिखा सकता है। इसके बजाय ऑपरेटिंग सिस्टम कनेक्टिविटी जांच चलाते हैं, जैसे कि यह पता लगाने के लिए कि इंटरनेट एक्सेस को इंटरसेप्ट किया जा रहा है या नहीं, TCP पोर्ट 80 और 443 पर captive.apple.com को Apple के कैप्टिव नेटवर्क सपोर्ट गाइडेंस में वर्णित अनुरोध बनाए जाते हैं।
पेज सही तरीके से लोड नहीं होता है। HTML आ जाता है, लेकिन स्टाइलशीट, स्क्रिप्ट, फ़ॉन्ट, या आइडेंटिटी-प्रोवाइडर रीडायरेक्ट प्रतिबंधित स्थिति के भीतर ब्लॉक हो जाते हैं। पोर्टल एसेट को स्थानीय रूप से होस्ट करें या पेज के लिए आवश्यक प्रत्येक एंडपॉइंट को अनुमति दें (अलाउलिस्ट करें)।
कुछ अतिथि पोर्टल को बायपास कर देते हैं। यदि आप IPv4 को फ़िल्टर करते हैं लेकिन IPv6 को खुला छोड़ देते हैं, तो ट्रैफ़िक आपके नियम के आसपास से गुज़र सकता है। दोनों पाथ को समान महत्व दें।
गेस्ट बार-बार वापस लॉगिन पर आ जाते हैं। ऑथराइजेशन टाइमर समाप्त हो जाता है, या एक्सेस पॉइंट के बीच रोमिंग से सेशन समाप्त हो जाता है, और गेस्ट को बार-बार रीडायरेक्ट किया जाता है। सिग्नल मजबूत होने पर भी यह WiFi खराब होने जैसा लगता है।
लॉन्च करने से पहले चलाए जाने वाले परीक्षण
- वास्तविक डिवाइसों का परीक्षण करें: iOS, Android, Windows, macOS, और प्रिंटर या टीवी जैसे कम से कम एक IoT डिवाइस पर काम करके देखें।
- दो समयों को मापें: प्रत्येक डिवाइस पर पोर्टल तक पहुंचने के समय और प्राधिकरण (authorisation) के समय को रिकॉर्ड करें।
- सत्र (session) समाप्ति को बाध्य करें: पुष्टि करें कि गेस्ट पोर्टल पर सुचारू रूप से वापस आता है और फिर से साइन इन कर सकता है।
- कनेक्ट रहने के दौरान रोम करें: प्राइवेट MAC एड्रेस सक्षम करके एक्सेस पॉइंट्स के बीच चलें और देखें कि क्या एक्सेस बना रहता है।
पोर्टल डिटेक्शन विफल होने की स्थिति के लिए एक डॉक्यूमेंटेड फ़ॉलबैक रखें, जैसे कि एक छोटा पता जिसे स्टाफ गेस्ट को मैन्युअल रूप से खोलने के लिए दे सके। नेटवर्क को पूरी तरह से ओपन पर स्विच करके सुरक्षा को कमजोर न करें।
अंत में, अतिथियों को फ़िशिंग पहचानने में मदद करें। नेटवर्क का नाम स्थान से मेल खाना चाहिए, पोर्टल का पता स्थान के अपने डोमेन पर होना चाहिए, और ब्राउज़र को उस डोमेन के लिए एक वैध TLS प्रमाणपत्र दिखाना चाहिए। एक वैध पोर्टल कभी भी बैंक विवरण या सोशल मीडिया पासवर्ड नहीं मांगता है।
आपके मौजूदा नेटवर्क के साथ एकीकरण के विकल्प
पोर्टल जोड़ने के लिए आपको अपने नेटवर्क को पूरी तरह बदलने की आवश्यकता नहीं है। इस बात से शुरुआत करें कि डिवाइसों को पोर्टल की मौजूदगी के बारे में कैसे पता चलता है, क्योंकि यह उन फ़ोनों की विश्वसनीयता तय करता है जो कभी भी पहले ब्राउज़र नहीं खोलते हैं।
नीचे दी गई छवि दिखाती है कि पोर्टल आपके एक्सेस पॉइंट और गेस्ट रिकॉर्ड प्राप्त करने वाले सिस्टम के बीच कैसे काम करता है।
मानक पथ
Fortinet के कैप्टिव पोर्टल एडमिनिस्ट्रेशन गाइड में वर्णित दृष्टिकोण के तहत, RFC 8910 परिभाषित करता है कि कोई नेटवर्क DHCPv4 ऑप्शन 114, DHCPv6, या IPv6 राउटर विज्ञापनों के माध्यम से अपने पोर्टल API एंडपॉइंट का विज्ञापन कैसे करता है। RFC 8908 फिर application/captive+json मीडिया प्रकार का उपयोग करके HTTPS JSON API निर्दिष्ट करता है, जो यह उजागर करता है कि क्लाइंट अभी भी कैप्टिव है या नहीं, उपयोगकर्ता के सामने वाला लॉगिन URI, और शेष एक्सेस समय जैसी सेशन जानकारी प्रदान करता है।
सरल शब्दों में, नेटवर्क ऑपरेटिंग सिस्टम को सीधे बताता है कि कहाँ साइन इन करना है और एक्सेस कितने समय तक रहेगा। यह असफल रीडायरेक्ट पर निर्भरता को कम करता है, खासकर जब ऐप्स HTTPS या सर्टिफिकेट पिंग का उपयोग करते हैं। दोनों API एंडपॉइंट और पोर्टल को सर्टिफिकेट वैलिडेशन के साथ TLS का उपयोग करना चाहिए, अन्यथा एक हमलावर एक अधिकृत स्थिति बना सकता है या लॉगिन गंतव्य बदल सकता है।
यह छोटा वीडियो बताता है कि वे एकीकरण बिंदु व्यवहार में एक साथ कैसे फिट बैठते हैं।
प्रत्येक कनेक्शन बिंदु को मैप करें
एक पोर्टल लेयर आपके मौजूदा हार्डवेयर पर बैठ सकती है, जिसमें Cisco Meraki, HPE Aruba, और Ubiquiti UniFi शामिल हैं, और यह आपके साइन-इन पर समर्पित WiFi प्लेटफॉर्म के साथ या उसके बिना चल सकती है। आपके IT प्रमुख को सेटिंग्स चुनने से पहले चार बिंदुओं का नक्शा बनाना चाहिए।
- एक्सेस पॉइंट कंट्रोलर: नेटवर्क नाम, प्रतिबंधित स्थिति और रीडायरेक्ट या API विज्ञापन का स्वामी है।
- आइडेंटिटी सोर्स: कमरे के नंबर, वाउचर, स्टाफ अकाउंट या सोशल साइन-इन की जांच करता है।
- गेस्ट रिकॉर्ड सिस्टम: सहमति प्राप्त संपर्क विवरण प्राप्त करता है, जैसा कि उपलब्ध Purple WiFi एकीकरणों में दिखाया गया है।
- TLS सर्टिफिकेट: मेहमानों द्वारा देखे जाने वाले पोर्टल डोमेन से मेल खाना चाहिए, जिसका नवीनीकरण किसी नामित व्यक्ति के पास होना चाहिए।
एक निर्णय परीक्षण (decision test) चलाएं। यदि आपका नेटवर्क IPv4 और IPv6 पर RFC 8910 विज्ञापन का समर्थन करता है, तो इसे बनाए रखें और JSON प्रतिक्रियाओं का परीक्षण करें। यदि ऐसा नहीं है, तो डॉक्यूमेंटेड फ़ॉलबैक के साथ ब्राउज़र-आधारित रीडायरेक्ट की योजना बनाएं।
वह पोर्टल सेटअप चुनें जिसकी आपके स्थान को आवश्यकता है
एक ही साइन-इन स्क्रीन के भीतर तीन अलग-अलग निर्णय छिपे होते हैं: नेटवर्क एक्सेस, शर्तों की स्वीकृति और मार्केटिंग सहमति। एक्सेस डिवाइस को नेटवर्क पर लाता है। शर्तों की स्वीकृति यह रिकॉर्ड करती है कि अतिथि आपके नियमों से सहमत था। मार्केटिंग सहमति एक जानबूझकर दिया गया ऑप्ट-इन है, और WiFi की शर्तों को स्वीकार करने से यह प्राप्त नहीं होता है। एक सेटअप जो इन्हें एक ही टिक में मिला देता है, वह या तो ऐसी सहमति एकत्र करता है जिसका आप उपयोग नहीं कर सकते हैं या उन अतिथियों को रोकता है जो आसानी से लॉग इन कर सकते थे।
तीन शुरुआती बिंदु
तेज़ पहुंच और एक ऑप्ट-इन सूची की आवश्यकता वाले कैफे को शर्तों के साथ वैकल्पिक ईमेल का उपयोग करना चाहिए। ईमेल फ़ील्ड और मार्केटिंग ऑप्ट-इन केवल तभी दिखाई देते हैं जब मेहमान सक्रिय रूप से उन्हें चुनते हैं। पहले गेस्ट रिकॉर्ड सिस्टम की जांच करें, ताकि नए संपर्क किसी उपयोगी जगह पर पहुंचें।
एक्सेस को बुकिंग से जोड़ने वाले होटल को कमरे या बुकिंग जांच, या चेक-इन के समय जारी किए गए वाउचर का उपयोग करना चाहिए। एक्सेस को अधिकृत करने के लिए आवश्यक स्टे संदर्भ कैप्चर करें, अतिरिक्त प्रोफ़ाइल फ़ील्ड नहीं। सबसे पहले पहचान स्रोत की जांच करें, क्योंकि फ्रंट डेस्क कर्मचारी बेमेल समस्याओं को दूर करेंगे।
निरंतरता की आवश्यकता वाले बहु-साइट समूह को सभी साइटों पर एक सहमति रिकॉर्ड और रिपोर्टिंग को मानकीकृत करना चाहिए। हर जगह एक ही अलग ऑप्ट-इन के साथ ईमेल पंजीकरण का मतलब है कि प्रत्येक साइट अस्वीकृतियों को एक ही तरह से संभालती है। पहले रिपोर्टिंग और डेटा प्रतिधारण की जांच करें।
वे डिवाइस जिन्हें पोर्टल कभी नहीं देखेगा
एक कैप्टिव पोर्टल केवल उसी हार्डवेयर पर काम करता है जो ब्राउज़र खोल सकता है। स्मार्ट टीवी, प्रिंटर, टिल टर्मिनल और कमरे में मौजूद गैजेट्स के पास पेज को रेंडर करने के लिए कुछ नहीं होता है, इसलिए वे अनिश्चित काल के लिए प्रतिबंधित स्थिति में ही पड़े रहते हैं। उन डिवाइसों को एक अलग रास्ता दें, जैसे स्टाफ या डिवाइस नेटवर्क पर प्रति-डिवाइस कुंजियां (keys), और पोर्टल को उन फोन और लैपटॉप के लिए आरक्षित रखें जो लॉगिन दिखा सकते हैं।
लॉन्च करने से पहले, पुष्टि करें कि आपका हार्डवेयर मानकों के पथ का समर्थन करता है या आपका फ़ॉलबैक डॉक्यूमेंटेड है। केवल कार्यालय में लैपटॉप ही नहीं, बल्कि वास्तविक गेस्ट डिवाइसों के साथ डिवाइस, एक्सपायरी, रोमिंग और IPv6 की जांच चलाएं।
Purple Engage उन स्थानों के लिए उपयुक्त है जो चाहते हैं कि साइन-इन का उपयोग बाद के मार्केटिंग के लिए किया जा सके। यह भौतिक स्थानों के लिए एक ऑल-इन-वन मार्केटिंग सिस्टम है जो हर WiFi साइन-इन को दोबारा आने वाले विजिट में बदल देता है, चाहे Purple WiFi हो या न हो, और यह साबित करता है कि किन अभियानों ने ऐसा किया है। यह WiFi साइन-इन, टिल सेल्स, बुकिंग, फॉर्म, फाइलें, संदेश और सर्वे के उत्तरों को ईमेल द्वारा मेल खाते एक गेस्ट रिकॉर्ड में जोड़ता है। क्योंकि यह Purple WiFi के साथ या उसके बिना काम करता है और आपके मौजूदा सिस्टम को पढ़ता है, आप इसे अपने पहले से चल रहे हार्डवेयर और टिल से जोड़ सकते हैं।
इस सप्ताह एक काम करें। अपने पोर्टल द्वारा प्रदान किए जाने वाले एक परिणाम को लिखें, फिर उस परिणाम के अनुसार अपनी लॉगिन विधि, डेटा फ़ील्ड और पहले एकीकरण की जाँच को मैप करें।
यदि आप WiFi के लिए एक कैप्टिव पोर्टल स्थापित कर रहे हैं और चाहते हैं कि प्रत्येक सहमत साइन-इन एक उपयोगी गेस्ट रिकॉर्ड बन जाए, तो Purple Engage WiFi साइन-इन को टिल बिक्री, बुकिंग, फॉर्म और सर्वेक्षण उत्तरों के साथ एक ही स्थान पर लाता है। यह देखने के लिए साइट पर जाएं कि यह आपके द्वारा पहले से चलाए जा रहे हार्डवेयर पर कैसे काम करता है और पहली बार कनेक्ट होने वाले को फिर से आने वाले गेस्ट में बदलने में कैसे मदद करता है।