WiFi साठी कॅप्टिव्ह पोर्टल: हे कसे कार्य करते आणि याची कोणाला गरज आहे
WiFi साठी कॅप्टिव्ह पोर्टल म्हणजे काय, ठिकाणे याचा कसा वापर करतात, कोणते संमतीचे नियम लागू होतात आणि कोणते एकत्रित पर्याय तुमच्या नेटवर्कसाठी योग्य आहेत हे जाणून घ्या.
जर एखादा गेस्ट तुमच्या WiFi मध्ये सामील होऊ शकत असेल आणि लगेच ब्राउझ करू शकत असेल, तर त्यांनी नेमके कशाला सहमती दिली आणि तुम्हाला त्यांच्याबद्दल काय माहिती मिळाली? तीच त्रुटी WiFi साठीचा कॅप्टिव्ह पोर्टल भरून काढतो, परंतु तुम्ही अनेकदा एकाच स्क्रीनवर एकत्र जोडलेली तीन कामे वेगळी केली तरच ते शक्य होते. एक काम नेटवर्क ॲक्सेस नियंत्रित करते. दुसरे काम तुमच्या वापराच्या अटींची स्वीकृती नोंदवते. तिसरे काम मार्केटिंग संमती मागते, आणि ते इतर दोन कामांसारखे नसते.
फ्रंट डेस्क एखाद्याला आत घेऊ शकते, घरातील नियम समजावून सांगू शकते आणि त्यांना मेलिंग लिस्टमध्ये सामील होण्यासाठी आमंत्रित करू शकते. ते एकमेकांशी संबंधित आहेत, परंतु तो एकच निर्णय नाही. जेव्हा स्थळे त्यांच्याकडे एकच टिक बॉक्स म्हणून पाहतात, तेव्हा अतिथींचा गोंधळ होतो, संमती डळमळीत होते आणि ब्राऊजर कधीही न उघडणारी उपकरणे सुटू शकतात किंवा अडकू शकतात.
अनुक्रमणिका
- कॅप्टिव्ह पोर्टल टप्प्याटप्प्याने कसे कार्य करते
- ठिकाणे कॅप्टिव्ह पोर्टल कुठे वापरतात
- गेस्ट डेटा, संमती आणि काय विचारावे
- प्रयत्न आणि डेटानुसार लॉगिन पद्धतींची तुलना
- कॅप्टिव्ह पोर्टल्स का अयशस्वी होतात आणि ते कसे रोखावे
- तुमच्या विद्यमान नेटवर्कसह इंटिग्रेशन पर्याय
- तुमच्या ठिकाणाला आवश्यक असलेला पोर्टल सेटअप निवडा
कॅप्टिव्ह पोर्टल टप्प्याटप्प्याने कसे कार्य करते
हॉटेल रिसेप्शनचा विचार करा. रूमची की गोळा करण्यापूर्वी प्रत्येक पाहुणा रिसेप्शन डेस्कवरून जातो आणि WiFi जोडले जाणे आणि इंटरनेटपर्यंत पोहोचणे यादरम्यान पोर्टल अशाच प्रकारे कार्य करते. पाहुणे प्रथम नेटवर्कशी जोडले जातात, परंतु केवळ त्या कनेक्शनमुळे निर्बंधमुक्त ब्राऊझिंगची परवानगी मिळत नाही.
समजा एखाद्या कॅफेमधील अतिथीने तुमच्या नेटवर्कच्या नावावर टॅप केले. तिचा फोन ॲक्सेस पॉइंटशी संबंधित होतो आणि स्थानिक नेटवर्क सेटिंग्ज मिळवतो, तरीही गेटवे तिला प्रतिबंधित स्थितीत ठेवतो. जेव्हा ती ब्राऊज करण्याचा प्रयत्न करते, तेव्हा ती विनंती इंटरसेप्ट केली जाते आणि तिने मागितलेल्या साइटऐवजी तिला तुमच्या पोर्टल पेजवर रीडायरेक्ट केले जाते.
तो असा व्यवहार आहे ज्याचे वर्णन Advantech कॅप्टिव्ह पोर्टल दस्तऐवजीकरणामध्ये केले आहे, जिथे वापरकर्ता उघड्या किंवा अर्ध-उघड्या नेटवर्कमध्ये सामील होतो आणि त्याला अशा पोर्टलवर रीडायरेक्ट केले जाते जे प्रवेश देण्यापूर्वी क्रेडेंशियल, पेमेंट, नोंदणी किंवा अटींची स्वीकृती मागू शकते. त्यानंतर ती अटी स्वीकारून, ईमेल प्रविष्ट करून किंवा पेमेंट करून प्रमाणित (authenticate) करते. तिने ती पायरी पूर्ण केल्यावर, नेटवर्क तिचे डिव्हाइस अधिकृत (authorise) करते आणि सामान्य ट्रॅफिकला पुढे जाण्याची अनुमती देते.
| टप्पा | काय घडते |
|---|---|
| 1. असोसिएशन (Association) | डिव्हाइस गेस्ट नेटवर्कमध्ये सामील होते |
| 2. इंटरसेप्शन (Interception) | ब्राउझरची विनंती पोर्टल पृष्ठावर रीडायरेक्ट केली जाते |
| 3. ऑथेंटिकेशन (Authentication) | गेस्ट ईमेल प्रविष्ट करतो, अटी स्वीकारतो किंवा पेमेंट करतो |
| 4. ऑथोरायझेशन (Authorisation) | नेटवर्क डिव्हाइसला इंटरनेट प्रवेश प्रदान करते |
| 5. सत्राचा शेवट (Session end) | टायमर संपतो आणि डिव्हाइस पुन्हा पोर्टलवर येते |
विमानतळ असो वा लहान कॅफे, हाच प्रवाह लागू होतो कारण पोर्टल हे असे ठिकाण आहे जिथे तुमचे नेटवर्क धोरण कोणाला ऑनलाइन ॲक्सेस द्यायचा ते ठरवते. जेव्हा टायमर संपतो, तेव्हा ऑथोरायझेशन समाप्त होते आणि डिव्हाइस पुन्हा पोर्टलवर येते.
ही चाचणी करून पहा: तुमच्या गेस्ट नेटवर्कशी फोन कनेक्ट करा, एक साधे HTTP पेज उघडा आणि कोणतेही ब्राउझिंग सुरू होण्यापूर्वी लॉगिन पेज दिसते याची खात्री करा.
ठिकाणे कॅप्टिव्ह पोर्टलचा वापर कुठे करतात
कोणीही स्क्रीन डिझाइन करण्यापूर्वी तुमच्या ठिकाणाच्या प्रकारानुसार पोर्टलचे कार्य निश्चित केले पाहिजे. कॅफे, हॉटेल आणि हॉस्पिटल यांना समान लॉगिन पायरीची आवश्यकता नसते आणि तिन्हींवर एकच टेम्पलेट लादल्याने वेगवेगळ्या ठिकाणी अडचणी निर्माण होतात.
| स्थळाचा प्रकार | उद्दीष्ट | लॉगिन पायरी | सर्वसाधारण सत्राचा कालावधी |
|---|---|---|---|
| कॅफे आणि रेस्टॉरंट | जलद साइन-इन आणि अतिथी सूची | अटी तसेच ऐच्छिक ईमेल | 1 ते 2 तास |
| हॉटेल आणि निवास व्यवस्था | खोली किंवा बुकिंगशी जोडलेला ॲक्सेस | बुकिंग किंवा खोलीची तपासणी, व्हाऊचर किंवा ॲक्सेस कोड | मुक्कामाचा कालावधी |
| रिटेल सेंटर | पुन्हा भेट देणाऱ्यांची नोंद मोजणे | पुन्हा येणाऱ्या अतिथींना ओळखणारे ईमेल किंवा खाते साइन-इन | 2 ते 4 तास |
| इव्हेंट, को-वर्किंग किंवा रुग्णालय | वेळेचे बंधन असलेला ॲक्सेस | व्हाऊचर किंवा ॲक्सेस कोड | इव्हेंटचा दिवस किंवा बुक केलेला स्लॉट |
कॅफे, हॉटेल्स आणि रिटेल केंद्रे
समजा एखाद्या कॅफेमध्ये ऑर्डर देणे आणि टेबलवर बसणे या दरम्यान पाहुणी WiFi ला कनेक्ट करते. तिला अटी आणि एक ऐच्छिक ईमेल बॉक्स असलेली एक स्क्रीन दिसते, ती कनेक्ट वर टॅप करते आणि काही सेकंदात ऑनलाइन होते. यात आणखी पाच फील्ड्स जोडा आणि ती त्याऐवजी मोबाईल डेटावर स्विच करेल.
हॉटेलमध्ये याच्या उलट धोका असतो. जर पोर्टलने खोली किंवा बुकिंग तपासले नाही, तर लॉबीमध्ये किंवा बाहेरील रस्त्यावर असलेली कोणतीही व्यक्ती पैसे देणाऱ्या अतिथींसाठी असलेले बँडविड्थ वापरू शकते. रिटेल केंद्रांना मापनाच्या समस्येला सामोरे जावे लागते. परत येणारे डिव्हाइस किंवा खाते ओळखणारे लॉजिक नसल्यास, प्रत्येक भेट ही पहिली भेट असल्यासारखी दिसते आणि पुन्हा भेट देणाऱ्यांचे मापन केले जाऊ शकत नाही.
इव्हेंट्स, सह-कार्यशील जागा (कोवर्किंग स्पेसेस) आणि रुग्णालये
या ठिकाणांना फॉर्मपेक्षा सेशन टाइमर आणि ॲक्सेस कोडची अधिक काळजी असते. डे पास, अपॉइंटमेंट किंवा इव्हेंट तिकीट हे ठरवते की ॲक्सेस किती काळ टिकला पाहिजे. तो कालावधी संपल्यावर, कर्मचाऱ्यांनी मॅन्युअली डिव्हाइसेस न हटवता ॲक्सेस व्यवस्थितपणे संपला पाहिजे.
तुमची सेटिंग काहीही असली, तरी केवळ लॉगिन पेज अतिथींना सुरक्षित ठेवते असा विचार करण्यापूर्वी या सार्वजनिक WiFi धोक्यांचे विश्लेषण तपासून पाहणे महत्त्वाचे आहे. मॅनेज्ड की द्वारे सुरक्षित केलेल्या केवळ कर्मचाऱ्यांसाठीच्या नेटवर्कला पोर्टलमुळे कोणताही अतिरिक्त फायदा होत नाही. हे केवळ तुमच्या टीमसाठी एक नको असलेली पायरी जोडते.
तुमच्या गेस्ट नेटवर्कने दिलेले एकच उद्दिष्ट लिहून ठेवा. ते वाक्य तुम्हाला गोळा करायच्या असलेल्या फील्ड्सच्या यादीपेक्षा अधिक चांगल्या प्रकारे तुमची लॉगिन पद्धत ठरवते.
अतिथी डेटा, संमती आणि कशाची मागणी करावी
ऑनलाइन जाणे म्हणजे वैयक्तिक डेटा हस्तांतरित करणे आवश्यक आहे का? अनेक ठिकाणे होय असे गृहीत धरतात आणि शक्य तितका मोठा फॉर्म तयार करतात. परंतु पुरावे असे सांगतात की ही एक निवड आहे, कोणतीही अनिवार्य अट नाही.
67 सार्वजनिक WiFi हॉटस्पॉट्सच्या 2019 मधील एका शैक्षणिक अभ्यासात, 27 हॉटस्पॉट्स, म्हणजे नमुन्याच्या 40.3%, वैयक्तिक माहिती गोळा करण्यासाठी सोशल लॉगिन किंवा नोंदणी पृष्ठाचा वापर करत होते, आणि 19 प्रकरणांमध्ये ती प्रक्रिया पूर्ण करणे इंटरनेट ॲक्सेससाठी अनिवार्य होते. त्याच अभ्यासात असे आढळून आले की 40 हॉटस्पॉट्स, म्हणजेच 59.7%, वैयक्तिक डेटाची स्पष्ट विनंती न करता इंटरनेट ॲक्सेसची अनुमती देत होते. त्यामुळे पोर्टल म्हणजे आपोआप मार्केटिंग नोंदणी असे होत नाही.
एका स्क्रीनवर तीन कार्ये
तुमच्या डिझाइनमध्ये आणि तुमच्या नोंदींमध्ये हे स्पष्टपणे वेगळे करा.
- नेटवर्क ॲक्सेस नियंत्रित करणे: हे डिव्हाइस इंटरनेटपर्यंत पोहोचू शकते की नाही हे गेटवे ठरवते.
- वापराच्या अटी दर्शवणे: अतिथी स्वतः कनेक्शनसाठी स्वीकार्य-वापर अटी स्वीकारतो.
- मार्केटिंग संमती मिळवणे: अतिथी नंतर मेसेज प्राप्त करण्यास सहमती देतो, जो एक स्वतंत्र निर्णय आहे.
वाचक सर्वात जास्त वेळा जो मुद्दा चुकवतात तो हा आहे. केवळ स्पष्ट ऑप्ट-इन हेच मार्केटिंग संमती म्हणून मानले जाते; WiFi अटी स्वीकारल्याने मार्केटिंगची संमती मिळत नाही. ऑनलाइन जाण्यासाठी बॉक्सवर टिक करणाऱ्या अतिथीने तुमच्या न्यूजलेटरला सहमती दिलेली नाही. त्या टिकला परवानगी मानल्याने तुमची लिस्ट आणि तुमची प्रतिष्ठा धोक्यात येते.
अतिथींना समजेल अशी मांडणी (लेआउट)
स्वीकार्य-वापराच्या मजकुराशेजारी आवश्यक अटींचा टिक बॉक्स ठेवा. त्याच्या खाली, स्वत:चे स्पष्ट वाक्य असलेला एक वेगळा, अनटिक केलेला मार्केटिंग चेकबॉक्स ठेवा, जसे की ईमेलद्वारे ऑफर्स मिळवण्याचे निमंत्रण. एक दृश्यमान गोपनीयता सूचना लिंक जोडा जी अतिथीने काहीही सबमिट करण्यापूर्वी उघडेल, साइन-इन केल्यानंतर लपवलेली नसेल.
हे वर्गीकरण या GDPR स्थळांसाठी अनुपालन ईमेल मार्केटिंग चेकलिस्ट मधील व्यावहारिक तपासण्यांशी जुळते. हे अतिथींना एक वास्तविक पर्याय देखील देते. एखादी व्यक्ती मार्केटिंग नाकारू शकते आणि तरीही ऑनलाइन जाऊ शकते, आणि हे अगदी असेच कार्य केले पाहिजे.
जास्त फील्ड्स म्हणजे जास्त व्हॅल्यू असा होत नाही. प्रत्येक अतिरिक्त प्रश्नामुळे फॉर्म पूर्ण होण्याचे प्रमाण घटते आणि तुम्हाला ज्याचे संरक्षण करण्याची जबाबदारी आहे असा डेटा वाढतो.
जेव्हा एखादा अतिथी ऑप्ट-इन करतो, तेव्हा पोर्टल त्यांचा ईमेल, भेटीची तारीख आणि पसंतीचे स्थान एका मध्यवर्ती नोंदीमध्ये संग्रहित करू शकते. जेव्हा एखादा अतिथी त्यांच्या ईमेल पत्त्याचा किंवा सोशल प्रोफाइलचा वापर करून कनेक्ट आणि लॉग इन करतो, तेव्हा आम्ही तो डेटा गोळा करतो आणि तो एका केंद्रीकृत CRM मध्ये संग्रहित करतो. अशा प्रकारे एखादे ठिकाण कोणत्याही प्लॅटफॉर्मच्या प्रेक्षकांवर अवलंबून राहण्याऐवजी स्वतःचा फर्स्ट-पार्टी डेटा तयार करते.
लाँच करण्यापूर्वी तीन प्रश्नांची उत्तरे द्या. ॲक्सेस देण्यासाठी कोणता डेटा काटेकोरपणे आवश्यक आहे? तुम्ही ओळख आणि डिव्हाइस रेकॉर्ड किती काळ ठेवाल? अतिथी मार्केटिंग नाकारूनही ऑनलाइन जाऊ शकतो का? कोणतेही उत्तर अस्पष्ट असल्यास, डिझाइन सुधारण्यापूर्वी फॉर्म सुधारा.
प्रयत्न आणि डेटानुसार तुलना केलेल्या लॉगिन पद्धती
प्रत्येक लॉगिन पद्धत पाहुण्यांचे प्रयत्न, कॅप्चर केलेला डेटा आणि उपकरणांमधील विश्वासार्हता यांच्यात तडजोड करते. हा तक्ता वरपासून खालपर्यंत वाचा आणि ही तडजोड टप्प्याटप्प्याने कशी वाढते ते तुमच्या लक्षात येईल.
| लॉगिन पद्धत | संकलित केलेला डेटा | गेस्टचे प्रयत्न | सर्वात योग्य |
|---|---|---|---|
| फक्त नियमांसाठी क्लिक-थ्रू | फक्त डिव्हाइस नोंद | खूप कमी | जलद ॲक्सेस इच्छिणारे कॅफे |
| व्हॉउचर किंवा ॲक्सेस कोड | फक्त कोड रिडेम्पशन | कमी | प्रिंट केलेल्या किंवा पेड ॲक्सेससह हॉटेल्स आणि इव्हेंट्स |
| ईमेल नोंदणी | ईमेल पत्ता आणि मार्केटिंग ऑप्ट-इन | मध्यम | गेस्ट लिस्ट तयार करणारी ठिकाणे |
| सोशल लॉगिन | प्रदाता अनुमती देणारा प्रोफाईल डेटा | कमी | वन-टॅप साइन-इन पसंत करणारे पाहुणे |
| 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 डिव्हाइसवर चाचणी करा.
- दोन वेळापत्रके मोजा: प्रत्येक डिव्हाइसवर पोर्टलची वेळ आणि ऑथोरायझेशनची वेळ नोंदवा.
- सत्र समाप्तीची सक्ती करा: गेस्ट पुन्हा पोर्टलवर व्यवस्थित येतो आणि पुन्हा साइन इन करू शकतो याची खात्री करा.
- कनेक्ट असताना रोम करा: खाजगी MAC पत्ता सक्षम करून ॲक्सेस पॉइंट्सदरम्यान फिरून पाहा आणि प्रवेश टिकून राहतो का ते तपासा.
जेव्हा पोर्टल डिटेक्शन अयशस्वी होते, तेव्हा वापरण्यासाठी एक दस्तऐवजीकृत फॉलबॅक ठेवा, जसे की एक लहान ॲड्रेस जो कर्मचारी पाहुण्यांना मॅन्युअली उघडण्यासाठी देऊ शकतात. नेटवर्क पूर्णपणे ओपन वर स्विच करून सुरक्षा कमकुवत करू नका.
शेवटी, अतिथींना फिशिंग ओळखण्यात मदत करा. नेटवर्कचे नाव स्थळाशी जुळणारे असावे, पोर्टलचा पत्ता स्थळाच्या स्वतःच्या डोमेनवर असावा, आणि ब्राऊजरने त्या डोमेनसाठी वैध TLS प्रमाणपत्र दाखवले पाहिजे. वैध पोर्टल कधीही बँक तपशील किंवा सोशल मीडिया पासवर्ड मागत नाही.
तुमच्या विद्यमान नेटवर्कसह इंटिग्रेशन पर्याय
पोर्टल जोडण्यासाठी तुम्हाला तुमचे नेटवर्क काढून टाकण्याची गरज नाही. डिव्हाइसेसना पोर्टलचे अस्तित्व कसे समजते इथपासून सुरुवात करा, कारण ते प्रथम ब्राउझर कधीही न उघडणाऱ्या फोन्सची विश्वासार्हता ठरवते.
खालील प्रतिमा दर्शवते की पोर्टल तुमच्या ॲक्सेस पॉइंट्स आणि पाहुण्यांच्या नोंदी प्राप्त करणाऱ्या सिस्टीम्सच्या दरम्यान कसे कार्य करते.
मानकांचा मार्ग
Fortinetच्या कॅप्टिव्ह पोर्टल प्रशासन मार्गदर्शकामध्ये वर्णन केलेल्या दृष्टिकोनानुसार, नेटवर्क DHCPv4 ऑप्शन 114, DHCPv6, किंवा IPv6 राउटर जाहिरातींद्वारे त्याच्या पोर्टलच्या API एंडपॉइंटची जाहिरात कशी करते हे RFC 8910 परिभाषित करते. त्यानंतर RFC 8908 application/captive+json मीडिया प्रकार वापरून HTTPS JSON API निर्दिष्ट करते, ज्याद्वारे क्लायंट अजूनही कॅप्टिव्ह आहे की नाही, वापरकर्त्यास दिसणारा लॉगिन URI, आणि उर्वरित ॲक्सेस वेळेसारखी सत्र माहिती दर्शविली जाते.
सोप्या शब्दांत सांगायचे तर, नेटवर्क थेट ऑपरेटिंग सिस्टमला कुठे साइन इन करायचे आणि ॲक्सेस किती काळ टिकेल हे सांगते. यामुळे विशेषतः जेव्हा ॲप्स HTTPS किंवा सर्टिफिकेट पिनिंग वापरतात तेव्हा अयशस्वी रीडायरेक्ट्सवरील अवलंबित्व कमी होते. API एंडपॉइंट आणि पोर्टल या दोन्ही घटकांनी सर्टिफिकेट व्हॅलिडेशनसह TLS वापरणे आवश्यक आहे, अन्यथा एखादा हल्लेखोर अधिकृत स्थिती बनावट करू शकतो किंवा लॉगिनचे ठिकाण बदलू शकतो.
हे लहान व्हिडिओ ते इंटिग्रेशन पॉइंट्स प्रत्यक्षात कसे एकत्र बसतात याचे प्रात्यक्षिक दाखवते.
प्रत्येक कनेक्शन पॉइंट मॅप करा
पोर्टल लेयर तुमच्या विद्यमान हार्डवेअरवर कार्य करू शकते, ज्यामध्ये Cisco Meraki, HPE Aruba, आणि Ubiquiti UniFi समाविष्ट आहेत आणि ते तुमच्या साइन-इनवर समर्पित WiFi प्लॅटफॉर्मसह किंवा त्याशिवाय चालले जाऊ शकते. तुमच्या IT प्रमुखाने सेटिंग्ज निवडण्यापूर्वी चार मुद्द्यांचे मॅपिंग केले पाहिजे.
- ॲक्सेस पॉइंट कंट्रोलर: नेटवर्कचे नाव, प्रतिबंधित स्थिती आणि रीडायरेक्ट किंवा API जाहिरातीची जबाबदारी याच्याकडे असते.
- ओळख स्त्रोत: खोली क्रमांक, व्हाऊचर्स, कर्मचारी खाती किंवा सोशल साइन-इन तपासते.
- अतिथी नोंद प्रणाली: उपलब्ध Purple WiFi इंटिग्रेशन्समध्ये दाखवल्याप्रमाणे, संमती दिलेले संपर्क तपशील प्राप्त करते.
- TLS प्रमाणपत्र: अतिथींना दिसणाऱ्या पोर्टल डोमेनशी जुळणारे असणे आवश्यक आहे, ज्याचे नूतनीकरण नामांकित व्यक्तीच्या जबाबदारीत असावे.
एक निर्णय चाचणी घ्या. तुमचे नेटवर्क IPv4 आणि IPv6 वर RFC 8910 ॲडव्हर्टाइजमेंटला सपोर्ट करत असल्यास, ते सुरू ठेवा आणि JSON रिस्पॉन्सची चाचणी घ्या. तसे नसल्यास, दस्तऐवजीकृत फॉलबॅकसह ब्राउझर-आधारित रिडायरेक्टचे नियोजन करा.
तुमच्या ठिकाणाला आवश्यक असलेले पोर्टल सेटअप निवडा
एकाच साइन-इन स्क्रीनमध्ये तीन वेगवेगळे निर्णय लपलेले असतात: नेटवर्क ॲक्सेस, अटींची स्वीकृती आणि मार्केटिंग संमती. ॲक्सेसमुळे डिव्हाइस नेटवर्कवर येते. अटींच्या स्वीकृतीमुळे अतिथीने तुमच्या नियमांना संमती दिल्याचे नोंदवले जाते. मार्केटिंग संमती हा एक ऐच्छिक (opt-in) पर्याय आहे आणि WiFi अटी स्वीकारल्याने तो आपोआप मिळत नाही. या सर्व गोष्टींना एकाच टिक बॉक्समध्ये समाविष्ट करणारा सेटअप एकतर अशी संमती गोळा करतो जी तुम्ही वापरू शकत नाही, किंवा सहर्ष लॉग इन करू इच्छिणाऱ्या अतिथींना ब्लॉक करतो.
तीन सुरुवातीचे मुद्दे
जलद ॲक्सेस आणि ऑप्ट-इन सूचीची गरज असलेल्या कॅफेने अटींनुसार ऐच्छिक ईमेल वापरला पाहिजे. पाहुण्याने (गेस्ट) सक्रियपणे निवड केल्यावरच ईमेल फील्ड आणि मार्केटिंग ऑप्ट-इन दिसतात. प्रथम गेस्ट रेकॉर्ड सिस्टम तपासा, जेणेकरून नवीन संपर्क उपयुक्त ठिकाणी नोंदवले जातील.
बुकिंगशी ॲक्सेस जोडणाऱ्या हॉटेलने रूम किंवा बुकिंग पडताळणी, अथवा चेक-इन वेळी दिलेल्या व्हॉउचर्सचा वापर केला पाहिजे. ॲक्सेस ऑथराइज करण्यासाठी आवश्यक असलेला स्टे रेफरन्स Capture करा, अतिरिक्त प्रोफाईल फील्ड्स नाही. ओळखीचा स्रोत प्रथम तपासा, कारण फ्रंट डेस्क कर्मचारी न जुळणाऱ्या गोष्टींचे निवारण करतील.
सुसंगततेची गरज असलेल्या बहु-साइट गटाने सर्व साइट्सवर एकच संमती नोंद आणि रिपोर्टिंग प्रमाणित केले पाहिजे. सर्वत्र एकाच स्वतंत्र ऑप्ट-इनसह ईमेल नोंदणीचा अर्थ असा आहे की प्रत्येक साइट नाकारलेल्या विनंत्या एकाच प्रकारे हाताळते. प्रथम रिपोर्टिंग आणि डेटा रिटेंशन तपासा.
पोर्टल कधीही पाहणार नाही अशी उपकरणे
कॅप्टिव्ह पोर्टल केवळ अशा हार्डवेअरवरच कार्य करते जे ब्राऊजर उघडू शकते. स्मार्ट टीव्ही, प्रिंटर, टिल टर्मिनल्स आणि खोलीतील गॅझेट्सकडे पेज प्रदर्शित करण्यासाठी काहीही नसते, त्यामुळे ते अनिश्चित काळासाठी प्रतिबंधित स्थितीत राहतात. त्या उपकरणांना एक वेगळा मार्ग द्या, जसे की कर्मचाऱ्यांच्या किंवा डिव्हाइस नेटवर्कवरील प्रति-डिव्हाइस की, आणि जे फोन व लॅपटॉप लॉगिन दाखवू शकतात त्यांच्यासाठीच पोर्टल राखीव ठेवा.
लाँच करण्यापूर्वी, तुमचे हार्डवेअर मानकांच्या मार्गाला सपोर्ट करते किंवा तुमचा फॉलबॅक दस्तऐवजीकृत आहे याची खात्री करा. केवळ ऑफिसमधील लॅपटॉपनेच नव्हे, तर वास्तविक पाहुण्यांच्या डिव्हाइसेससह डिव्हाइस, मुदत समाप्ती, रोमिंग आणि IPv6 चाचण्या करा.
Purple Engage ज्या स्थळांना साइन-इनचा वापर पुढील मार्केटिंगसाठी करायचा आहे त्यांच्यासाठी योग्य आहे. ही प्रत्यक्ष ठिकाणांसाठीची एक ऑल-इन-वन मार्केटिंग प्रणाली आहे जी प्रत्येक WiFi साइन-इनचे रूपांतर पुनर्भेटीत करते, मग ते Purple WiFi सह असो वा त्याशिवाय, आणि कोणत्या मोहिमांनी हे केले हे सिद्ध करते. ही प्रणाली WiFi साइन-इन, टिल विक्री, बुकिंग, फॉर्म्स, फाइल्स, संदेश आणि सर्वेक्षणातील उत्तरांना ईमेलद्वारे जुळणाऱ्या एका अतिथी नोंदीमध्ये एकत्रित करते. हे Purple WiFi सह किंवा त्याशिवाय कार्य करत असल्यामुळे आणि आपल्या विद्यमान प्रणाली वाचत असल्यामुळे, आपण आपल्या सध्या वापरत असलेल्या हार्डवेअर आणि टिल्सशी ते कनेक्ट करू शकता.
या आठवड्यात एक गोष्ट करा. तुमच्या पोर्टलने कोणता एक परिणाम दिलाच पाहिजे ते लिहून ठेवा, नंतर तुमची लॉगिन पद्धत, डेटा फील्ड्स आणि पहिली इंटिग्रेशन तपासणी त्या परिणामाशी मॅप करा.
जर तुम्ही WiFi साठी कॅप्टिव्ह पोर्टल सेट करत असाल आणि संमती असलेले प्रत्येक साइन-इन एक उपयुक्त गेस्ट रेकॉर्ड बनवायचे असेल, तर Purple Engage हे WiFi मधील साइन-इन, टिल विक्री, बुकिंग, फॉर्म आणि सर्वेक्षणाची उत्तरे एकाच ठिकाणी एकत्र आणते. तुम्ही आधीपासून वापरत असलेल्या हार्डवेअरवर हे कसे कार्य करते आणि ते पहिल्या कनेक्शनला परत भेटीत बदलण्यास कशी मदत करते हे पाहण्यासाठी वेबसाइटला भेट द्या.