মূল কন্টেন্টে যান

গেস্ট WiFi ক্যাপটিভ পোর্টাল-এর সাথে WeChat অথেন্টিকেশন ইন্টিগ্রেট করা

এই গাইডটি ব্যাখ্যা করে কীভাবে এন্টারপ্রাইজ গেস্ট WiFi ক্যাপটিভ পোর্টাল-এ WeChat OAuth 2.0 অথেন্টিকেশন ইন্টিগ্রেট করতে হয়। এতে ডুয়াল-প্ল্যাটফর্ম রেজিস্ট্রেশনের প্রয়োজনীয়তা, ফার্স্ট-পার্টি ডেটা সংগ্রহের জন্য স্কোপ নির্বাচন, RADIUS Change of Authorization-এর মাধ্যমে নেটওয়ার্ক প্রয়োগ এবং GDPR ও চীনের PIPL-এর সাথে কমপ্লায়েন্সের বিষয়গুলো আলোচনা করা হয়েছে। হসপিটালিটি, রিটেইল এবং ইভেন্ট খাতের ভেন্যু অপারেটররা এখানে স্কেলে WeChat লগইন গেস্ট WiFi স্থাপন করার জন্য সুনির্দিষ্ট বাস্তবায়ন পদক্ষেপ, বাস্তব-জগতের কেস স্টাডি এবং সিকিউরিটি হার্ডেনিং গাইডলাইন পাবেন।

📖 8 মিনিট পাঠ📝 1,966 শব্দ🔧 2 সমাধানকৃত উদাহরণ4 অনুশীলনী প্রশ্ন📚 9 মূল সংজ্ঞা

এই গাইডটি শুনুন

পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
ক্যাপটিভ পোর্টাল-এর জন্য WECHAT OAUTH অথেন্টিকেশন কীভাবে কনফিগার করবেন একটি Purple টেকনিক্যাল ব্রিফিং - প্রায় ১০ মিনিট --- ভূমিকা এবং প্রেক্ষাপট (প্রায় ১ মিনিট) স্বাগতম। আপনি যদি কোনো হোটেল, রিটেইল চেইন, স্টেডিয়াম বা কনফারেন্স সেন্টারে গেস্ট WiFi-এর জন্য দায়ী হন যা চীনা ভিজিটরদের সেবা দেয়, তবে এই ব্রিফিংটি আপনার জন্য। Tencent-এর ২০২৪ সালের ডেটা অনুসারে, WeChat-এর মাসিক সক্রিয় ব্যবহারকারীর সংখ্যা ১.৩৮ বিলিয়ন। এর সিংহভাগই চীনে, তবে প্ল্যাটফর্মটির একটি অর্থপূর্ণ আন্তর্জাতিক উপস্থিতি রয়েছে - মার্কিন যুক্তরাষ্ট্রে চার মিলিয়ন ব্যবহারকারী, মালয়েশিয়ায় ১২ মিলিয়ন এবং দক্ষিণ-পূর্ব এশিয়া, ইউরোপ এবং মধ্যপ্রাচ্য জুড়ে ক্রমবর্ধমান সংখ্যা। যখন একজন চীনা গেস্ট আপনার WiFi-এর সাথে সংযুক্ত হন এবং কেবল ইমেল, Facebook বা একটি ভাউচার কোড সহ একটি লগইন পেজ দেখেন, তখন তারা তাৎক্ষণিক বাধার সম্মুখীন হন। তাদের সেই ডিভাইসে একটি স্থানীয় ইমেল ঠিকানা সেট আপ নাও থাকতে পারে। তাদের প্রায় নিশ্চিতভাবেই WeChat আছে। তাই প্রশ্নটি এটি নয় যে আপনার WeChat লগইন অফার করা উচিত কিনা - প্রশ্নটি হলো কীভাবে এটি সঠিকভাবে, নিরাপদে এবং এমনভাবে কনফিগার করবেন যা ফার্স্ট-পার্টি ডেটা তৈরি করে যা আপনি আসলে ব্যবহার করতে পারেন। আজ আমরা সেটাই কভার করতে যাচ্ছি। আমরা OAuth 2.0 ফ্লো, আপনার প্রয়োজনীয় দুটি প্ল্যাটফর্ম রেজিস্ট্রেশন, স্কোপের সিদ্ধান্ত যা নির্ধারণ করে আপনি কী ডেটা সংগ্রহ করবেন, নেটওয়ার্ক-সাইড প্রয়োগের প্রক্রিয়া এবং ২০২৬ সালে গুরুত্বপূর্ণ কমপ্লায়েন্সের বিষয়গুলো নিয়ে আলোচনা করব। --- টেকনিক্যাল ডিপ াইভ (প্রায় ৫ মিনিট) আসুন আর্কিটেকচার দিয়ে শুরু করা যাক। একটি ক্যাপটিভ পোর্টাল একটি অথেন্টিকেট না করা ডিভাইস থেকে 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 স্কোপের অনুরোধ করে থাকেন, তবে আপনি ব্যবহারকারীর ডাকনাম, অবতার, লিঙ্গ এবং শহর পুনরুদ্ধার করতে একটি দ্বিতীয় API কল করতে পারেন। এখন, দুটি প্ল্যাটফর্ম রেজিস্ট্রেশন। এখানেই বেশিরভাগ বাস্তবায়ন ভুল হয়। WeChat-এর দুটি পৃথক ডেভেলপার প্ল্যাটফর্ম রয়েছে। WeChat Open Platform ওয়েবসাইট অ্যাপ্লিকেশন এবং মোবাইল অ্যাপ পরিচালনা করে। WeChat Official Accounts Platform পাবলিক অ্যাকাউন্ট পরিচালনা করে - যা বেশিরভাগ ভেন্যুর আসলে প্রয়োজন। WeChat ইন-অ্যাপ ব্রাউজারের ভিতরে গেস্টদের সেবা প্রদানকারী একটি ক্যাপটিভ পোর্টাল-এর জন্য, আপনার Official Accounts Platform-এ একটি সার্ভিস অ্যাকাউন্ট প্রয়োজন। একটি সাবস্ক্রিপশন অ্যাকাউন্ট কাজ করবে না - এটিতে OAuth ওয়েব পেজ অথরাইজেশন পারমিশন নেই। একটি সার্ভিস অ্যাকাউন্টে এটি রয়েছে এবং এটি snsapi base এবং snsapi userinfo উভয় স্কোপই সমর্থন করে। WeChat-এর বাইরে একটি স্ট্যান্ডার্ড মোবাইল ব্রাউজার - Android-এ Chrome, iOS-এ Safari - থেকে অ্যাক্সেস করা একটি ক্যাপটিভ পোর্টাল-এর জন্য, আপনার Open Platform-এ রেজিস্টার করা একটি ওয়েবসাইট অ্যাপ্লিকেশন প্রয়োজন। এটি snsapi login স্কোপ ব্যবহার করে এবং একটি QR কোড উপস্থাপন করে যা ব্যবহারকারী তাদের WeChat অ্যাপ দিয়ে স্ক্যান করেন। বাস্তবে, বেশিরভাগ ভেন্যু স্থাপনায় উভয়ই ব্যবহৃত হয়। একটি হোটেলের WiFi-এ থাকা একজন গেস্ট Chrome-এ পোর্টালটি খুলতে পারেন, একটি QR কোড দেখতে পারেন, এটি WeChat দিয়ে স্ক্যান করতে পারেন এবং অথেন্টিকেট করতে পারেন। অথবা তারা স্বয়ং WeChat-এর একটি লিঙ্ক অনুসরণ করতে পারেন, ইন-অ্যাপ ব্রাউজারে ল্যান্ড করতে পারেন এবং snsapi base দিয়ে নীরবে অথেন্টিকেট করতে পারেন। আসুন স্কোপ নির্বাচন নিয়ে কথা বলি, কারণ এটি একটি বাস্তব সিদ্ধান্ত গ্রহণের বিষয়। snsapi base কেবল Open ID ফেরত দেয় - যা আপনার অফিশিয়াল অ্যাকাউন্টের মধ্যে সেই ব্যবহারকারীর জন্য একটি অনন্য আইডেন্টিফায়ার। এর জন্য কোনো ব্যবহারকারীর সম্মতি প্রম্পটের প্রয়োজন হয় না। অথেন্টিকেশনটি ব্যবহারকারীর কাছে অদৃশ্য থাকে। এটি ফিরে আসা গেস্টদের জন্য আদর্শ যাদের আপনি ইতিমধ্যে প্রোফাইল করেছেন, বা এমন ভেন্যুগুলোর জন্য যেখানে আপনি শূন্য বাধা চান। snsapi userinfo-এ Open ID-এর সাথে ব্যবহারকারীর WeChat ডাকনাম, প্রোফাইল ছবি, লিঙ্গ, ভাষা সেটিং এবং শহর ফেরত দেওয়া হয়। এর জন্য একটি স্পষ্ট সম্মতি স্ক্রিনের প্রয়োজন হয়। বেশিরভাগ ব্যবহারকারী এটি গ্রহণ করেন, তবে বাধা থাকে। সদুপায়টি আপনার ব্যবহারের ক্ষেত্রের ওপর নির্ভর করে। প্রথমবার আসা গেস্ট রেজিস্ট্রেশনের জন্য যেখানে আপনি একটি প্রোফাইল তৈরি করতে চান, সেখানে snsapi userinfo ব্যবহার করুন এবং আপনার পোর্টাল পেজে একটি GDPR-কমপ্লায়েন্ট সম্মতি লেয়ারের সাথে এটি যুক্ত করুন। ফিরে আসা গেস্টের জন্য যিনি ইতিমধ্যে সম্মতি দিয়েছেন এবং যার প্রোফাইল আপনার কাছে ইতিমধ্যে রয়েছে, নীরব পুনরায় অথেন্টিকেশনের জন্য snsapi base ব্যবহার করুন। এখন, নেটওয়ার্ক প্রয়োগের দিকটি। একটি OAuth টোকেন প্রাপ্তি পরিচয় প্রমাণ করে, তবে এটি স্বয়ংক্রিয়ভাবে নেটওয়ার্ক উন্মুক্ত করে না। একটি সফল অথেন্টিকেশনকে নেটওয়ার্ক অ্যাক্সেসে অনুবাদ করার জন্য আপনার একটি প্রক্রিয়া প্রয়োজন। দুটি স্ট্যান্ডার্ড পদ্ধতি হলো RADIUS Change of Authorisation, যা RFC 3576-এ সংজ্ঞায়িত, এবং MAC address bypass। RADIUS CoA-এর মাধ্যমে, আপনার পোর্টাল সার্ভার সফল OAuth-এর পর নেটওয়ার্ক কন্ট্রোলারে একটি CoA অনুরোধ পাঠায় এবং কন্ট্রোলার ডিভাইসটিকে প্রি-অথেন্টিকেশন VLAN থেকে গেস্ট VLAN-এ স্থানান্তরিত করে। এটি Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist এবং বেশিরভাগ এন্টারপ্রাইজ-গ্রেড কন্ট্রোলারের সাথে কাজ করে। MAC bypass-এর মাধ্যমে, পোর্টাল সার্ভার ডিভাইসের MAC অ্যাড্রেসটিকে একটি অনুমোদিত ক্লায়েন্ট হিসেবে রেজিস্টার করে এবং কন্ট্রোলার এটিকে অনুমতি দেয়। MAC bypass বাস্তবায়ন করা সহজ কিন্তু কম নিরাপদ, কারণ MAC অ্যাড্রেস স্পুফ করা যেতে পারে। Purple-এর Guest WiFi প্ল্যাটফর্ম উভয় প্রক্রিয়াই পরিচালনা করে। WeChat OAuth সম্পন্ন হওয়ার পর, Purple-এর ক্লাউড ওভারলে অন্তর্নিহিত হার্ডওয়্যারে উপযুক্ত সংকেত পাঠায় - তা Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme বা Fortinet যাই হোক না কেন। ভেন্যু অপারেটরকে ম্যানুয়ালি সেই অনুবাদ পরিচালনা করতে হবে না। --- বাস্তবায়ন সুপারিশ এবং ত্রুটিসমূহ (প্রায় ২ মিনিট) আসুন আমি আপনাকে পাঁচটি বিষয় বলি যা WeChat OAuth ক্যাপটিভ পোর্টাল বাস্তবায়নকে ব্যর্থ করে। প্রথম: রিডাইরেক্ট URI-এর অমিল। WeChat প্ল্যাটফর্মে আপনার রেজিস্টার করা অনুমোদিত ডোমেনের বিপরীতে রিডাইরেক্ট URI যাচাই করে। যদি আপনার পোর্টাল সার্ভার একটি ভিন্ন সাবডোমেন, একটি ভিন্ন পাথ বা HTTPS-এর পরিবর্তে HTTP ব্যবহার করে, তবে OAuth ফ্লো ৪০০২৯ ত্রুটি - অবৈধ কোড সহ ব্যর্থ হয়। স্টেজিং এনভায়রনমেন্ট সহ আপনার ব্যবহৃত প্রতিটি ডোমেন ভেরিয়েন্ট রেজিস্টার করুন। দ্বিতীয়: ক্লায়েন্ট সাইডে App Secret। আপনার App Secret কখনই ক্লায়েন্ট-সাইড JavaScript-এ প্রদর্শিত হওয়া উচিত নয়। এটি আপনার সার্ভারে থাকা উচিত। যদি এটি প্রকাশ পায়, তবে যে কেউ আপনার অ্যাপ্লিকেশনের ছদ্মবেশ ধারণ করতে পারে এবং আপনার পক্ষে WeChat-এর API কল করতে পারে। তৃতীয়: CSRF প্রোটেকশনের অভাব। OAuth অনুরোধে state প্যারামিটারটি বিশেষভাবে ক্রস-সাইট রিকোয়েস্ট ফোরজারি প্রতিরোধ করার জন্য বিদ্যমান। একটি ক্রিপ্টোগ্রাফিকভাবে র্যান্ডম state মান তৈরি করুন, এটি ব্যবহারকারীর সেশনে সংরক্ষণ করুন এবং WeChat রিডাইরেক্ট ফিরে আসার সময় এটি যাচাই করুন। এটি এড়িয়ে গেলে আপনার একটি বাস্তব দুর্বলতা তৈরি হবে। চতুর্থ: ইন-অ্যাপ ব্রাউজার সনাক্তকরণের ঘাটতি। WeChat-এর ইন-অ্যাপ ব্রাউজার একটি নির্দিষ্ট ইউজার এজেন্ট স্ট্রিং সেট করে যাতে MicroMessenger থাকে। যদি আপনার পোর্টাল এটি সনাক্ত করতে এবং সঠিক OAuth ফ্লো পরিবেশন করতে ব্যর্থ হয়, তবে ব্যবহারকারীরা একটি ত্রুটিপূর্ণ অভিজ্ঞতা বা একটি ত্রুটি পাবেন। পঞ্চম: GDPR এবং PIPL সামঞ্জস্য। আপনি যদি ইউরোপীয় ভিজিটরদের সেবা দেন, তবে GDPR প্রযোজ্য। আপনি যদি চীনা ভিজিটরদের সেবা দেন, তবে চীনের Personal Information Protection Law - PIPL - প্রযোজ্য। উভয়ের জন্যই প্রক্রিয়াকরণের একটি আইনি ভিত্তি, স্পষ্ট উদ্দেশ্যের সীমাবদ্ধতা এবং ডেটা মিনিমাইজেশন প্রয়োজন। ডেটা মিনিমাইজেশন নীতির অধীনে snsapi base সমর্থন করা snsapi userinfo-এর চেয়ে সহজ। আপনি যা সংগ্রহ করুন না কেন, আপনার আইনি ভিত্তি এবং আপনার সংরক্ষণের সময়কাল নথিভুক্ত করুন। --- র‌্যাপিড-ফায়ার প্রশ্নোত্তর (প্রায় ১ মিনিট) আমি কি এমন একটি পোর্টালে WeChat লগইন ব্যবহার করতে পারি যা ইমেল এবং SMS লগইনও অফার করে? হ্যাঁ। Purple সহ বেশিরভাগ এন্টারপ্রাইজ পোর্টাল প্ল্যাটফর্ম একই পোর্টাল পেজে একাধিক অথেন্টিকেশন পদ্ধতি সমর্থন করে। WeChat OAuth কি iOS-এ কাজ করে? হ্যাঁ। iOS-এ Safari-তে WeChat লগইন QR কোড ফ্লো বা রিডাইরেক্ট ফ্লোর মাধ্যমে কাজ করে। WeChat অ্যাপ নিজেই অথেন্টিকেশন পরিচালনা করে। WeChat-এর API অনুপলব্ধ হলে কী হবে? একটি ফলব্যাক বাস্তবায়ন করুন। যদি WeChat API কল টাইম আউট হয় বা কোনো ত্রুটি ফেরত দেয়, তবে ব্যবহারকারীকে একটি বিকল্প লগইন পদ্ধতিতে রিডাইরেক্ট করুন। আমি কি একটি স্থায়ী গ্রাহক আইডেন্টিফায়ার হিসেবে Open ID ব্যবহার করতে পারি? আপনার অফিশিয়াল অ্যাকাউন্টের মধ্যে, হ্যাঁ। একাধিক প্রপার্টি জুড়ে ক্রস-অ্যাকাউন্ট পরিচয় সনাক্তকরণের জন্য, পরিবর্তে UnionID ব্যবহার করুন। --- সারসংক্ষেপ এবং পরবর্তী পদক্ষেপ (প্রায় ১ মিনিট) সংক্ষেপে বলতে গেলে। ক্যাপটিভ পোর্টাল-এর জন্য WeChat OAuth অথেন্টিকেশন হলো একটি ডুয়াল-প্ল্যাটফর্ম রেজিস্ট্রেশন অনুশীলন, একটি স্কোপের সিদ্ধান্ত, একটি নেটওয়ার্ক প্রয়োগের ইন্টিগ্রেশন এবং একটি কমপ্লায়েন্স পর্যালোচনা। এই চারটি জিনিস সঠিকভাবে করুন এবং আপনার কাছে এমন একটি লগইন পদ্ধতি থাকবে যা কোনো পাসওয়ার্ডের ঝামেলা ছাড়াই এক বিলিয়নেরও বেশি সম্ভাব্য ভিজিটরকে সেবা দেয়। ব্যবহারিক পরবর্তী পদক্ষেপগুলো: আপনার ভিজিটররা WeChat ইন-অ্যাপ ব্রাউজারের ভিতরে নাকি স্ট্যান্ডার্ড মোবাইল ব্রাউজারে পোর্টালের মুখোমুখি হন তা নির্ধারণ করুন। স্কোপের বিষয়ে সিদ্ধান্ত নিন - ফিরে আসা গেস্টদের জন্য snsapi base, সম্মতির সাথে প্রথমবার রেজিস্ট্রেশনের জন্য snsapi userinfo। আপনার নেটওয়ার্ক হার্ডওয়্যার RADIUS CoA সমর্থন করে কিনা তা নিশ্চিত করুন। GDPR এবং PIPL-এর বিপরীতে আপনার গোপনীয়তা নোটিশ পর্যালোচনা করুন। লাইভ হওয়ার আগে রিডাইরেক্ট URI, state প্যারামিটার যাচাইকরণ এবং ইন-অ্যাপ ব্রাউজার সনাক্তকরণ পরীক্ষা করুন। আপনি যদি দেখতে চান কীভাবে Purple একটি বিস্তৃত Guest WiFi এবং অ্যানালিটিক্স প্ল্যাটফর্মের অংশ হিসেবে WeChat OAuth পরিচালনা করে - ২০২৪ সালে ৮০,০০০ ভেন্যু এবং ৪৪০ মিলিয়ন লগইন জুড়ে - তবে purple.ai ভিজিট করুন বা আপনার অ্যাকাউন্ট টিমের সাথে কথা বলুন। শোনার জন্য ধন্যবাদ। --- স্ক্রিপ্টের সমাপ্তি

header_image.png

সারসংক্ষেপ

যখন একজন চীনা ভিজিটর আপনার এন্টারপ্রাইজ নেটওয়ার্কে সংযুক্ত হন এবং এমন একটি ক্যাপটিভ পোর্টাল-এর মুখোমুখি হন যা কেবল ইমেল, Facebook বা ক্রেডেনশিয়াল কোড অফার করে, তখন আপনি তাৎক্ষণিক বাধা তৈরি করেন। Tencent-এর ২০২৪ সালের ডেটা অনুসারে, WeChat-এর মাসিক সক্রিয় ব্যবহারকারীর সংখ্যা ১.৩৮ বিলিয়ন। গেস্ট WiFi-এর সাথে WeChat লগইন ইন্টিগ্রেট করা কেবল একটি হসপিটালিটি সুবিধা নয়; এটি কোনো বাধা ছাড়াই এই ডেমোগ্রাফিক থেকে ফার্স্ট-পার্টি ডেটা ক্যাপচার করার জন্য একটি প্রযুক্তিগত প্রয়োজনীয়তা।

এই গাইডটি ক্যাপটিভ পোর্টাল-এর সাথে WeChat OAuth 2.0 অথেন্টিকেশন ইন্টিগ্রেট করার প্রযুক্তিগত আর্কিটেকচার বিস্তারিতভাবে বর্ণনা করে। এটি স্ট্যান্ডার্ড মোবাইল ব্রাউজারের পাশাপাশি WeChat ইন-অ্যাপ ব্রাউজারকে সমর্থন করার জন্য প্রয়োজনীয় ডুয়াল-প্ল্যাটফর্ম রেজিস্ট্রেশন ব্যাখ্যা করে, ডেটা সংগ্রহের জন্য snsapi_base এবং snsapi_userinfo স্কোপের মধ্যে আপস মূল্যায়ন করে এবং কীভাবে RADIUS Change of Authorization (CoA) বা MAC Authentication Bypass ব্যবহার করে নেটওয়ার্ক অ্যাক্সেস প্রয়োগ করা হয় তা রূপরেখা দেয়। এটি Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet ইনফ্রাস্ট্রাকচার জুড়ে বড় আকারের স্থাপনার জন্য প্রয়োজনীয় সিকিউরিটি কনফিগারেশন এবং কমপ্লায়েন্স নির্দেশাবলী—GDPR এবং চীনের Personal Information Protection Law (PIPL)—কভার করে।


টেকনিক্যাল ডিপ ডাইভ: WeChat OAuth 2.0 আর্কিটেকচার

একটি ক্যাপটিভ পোর্টাল অথেন্টিকেট না করা ডিভাইস থেকে HTTP ট্রাফিক ইন্টারসেপ্ট করে এবং সেগুলোকে একটি পোর্টাল সার্ভারে হোস্ট করা ল্যান্ডিং পেজে রিডাইরেক্ট করে। WeChat অথেন্টিকেশন যুক্ত করার ফলে OAuth 2.0 প্রোটোকল ব্যবহার করে এই ফ্লোতে একটি থার্ড-পার্টি আইডেন্টিটি প্রোভাইডার যুক্ত হয়, যা ফেডারেটেড আইডেন্টিটির জন্য Google, Microsoft Entra ID এবং Okta দ্বারা ব্যবহৃত একই স্ট্যান্ডার্ড।

oauth_flow_diagram.png

অথেন্টিকেশন ফ্লোটি নিম্নরূপ কাজ করে: একজন ভিজিটর SSID-এর সাথে সংযুক্ত হন। অ্যাক্সেস পয়েন্ট বা ওয়্যারলেস কন্ট্রোলার অথেন্টিকেট না করা সেশনটি সনাক্ত করে এবং HTTP ট্রাফিককে ক্যাপটিভ পোর্টাল URL-এ রিডাইরেক্ট করে। ভিজিটর পোর্টাল পেজে WeChat লগইন নির্বাচন করেন। পোর্টাল সার্ভার ব্রাউজারটিকে open.weixin.qq.com-এ WeChat অথরাইজেশন এন্ডপয়েন্টে রিডাইরেক্ট করে, যেখানে AppID, রিডাইরেক্ট URI, code-এর রেসপন্স টাইপ এবং অনুরোধ করা স্কোপ পাস করা হয়। WeChat তার নিজস্ব সার্ভারে অথেন্টিকেশন পরিচালনা করে। ভিজিটর যদি snsapi_base স্কোপ ব্যবহার করে WeChat বিল্ট-ইন ব্রাউজারের ভিতরে থাকেন, তবে অথেন্টিকেশনটি নীরবে সম্পন্ন হয়—কোনো অথরাইজেশন সম্মতি প্রম্পট প্রদর্শিত হয় না। যদি snsapi_userinfo ব্যবহার করা হয়, তবে WeChat একটি অথরাইজেশন সম্মতি পেজ প্রদর্শন করে। এরপর WeChat একটি অস্থায়ী অথরাইজেশন কোড সহ পোর্টালের রিডাইরেক্ট URI-তে ফেরত পাঠায়। পোর্টাল সার্ভার AppID, AppSecret, কোড এবং authorization_code-এর গ্রান্ট টাইপ সহ api.weixin.qq.com/sns/oauth2/access_token-এ একটি API কল করে এই কোডটি একটি অ্যাক্সেস টোকেনের সাথে বিনিময় করে। WeChat অ্যাক্সেস টোকেন, রিফ্রেশ টোকেন, ব্যবহারকারীর OpenID এবং মঞ্জুর করা স্কোপ ফেরত দেয়। যদি snsapi_userinfo মঞ্জুর করা হয়, তবে সার্ভার ব্যবহারকারীর ডাকনাম, প্রোফাইল ছবি, লিঙ্গ এবং শহর সংগ্রহ করতে একটি দ্বিতীয় API কল শুরু করে।

ডুয়াল-প্ল্যাটফর্ম রেজিস্ট্রেশনের প্রয়োজনীয়তা

বেশিরভাগ বাস্তবায়ন রেজিস্ট্রেশন পর্যায়ে ব্যর্থ হয়। WeChat দুটি পৃথক ডেভেলপার প্ল্যাটফর্ম পরিচালনা করে এবং এন্টারপ্রাইজ স্থাপনার জন্য সাধারণত উভয়েরই প্রয়োজন হয়।

প্ল্যাটফর্ম URL প্রয়োজনীয় অ্যাকাউন্টের ধরন সমর্থিত স্কোপ ব্রাউজার এনভায়রনমেন্ট
Official Accounts Platform mp.weixin.qq.com সার্ভিস অ্যাকাউন্ট snsapi_base, snsapi_userinfo WeChat ইন-অ্যাপ ব্রাউজার
Open Platform open.weixin.qq.com ওয়েব অ্যাপ্লিকেশন snsapi_login স্ট্যান্ডার্ড মোবাইল ব্রাউজার

WeChat ইন-অ্যাপ ব্রাউজারের ভিতরে পোর্টাল অ্যাক্সেস করা ভিজিটরদের জন্য, আপনার Official Accounts Platform-এ একটি সার্ভিস অ্যাকাউন্ট প্রয়োজন। সাবক্রিপশন অ্যাকাউন্টগুলো কাজ করবে না—সেগুলোতে OAuth ওয়েবপেজ অথরাইজেশন পারমিশন নেই। Android-এ Chrome বা iOS-এ Safari থেকে পোর্টাল অ্যাক্সেস করা ভিজিটরদের জন্য, আপনার Open Platform-এ একটি ওয়েব অ্যাপ্লিকেশন প্রয়োজন, যা snsapi_login স্কোপ ব্যবহার করে এবং ব্যবহারকারীকে স্ক্যান করার জন্য একটি QR কোড প্রদর্শন করে।

বাস্তবে, বেশিরভাগ ভেন্যু স্থাপনায় উভয়ই ব্যবহৃত হয়। একজন হোটেল গেস্ট Chrome-এ পোর্টালটি খুলতে পারেন, একটি QR কোড দেখতে পারেন, এটি WeChat দিয়ে স্ক্যান করতে পারেন এবং অথেন্টিকেট করতে পারেন। অথবা তারা সরাসরি WeChat-এর মধ্যে একটি লিঙ্কে ট্যাপ করতে পারেন, ইন-অ্যাপ ব্রাউজারে প্রবেশ করতে পারেন এবং snsapi_base-এর মাধ্যমে নীরবে অথেন্টিকেট করতে পারেন।

স্কোপ নির্বাচন: ডেটা সংগ্রহ বনাম ব্যবহারকারীর বাধা

scope_comparison.png

আপনার অনুরোধ করা স্কোপটি নির্ধারণ করে যে আপনি কী ডেটা সংগ্রহ করবেন এবং ভিজিটর কী ধরনের বাধার সম্মুখীন হবেন। এটি কমপ্লায়েন্সের প্রভাব সহ একটি ব্যবহারিক সিদ্ধান্ত গ্রহণের বিষয়।

snsapi_base কেবল OpenID ফেরত দেয়—যা আপনার অফিশিয়াল অ্যাকাউন্টের মধ্যে সেই ব্যবহারকারীর জন্য অনন্য আইডেন্টিফায়ার। এর জন্য কোনো ব্যবহারকারীর সম্মতি প্রম্পটের প্রয়োজন হয় না। ভিজিটরের জন্য অথেন্টিকেশন নীরবে সম্পন্ন হয়। এটি ফিরে আসা ভিজিটরদের জন্য আদর্শ যাদের প্রোফাইল ইতিমধ্যে আপনার কাছে রয়েছে, অথবা যখন আপনি বাধাহীন অ্যাক্সেসকে অগ্রাধিকার দেন। GDPR এবং PIPL ডেটা মিনিমাইজেশন নীতির অধীনে, snsapi_base সমর্থন করা অনেক সহজ।

snsapi_userinfo OpenID-এর সাথে ব্যবহারকারীর ডাকনাম, প্রোফাইল ছবি, লিঙ্গ এবং শহর ফেরত দেয়। এর জন্য একটি স্পষ্ট অথরাইজেশন সম্মতি পেজের প্রয়োজন হয়। এটি প্রথমবার আসা ভিজিটর রেজিস্ট্রেশনের জন্য আদর্শ যেখানে আপনার একটি প্রোফাইল তৈরি করতে হবে, যা আপনার পোর্টাল পেজে একটি কমপ্লায়েন্ট সম্মতি ওভারলের সাথে যুক্ত থাকে।

মাল্টি-সাইট স্থাপনার জন্য UnionID

একটি OpenID একজন ব্যবহারকারী এবং একটি নির্দিষ্ট অফিশিয়াল অ্যাকাউন্টের সংমিশ্রণের জন্য অনন্য। ২০টি প্রপার্টি বিশিষ্ট একটি হোটেল গ্রুপ, যার প্রতিটি নিজস্ব অফিশিয়াল অ্যাকাউন্ট চালাচ্ছে, তারা একই ভিজিটরের জন্য ২০টি ভিন্ন OpenID দেখতে পাবে। UnionID এই সমস্যার সমাধান করে। এটি একটি একক আইডেন্টিফায়ার যা একই Open Platform অ্যাকাউন্টের অধীনে লিঙ্ক করা সমস্ত অফিশিয়াল অ্যাকাউন্ট এবং অ্যাপ্লিকেশন জুড়ে একজন ব্যবহারকারীকে প্রতিনিধিত্ব করে। আপনার অফিশিয়াল অ্যাকাউন্টগুলোকে আপনার Open Platform অ্যাকাউন্টের সাথে লিঙ্ক করুন, এবং OAuth রেসপন্সে UnionID ফেরত দেওয়া হবে। এটি ক্রস-সাইট ভিজিটর সনাক্তকরণের ভিত্তি।


বাস্তবায়ন গাইড

নেটওয়ার্ক প্রয়োগের প্রক্রিয়া

একটি 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) RADIUS ডেটাবেসে একটি অনুমোদিত ক্লায়েন্ট হিসেবে ডিভাইসের MAC অ্যাড্রেস রেজিস্টার করে। কন্ট্রোলার এই MAC-এর ওপর ভিত্তি করে অ্যাক্সেসের অনুমতি দেয়। MAB বাস্তবায়ন করা সহজ কিন্তু কম নির্ভরযোগ্য: আধুনিক iOS এবং Android ডিভাইসগুলো ডিফল্টরূপে MAC অ্যাড্রেস র্যান্ডমাইজ করে, যা পুনরায় সংযোগ করার সময় সেশন অ্যাসোসিয়েশন ভেঙে দেয়।

Purple-এর Guest WiFi প্ল্যাটফর্ম এই রূপান্তরটিকে স্বয়ংক্রিয় করে। একবার WeChat OAuth সম্পন্ন হলে, Purple-এর ক্লাউড ওভারলে নেটওয়ার্ক অন্তর্নিহিত হার্ডওয়্যারে উপযুক্ত CoA বা MAB সংকেত পাঠায়, যা ম্যানুয়াল VLAN কনফিগারেশনের ঝামেলা দূর করে।

সিকিউরিটি কনফিগারেশন

নিম্নলিখিত তিনটি কনফিগারেশন অ-আলোচনাযোগ্য।

১. AppSecret সুরক্ষিত রাখুন। AppSecret কখনই ক্লায়েন্ট-সাইড JavaScript-এ প্রদর্শিত হওয়া উচিত নয়। এটি অবশ্যই আপনার সার্ভারে থাকতে হবে। যদি এটি আপস করা হয়, তবে আক্রমণকারীরা আপনার অ্যাপ্লিকেশনের ছদ্মবেশ ধারণ করতে পারে এবং আপনার পক্ষে WeChat API কল করতে পারে। ২. CSRF প্রোটেকশন বাস্তবায়ন করুন। একটি ক্রিপ্টোগ্রাফিকভাবে র্যান্ডম state মান তৈরি করুন, এটি ব্যবহারকারী সেশনে সংরক্ষণ করুন এবং WeChat রিডাইরেক্ট ফিরে আসার সময় এটি যাচাই করুন। এটি RFC 6749-এ সংজ্ঞায়িত ক্রস-সাইট রিকোয়েস্ট ফোরজারি আক্রমণ প্রতিরোধ করে। ৩. ** can-সমস্ত রিডাইরেক্ট URI ভেরিয়েশন রেজিস্টার করুন।** WeChat আপনার রেজিস্টার করা ডোমেনের বিপরীতে রিডাইরেক্ট URI যাচাই করে। ৪০০২৯ ত্রুটি (অবৈধ কোড) প্রতিরোধ করতে আপনার ব্যবহৃত প্রতিটি সাবডোমেন এবং পাথ ভেরিয়েন্ট (স্টেজিং এনভায়রনমেন্ট সহ) রেজিস্টার করুন।

ইন-অ্যাপ ব্রাউজার সনাক্তকরণ

WeChat-এর ইন-অ্যাপ ব্রাউজার একটি ইউজার-এজেন্ট স্ট্রিং সেট করে যাতে MicroMessenger থাকে। আপনার ক্যাপটিভ পোর্টাল-কে অবশ্যই এই স্ট্রিংটি সনাক্ত করতে হবে এবং সেই অনুযায়ী রুট করতে হবে: ইন-অ্যাপ ব্রাউজারটি অফিশিয়াল অ্যাকাউন্ট ফ্লো ব্যবহার করে, যেখানে স্ট্যান্ডার্ড ব্রাউজারগুলো Open Platform QR কোড ফ্লো ব্যবহার করে। এই স্ট্রিংটি সনাক্ত করতে ব্যর্থ হলে অভিজ্ঞতা ব্যাহত হয় বা অথেন্টিকেশন ত্রুটি ঘটে।

hotel_wechat_wifi.png


সর্বোত্তম অনুশীলন এবং কমপ্লায়েন্স

GDPR কমপ্লায়েন্স

আপনি যদি ইউরোপীয় ভিজিটরদের সেবা দেন বা ইউরোপে কাজ করেন, তবে WeChat OAuth-এর মাধ্যমে আপনার সংগ্রহ করা ডেটার ক্ষেত্রে GDPR প্রযোজ্য হবে। আপনাকে অবশ্যই একটি কমপ্লায়েন্ট প্রসেসিং ভিত্তি স্থাপন করতে হবে—সাধারণত সম্মতি বা বৈধ স্বার্থ। অথেন্টিকেশন হওয়ার আগে, আপনাকে অবশ্যই ক্যাপটিভ পোর্টাল-এ একটি স্পষ্ট গোপনীয়তা নোটিশ প্রদান করতে হবে। আপনাকে অবশ্যই সাবজেক্ট অ্যাক্সেস রিকোয়েস্ট এবং মুছে ফেলার অনুরোধের প্রতিক্রিয়া জানাতে হবে। একটি বিস্তারিত কমপ্লায়েন্স ফ্রেমওয়ার্কের জন্য, Compliance Playbook: GDPR and Guest WiFi Data Privacy দেখুন।

PIPL কমপ্লায়েন্স

যখন আপনি চীনা নাগরিকদের ব্যক্তিগত ডেটা পরিচালনা করেন, তখন চীনের Personal Information Protection Law (PIPL) প্রযোজ্য হয়। GDPR-এর মতো, PIPL-এর জন্যও স্পষ্ট উদ্দেশ্যের সীমাবদ্ধতা, ডেটা মিনিমাইজেশন এবং একটি লিখিত আইনি ভিত্তি প্রয়োজন। ডেটা মিনিমাইজেশন নীতির অধীনে, snsapi_base সমর্থন করা snsapi_userinfo-এর চেয়ে অনেক সহজ। আপনি যে ডেটাই সংগ্রহ করুন না কেন, লাইভ হওয়ার আগে আপনার আইনি ভিত্তি এবং সংরক্ষণের সময়কাল নথিভুক্ত করুন।

নেটওয়ার্ক আইসোলেশন

আপনার কর্পোরেট নেটওয়ার্ক থেকে গেস্ট WiFi ট্রাফিক আলাদা করতে VLAN সেগমেন্টেশন ব্যবহার করুন। WeChat-এর মাধ্যমে অথেন্টিকেট করা গেস্টদের একটি ডেডিকেটেড গেস্ট VLAN-এ রাখা উচিত যাতে কেবল ইন্টারনেটে অ্যাক্সেস থাকে—অভ্যন্তরীণ সিস্টেমে কোনো অ্যাক্সেস না থাকে। এটি কার্ডহোল্ডার ডেটা এনভায়রনমেন্ট আইসোলেশনের জন্য PCI DSS প্রয়োজনীয়তা এবং সাধারণ কর্পোরেট সিকিউরিটি অনুশীলনের সাথে সামঞ্জস্যপূর্ণ। আইসোলেশন আর্কিটেকচার সম্পর্কে আরও জানতে, Bandwidth Management: A Practical Guide for 2026 দেখুন।

ফলব্যাক অথেন্টিকেশন

যদি WeChat-এর API অনুপলব্ধ থাকে, তবে আপনার পোর্টালকে অবশ্যই একটি বিকল্প লগইন পদ্ধতিতে রিডাইরেক্ট করতে হবে। গেস্টদের একটি ফাঁকা স্ক্রিনের দিকে তাকিয়ে রাখবেন না। ইমেল বা SMS ফলব্যাক প্রদান করা ধারাবাহিকতা নিশ্চিত করে। এটি বিশেষ করে Transport এবং Healthcare পরিবেশের জন্য অত্যন্ত গুরুত্বপূর্ণ, যেখানে নেটওয়ার্ক সংযোগ একটি পরিষেবাগত বাধ্যবাধকতা।


বাস্তব-জগতের কেস স্টাডি

হসপিটালিটি: লাক্সারি হোটেল গ্রুপ

লন্ডনের একটি ৪০০ রুমের লাক্সারি হোটেল মূল ভূখণ্ডের চীন থেকে আসা গেস্টদের উল্লেখযোগ্য সংখ্যার আতিথেয়তা প্রদান করেছিল। তাদের আসল ক্যাপটিভ পোর্টাল-এর জন্য ইমেল ঠিকানা এবং SMS ভেরিফিকেশনের প্রয়োজন ছিল। চীনা মোবাইল নম্বরগুলো প্রায়শই ইউরোপীয় ক্যারিয়ার থেকে SMS বার্তা পেতে ব্যর্থ হতো এবং অনেক গেস্টের ডিভাইসে নেটিভ ইমেল অ্যাকাউন্ট কনফিগার করা ছিল না। এর ফলে পোর্টাল পরিত্যাগের হার ৬০% পর্যন্ত পৌঁছেছিল।

হোটেলটি Official Accounts প্ল্যাটফর্মে একটি সার্ভিস অ্যাকাউন্ট এবং Open Platform-এ একটি ওয়েবসাইট অ্যাপ্লিকেশন রেজিস্টার করেছে। পোর্টালটি MicroMessenger ইউজার-এজেন্ট সনাক্ত করেছে এবং ইন-অ্যাপ ব্রাউজার ব্যবহারকারীদের জন্য snsapi_base ট্রিগার করেছে—কোনো অথরাইজেশন প্রম্পট ছাড়াই তিন সেকেন্ডেরও কম সময়ে তাদের সংযুক্ত করেছে। Chrome বা Safari ব্যবহারকারী গেস্টদের একটি QR কোড দেখানো হয়েছিল। পরবর্তী ভিজিটগুলোতে, সিস্টেমটি একই OpenID সনাক্ত করে এবং ক্রেডেনশিয়াল না চেয়েই নীরবে গেস্টকে অথেন্টিকেট করে। হোটেলের CRM গেস্টের ফিরে আসার তথ্য লগ করেছে, যা লক্ষ্যযুক্ত প্রি-অ্যারাইভাল যোগাযোগের সুযোগ করে দিয়েছে। হসপিটালিটিতে WiFi স্থাপনের বিষয়ে আরও জানতে, Hospitality দেখুন।

রিটেইল: শপিং সেন্টার অ্যানালিটিক্স

একটি বড় শপিং সেন্টার টেন্যান্ট মিক্স এবং মার্কেটিং কৌশল নির্ধারণের জন্য চীনা গ্রাহকদের কাছ থেকে ডেমোগ্রাফিক অন্তর্দৃষ্টি সংগ্রহ করতে চেয়েছিল। তাদের হোম সিটি, লিঙ্গ এবং ভিজিটের ফ্রিকোয়েন্সি বোঝার প্রয়োজন ছিল। এখানে, snsapi_base যথেষ্ট ছিল না—তাদের snsapi_userinfo প্রয়োজন ছিল। পোর্টালটি সম্পূর্ণ userinfo স্কোপের অনুরোধ করেছিল। গেস্টরা WeChat অথরাইজেশন প্রম্পট দেখেছিলেন এবং অনুমতি দিন-এ ক্লিক করেছিলেন। শপিং সেন্টারের অ্যানালিটিক্স প্ল্যাটফর্ম, যা Purple-এর WiFi Analytics -এর সাথে ইন্টিগ্রেট করা ছিল, যাচাইকৃত ডেমোগ্রাফিক ডেটার একটি স্ট্রিম পেয়েছিল। শনিবার বিকেলে, ৪০% WiFi ব্যবহারকারী একটি নির্দিষ্ট অঞ্চলের ছিলেন। এই ডেটা সরাসরি প্রভাবিত করেছিল যে পপ-আপ অ্যাক্টিভেশনের জন্য কোন ব্র্যান্ডগুলোর সাথে যোগাযোগ করা হবে। রিটেইল WiFi স্থাপনের বিষয়ে আরও জানতে, Retail দেখুন।


ট্রাবলশুটিং এবং ঝুঁকি প্রশমন

WeChat OAuth ক্যাপটিভ পোর্টাল স্থাপনে পাঁচটি সবচেয়ে সাধারণ ব্যর্থতার মোড হলো:

Redirect URI Mismatch (Error 40029). WeChat রেজিস্টার করা ডোমেনের বিপরীতে রিডাইরেক্ট URI যাচাই করে। সাবডোমেন, পাথ বা প্রোটোকলের যেকোনো অমিল কোড বিনিময় ব্যর্থ করবে। স্টেজিং এনভায়রনমেন্ট সহ সমস্ত ভেরিয়েন্ট রেজিস্টার করুন।

AppSecret exposure. ক্লায়েন্ট-সাইড কোডে AppSecret এম্বেড করা সবচেয়ে গুরুতর সিকিউরিটি ভুল। অনুগ্রহ করে সমস্ত টোকেন বিনিময় লজিক সার্ভার সাইডে স্থানান্তরিত করুন।

Missing CSRF protection. state প্যারামিটার যাচাইকরণ উপেক্ষা করলে পোর্টালটি ক্রস-সাইট রিকোয়েস্ট ফোরজারি আক্রমণের ঝুঁকিতে পড়ে। প্রতি সেশনে একটি ক্রিপ্টোগ্রাফিক র্যান্ডম মান তৈরি করুন এবং কলব্যাকে এটি যাচাই করুন।

In-app browser detection failure. ইউজার এজেন্টে MicroMessenger সনাক্ত করতে ব্যর্থ হওয়ার অর্থ হলো ইন-অ্যাপ ব্রাউজার ব্যবহারকারীদের ভুল OAuth ফ্লো পরিবেশন করা হবে, যার ফলে ত্রুটি ঘটবে।

MAC address randomisation breaks MAB sessions. আধুনিক মোবাইল অপারেটিং সিস্টেমগুলো MAC অ্যাড্রেস র্যান্ডমাইজ করে। MAB প্রয়োগের ওপর নির্ভরশীল গেস্টরা পুনরায় সংযোগ করার সময় তাদের সেশন হারাবেন। নির্ভরযোগ্য সেশন ম্যানেজমেন্টের জন্য RADIUS CoA-তে আপগ্রেড করুন। নিরাপদ WiFi কনফিগারেশনের নির্দেশনার জন্য, What is Secure WiFi: The 2026 Enterprise Essential Guide দেখুন।


ROI এবং ব্যবসায়িক প্রভাব

গেস্ট WiFi-এর জন্য WeChat লগইন স্থাপন করা তিনটি পরিমাপযোগ্য প্রভাব প্রদান করে।

Improved authentication rates. SMS ভেরিফিকেশন ব্যর্থতার পয়েন্ট এবং ইমেল ইনপুটের প্রয়োজনীয়তা দূর করা সফলভাবে সংযুক্ত হওয়া চীনা ভিজিটরদের অনুপাত বাড়ায়। WeChat সমর্থন ছাড়া ক্যাপটিভ পোর্টাল-এর জন্য, ৬০% পরিত্যাগের হার একটি বাস্তবসম্মত বেসলাইন।

First-party data quality. WeChat-যাচাইকৃত প্রোফাইলগুলোতে একটি বৈধ OpenID এবং snsapi_userinfo-এর মাধ্যমে সোশ্যাল প্ল্যাটফর্ম থেকে ডেমোগ্রাফিক বৈশিষ্ট্যগুলোতে সরাসরি অ্যাক্সেস অন্তর্ভুক্ত থাকে। থার্ড-পার্টি কুকিজের ওপর নির্ভর না করে লক্ষ্যযুক্ত মার্কেটিং চালানোর জন্য এই ডেটা অ্যানালিটিক্স প্ল্যাটফর্মে ইনজেক্ট করা যেতে পারে।

Reduced support overhead. নির্বিঘ্ন লগইন আন্তর্জাতিক ভিজিটরদের সংযোগের সমস্যা সমাধানের জন্য ফ্রন্ট ডেস্ক এবং IT সাপোর্ট স্টাফদের কাছে কলের পরিমাণ কমিয়ে দেয়।

Purple ৮০,০০০-এরও বেশি ভেন্যুতে কাজ করে এবং ২০২৪ সালে ৪৪০ মিলিয়ন লগইন প্রক্রিয়া করেছে (Purple-এর অভ্যন্তরীণ ডেটা)। প্ল্যাটফর্মটি ISO 27001 সার্টিফাইড, GDPR এবং CCPA কমপ্লায়েন্ট এবং ৯৯.৯৯৯% আপটাইম বজায় রাখে। Retail এবং Hospitality খাতের ভেন্যুগুলোর জন্য, WeChat অথেন্টিকেশন নেটওয়ার্ককে একটি খরচ কেন্দ্র থেকে একটি শক্তিশালী ফার্স্ট-পার্টি ডেটা ক্যাপচার চ্যানেলে রূপান্তরিত করে।

মূল সংজ্ঞাসমূহ

ক্যাপটিভ পোর্টাল

একটি ওয়েব পেজ যা একটি অথেন্টিকেট না করা ডিভাইস থেকে HTTP ট্রাফিক ইন্টারসেপ্ট করে এবং নেটওয়ার্ক অ্যাক্সেস দেওয়ার আগে ব্যবহারকারীকে এটির সাথে ইন্টারঅ্যাক্ট করতে বাধ্য করে।

প্রধান ইন্টারফেস যেখানে গেস্টের সামনে WeChat লগইন বিকল্পটি উপস্থাপন করা হয়। পোর্টাল সার্ভার এই পেজটি হোস্ট করে এবং OAuth ফ্লো পরিচালনা করে।

OAuth 2.0

একটি ইন্ডাস্ট্রি-স্ট্যান্ডার্ড অথরাইজেশন প্রোটোকল (RFC 6749) যা একটি থার্ড-পার্টি অ্যাপ্লিকেশনকে ব্যবহারকারীর পক্ষে একটি HTTP সার্ভিসে সীমিত অ্যাক্সেস পাওয়ার অনুমতি দেয়।

ব্যবহারকারীর ক্রেডেনশিয়াল প্রকাশ না করে পোর্টাল সার্ভারে অথেন্টিকেশন টোকেন পাস করার জন্য WeChat যে অন্তর্নিহিত প্রোটোকলটি ব্যবহার করে। Microsoft Entra ID, Okta এবং Google Workspace দ্বারা ব্যবহৃত একই প্রোটোকল।

OpenID

একটি নির্দিষ্ট অফিশিয়াল অ্যাকাউন্টের জন্য একটি নির্দিষ্ট WeChat ব্যবহারকারীকে দেওয়া একটি অনন্য আলফানিউমেরিক আইডেন্টিফায়ার।

WiFi অ্যানালিটিক্স ডেটাবেসে ফিরে আসা গেস্টদের সনাক্ত করতে প্রাইমারি কি হিসেবে ব্যবহৃত হয়। প্রতিটি অফিশিয়াল অ্যাকাউন্টের জন্য পরিবর্তিত হয় - ক্রস-প্রপার্টি সনাক্তকরণের জন্য UnionID ব্যবহার করুন।

UnionID

একটি একক WeChat আইডেন্টিফায়ার যা একই Open Platform অ্যাকাউন্টের সাথে লিঙ্ক করা সমস্ত অফিশিয়াল অ্যাকাউন্ট এবং অ্যাপ জুড়ে একজন ব্যবহারকারীকে প্রতিনিধিত্ব করে।

হোটেল গ্রুপ, রিটেইল চেইন এবং একাধিক ভেন্যু সহ স্টেডিয়াম অপারেটরদের জন্য অপরিহার্য যাদের তাদের সম্পূর্ণ এস্টেট জুড়ে একই গেস্টকে সনাক্ত করতে হবে।

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, ডাকনাম, অবতার, লিঙ্গ এবং শহর ফেরত দেয় এবং একটি স্পষ্ট সম্মতি স্ক্রিনের প্রয়োজন হয়।

প্রথমবার আসা গেস্ট রেজিস্ট্রেশনের জন্য ব্যবহৃত হয় যেখানে অ্যানালিটিক্সের জন্য ডেমোগ্রাফিক ডেটা প্রয়োজন। GDPR এবং PIPL-এর অধীনে নথিভুক্ত আইনি ভিত্তি প্রয়োজন।

PIPL (Personal Information Protection Law)

চীনের ব্যাপক ডেটা গোপনীয়তা আইন, যা নভেম্বর ২০২১ থেকে কার্যকর হয়েছে, যা চীনে অবস্থিত স্বাভাবিক ব্যক্তিদের ব্যক্তিগত তথ্য প্রক্রিয়াকরণ নিয়ন্ত্রণ করে।

যখন ভেন্যুগুলো WeChat OAuth-এর মাধ্যমে চীনা নাগরিকদের ডেটা প্রসেস করে তখন প্রযোজ্য হয়। স্পষ্ট সম্মতি, উদ্দেশ্যের সীমাবদ্ধতা, ডেটা মিনিমাইজেশন এবং একটি মুছে ফেলার প্রক্রিয়া প্রয়োজন।

AppSecret

অ্যাপ্লিকেশন রেজিস্ট্রেশনের সময় WeChat দ্বারা জারি করা একটি গোপনীয় ক্রিপ্টোগ্রাফিক কী, যা পোর্টাল সার্ভার থেকে API কলগুলোকে অথরাইজ করতে ব্যবহৃত হয়।

অবশ্যই একচেটিয়াভাবে সার্ভার সাইডে সংরক্ষণ করতে হবে। ক্লায়েন্ট-সাইড JavaScript-এ প্রকাশ পেলে আক্রমণকারীরা অ্যাপ্লিকেশনের ছদ্মবেশ ধারণ করতে পারে এবং ক্ষতিকারকভাবে WeChat API কল করতে পারে।

সমাধানকৃত উদাহরণসমূহ

লন্ডনের একটি ৪০০ রুমের লাক্সারি হোটেলে মূল ভূখণ্ডের চীন থেকে আসা গেস্টদের মধ্যে ৬০% পোর্টাল ড্রপ-অফ হার রয়েছে। বর্তমান পোর্টালের জন্য ইমেল এবং 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), উদ্দেশ্য (গেস্ট WiFi অ্যাক্সেস এবং ফিরে আসা ভিজিটর সনাক্তকরণ) এবং সংরক্ষণের সময়কাল। ধাপ ৪: সফল OAuth টোকেন বিনিময়ের পর, পোর্টাল সার্ভার Cisco Meraki কন্ট্রোলারে একটি RADIUS CoA অনুরোধ পাঠায়, যা গেস্ট ডিভাইসটিকে প্রি-অথেন্টিকেশন VLAN থেকে সেগমেন্টেড গেস্ট VLAN-এ স্থানান্তরিত করে। ধাপ ৫: গেস্ট ডেটাবেসে ডিভাইসের MAC অ্যাড্রেসের বিপরীতে OpenID সংরক্ষণ করুন। পরবর্তী ভিজিটগুলোতে, ফিরে আসা OpenID নীরব পুনরায় অথেন্টিকেশন ট্রিগার করবে।

পরীক্ষকের মন্তব্য: এই পদ্ধতিটি প্রযুক্তিগত এবং কমপ্লায়েন্স উভয় প্রয়োজনীয়তা সঠিকভাবে সমাধান করে। snsapi_base ব্যবহার করা GDPR ডেটা মিনিমাইজেশন নীতির সাথে সামঞ্জস্যপূর্ণ, যা আইনি ঝুঁকি হ্রাস করার পাশাপাশি SMS ভেরিফিকেশন ব্যর্থতার পয়েন্টটি দূর করে। RADIUS CoA নিরাপদ, স্বয়ংক্রিয় নেটওয়ার্ক সেগমেন্টেশন নিশ্চিত করে। সম্মতি চেকবক্সটি একটি নথিভুক্ত আইনি ভিত্তির জন্য GDPR প্রয়োজনীয়তা পূরণ করে। মূল সিদ্ধান্তটি হলো snsapi_userinfo-এর পরিবর্তে snsapi_base ব্যবহার করা - এই ব্যবহারের ক্ষেত্রে হোটেলের ডেমোগ্রাফিক ডেটার প্রয়োজন নেই, তাই এটি সংগ্রহ করলে অপ্রয়োজনীয় কমপ্লায়েন্স বাধ্যবাধকতা তৈরি হতো।

একটি শপিং মল তাদের অ্যানালিটিক্স প্ল্যাটফর্মে ইনপুট করার জন্য গেস্ট 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 অ্যাড্রেস র্যান্ডমাইজ করে, যার অর্থ গেস্টরা পুনরায় সংযোগ করার সময় তাদের অথেন্টিকেট করা সেশনটি হারাবেন এবং পুনরায় অথেন্টিকেট করতে বাধ্য হবেন। শপিং মলের উচিত এটি সমাধানের জন্য HPE Aruba-তে RADIUS CoA-তে স্থানান্তরিত হওয়ার পরিকল্পনা করা। PIPL কমপ্লায়েন্স ডকুমেন্টেশন ঐচ্ছিক নয় - ভেন্যু যেখানেই অবস্থিত হোক না কেন, চীনা নাগরিকদের ডেটা প্রসেস করার জন্য এটি একটি আইনি প্রয়োজনীয়তা।

অনুশীলনী প্রশ্নসমূহ

Q1. আপনি একটি স্টেডিয়ামে একটি ক্যাপটিভ পোর্টাল স্থাপন করছেন। আপনি চান যে ফিরে আসা সিজন টিকিট হোল্ডাররা যারা আগে অথেন্টিকেট করেছেন তারা পরবর্তী ভিজিটগুলোতে কোনো লগইন স্ক্রিন না দেখেই স্বয়ংক্রিয়ভাবে সংযুক্ত হন। পুনরায় অথেন্টিকেশন ফ্লোর জন্য আপনার কোন WeChat OAuth স্কোপটি বাস্তবায়ন করা উচিত এবং কেন?

ইঙ্গিত: প্রতিটি ভিজিটে ব্যবহারকারীকে সম্মতির জন্য প্রম্পট না করে কোন স্কোপটি নীরব অথেন্টিকেশনের অনুমতি দেয় তা বিবেচনা করুন।

মডেল উত্তর দেখুন

snsapi_base ব্যবহার করুন। এই স্কোপটি কেবল ব্যবহারকারীর OpenID ফেরত দেয় এবং কোনো সম্মতি প্রম্পটের প্রয়োজন হয় না, যা নীরব পুনরায় অথেন্টিকেশন সক্ষম করে। প্রথম ভিজিটে, আপনি ফ্যানের প্রোফাইলের বিপরীতে OpenID সংরক্ষণ করেন। পরবর্তী ভিজিটগুলোতে, পোর্টালটি snsapi_base-এর মাধ্যমে ফিরে আসা OpenID সনাক্ত করে, মিল নিশ্চিত করে এবং অ্যাক্সেস দেওয়ার জন্য একটি RADIUS CoA ইস্যু করে - যার কোনোটিতেই ফ্যানকে কোনো লগইন স্ক্রিন দেখতে হয় না। এটি GDPR ডেটা মিনিমাইজেশন নীতির সাথেও সামঞ্জস্যপূর্ণ, কারণ আপনি অথেন্টিকেশন ফাংশনের জন্য যা প্রয়োজন তার বাইরে অতিরিক্ত ডেটা সংগ্রহ করছেন না।

Q2. পরীক্ষার সময়, আপনার পোর্টালটি সফলভাবে WeChat-এ রিডাইরেক্ট হয়, ব্যবহারকারী সম্মতি দেন এবং WeChat আপনার পোর্টালে ফিরে রিডাইরেক্ট করে। তবে, পোর্টাল সার্ভার লগগুলো OAuth ত্রুটি ৪০০২৯ (অবৈধ কোড) দেখায়। সবচেয়ে সম্ভাব্য কনফিগারেশন ত্রুটি কী এবং কীভাবে আপনি এটি সমাধান করবেন?

ইঙ্গিত: WeChat কঠোরভাবে যাচাই করে যে এটি কোন গন্তব্যে অথরাইজেশন কোড পাঠাচ্ছে তা একটি রেজিস্টার করা তালিকার বিপরীতে।

মডেল উত্তর দেখুন

সবচেয়ে সম্ভাব্য কারণ হলো রিডাইরেক্ট URI-এর অমিল। WeChat প্ল্যাটফর্মে রেজিস্টার করা অনুমোদিত ডোমেনের বিপরীতে OAuth অনুরোধে রিডাইরেক্ট URI যাচাই করে। যদি পোর্টাল সার্ভার একটি ভিন্ন সাবডোমেন, একটি ভিন্ন পাথ বা HTTPS-এর পরিবর্তে HTTP ব্যবহার করে, তবে কোড বিনিময় ৪০০২৯ ত্রুটি সহ ব্যর্থ হয়। সমাধান: WeChat ডেভেলপার প্ল্যাটফর্মে লগ ইন করুন, আপনার সার্ভিস অ্যাকাউন্ট বা ওয়েবসাইট অ্যাপ্লিকেশন সেটিংসে যান এবং আপনার ব্যবহৃত প্রতিটি রিডাইরেক্ট URI ভেরিয়েন্ট যোগ করুন - যার মধ্যে স্টেজিং সাবডোমেন, ভিন্ন পাথ এবং HTTPS সংস্করণ অন্তর্ভুক্ত রয়েছে। নিশ্চিত করুন যে আপনার OAuth অনুরোধে redirect_uri প্যারামিটারটি URL এনকোডিং সহ রেজিস্টার করা URI-গুলোর একটির সাথে হুবহু মিলে যায়।

Q3. একজন IT ম্যানেজার সরাসরি ক্লায়েন্ট ব্রাউজার থেকে টোকেন বিনিময় প্রক্রিয়া ত্বরান্বিত করতে ক্যাপটিভ পোর্টাল-এর ফ্রন্ট-এন্ড JavaScript-এ WeChat AppSecret এম্বেড করার প্রস্তাব করেছেন। কেন আপনাকে অবশ্যই এই প্রস্তাবটি প্রত্যাখ্যান করতে হবে এবং সঠিক আর্কিটেকচার কী?

ইঙ্গিত: প্রকাশ্যে অ্যাক্সেসযোগ্য কোডে ক্রিপ্টোগ্রাফিক কীগুলো প্রকাশ করার সিকিউরিটি প্রভাবগুলো বিবেচনা করুন।

মডেল উত্তর দেখুন

এই প্রস্তাবটি প্রত্যাখ্যান করুন। AppSecret একটি গোপনীয় ক্রিপ্টোগ্রাফিক কী। ক্লায়েন্ট-সাইড JavaScript-এ এটি এম্বেড করলে এটি এমন যে কারও কাছে প্রকাশ পেয়ে যায় যে পেজের সোর্স কোড দেখে বা নেটওয়ার্ক ট্রাফিক ইন্টারসেপ্ট করে। একজন আক্রমণকারী AppSecret বের করতে পারে এবং অ্যাপ্লিকেশনের ছদ্মবেশ ধারণ করতে পারে, ভেন্যুর পক্ষে WeChat API কল করতে পারে, ব্যবহারকারীর ডেটা অ্যাক্সেস করতে পারে এবং সম্ভাব্যভাবে সম্পূর্ণ অফিশিয়াল অ্যাকাউন্টটির ক্ষতি করতে পারে। সঠিক আর্কিটেকচার: ক্লায়েন্ট-সাইড পোর্টাল পেজটি WeChat থেকে অথরাইজেশন কোড গ্রহণ করে এবং একটি সার্ভার-সাইড API কলের মাধ্যমে এটি পোর্টাল সার্ভারে ফরোয়ার্ড করে। পোর্টাল সার্ভার একটি নিরাপদ এনভায়রনমেন্ট ভেরিয়েবলে AppSecret ধারণ করে এবং WeChat-এর API-এর সাথে টোকেন বিনিময় সম্পন্ন করে। AppSecret কখনই সার্ভার থেকে বাইরে যায় না।

Q4. ইউরোপ জুড়ে ১৫টি প্রপার্টি বিশিষ্ট একটি হোটেল গ্রুপ একটি গেস্ট প্রোফাইল তৈরি করতে চায় যা সনাক্ত করবে যখন একই চীনা গেস্ট বিভিন্ন প্রপার্টিতে থাকবেন। প্রতিটি প্রপার্টির নিজস্ব WeChat অফিশিয়াল অ্যাকাউন্ট রয়েছে। তাদের কোন WeChat আইডেন্টিফায়ার ব্যবহার করা উচিত এবং কী কনফিগারেশন প্রয়োজন?

ইঙ্গিত: OpenID অ্যাকাউন্ট-নির্দিষ্ট। ক্রস-অ্যাকাউন্ট সনাক্তকরণের জন্য ডিজাইন করা একটি ভিন্ন আইডেন্টিফায়ার রয়েছে।

মডেল উত্তর দেখুন

UnionID ব্যবহার করুন। OpenID প্রতিটি অফিশিয়াল অ্যাকাউন্টের জন্য পরিবর্তিত হয়, তাই একই গেস্টের ১৫টি অ্যাকাউন্টে ১৫টি ভিন্ন OpenID থাকবে। UnionID হলো একটি স্থিতিশীল আইডেন্টিফায়ার যা একই Open Platform অ্যাকাউন্টের সাথে লিঙ্ক করা সমস্ত অফিশিয়াল অ্যাকাউন্ট এবং অ্যাপ জুড়ে একজন ব্যবহারকারীকে প্রতিনিধিত্ব করে। প্রয়োজনীয় কনফিগারেশন: সমস্ত ১৫টি অফিশিয়াল অ্যাকাউন্টকে একটি একক WeChat Open Platform অ্যাকাউন্টের সাথে লিঙ্ক করুন। একবার লিঙ্ক হয়ে গেলে, ব্যবহারকারী লিঙ্ক করা অ্যাকাউন্টগুলোর অন্তত একটি অথরাইজ করলে OAuth রেসপন্সে UnionID ফেরত দেওয়া হয়। গেস্ট CRM-এ UnionID-কে প্রাইমারি কি হিসেবে ব্যবহার করুন যাতে ক্রস-প্রপার্টি প্রোফাইল তৈরি করা যায় এবং তারা যে প্রপার্টিতেই যান না কেন ফিরে আসা গেস্টদের সনাক্ত করা যায়।

এই সিরিজে পড়া চালিয়ে যান

Ruijie-এর জন্য ক্যাপটিভ পোর্টাল: Purple গেস্ট WiFi-এর সাথে এটি সেট আপ করুন

কীভাবে Purple-এর ক্লাউড গেস্ট WiFi ওয়েব অথেনটিকেশন এবং RADIUS ব্যবহার করে Ruijie RG Series অ্যাক্সেস পয়েন্টের উপরে কাজ করে, যা কমান্ড লাইন থেকে কনফিগার করা হয় এবং সঠিক সেটআপ ধাপগুলো কোথায় পাওয়া যাবে।

গাইডটি পড়ুন →

B2B Captive Portals ডিজাইন করা: নিবন্ধিত নাম এবং কোম্পানির ডেটা সংগ্রহ করা

এই নির্দেশিকাটি IT ম্যানেজার এবং ভেন্যু অপারেটরদের B2B captive portals ডিজাইন করার জন্য একটি ভেন্ডর-নিরপেক্ষ প্রযুক্তিগত কাঠামো প্রদান করে। এটি নিবন্ধিত নাম এবং কোম্পানির ডেটা ক্যাপচার করার জন্য কীভাবে রেজিস্ট্রেশন ফিল্ড গঠন করা যায় তা বিস্তারিত ব্যাখ্যা করে, যা GDPR সম্মতি বজায় রেখে এবং অ্যাকাউন্ট-স্তরের ইন্টেলিজেন্স তৈরি করার পাশাপাশি উচ্চ সমাপ্তির হার নিশ্চিত করে।

গাইডটি পড়ুন →

ক্যাপটিভ পোর্টাল আর্কিটেকচার: নিরাপত্তা, রিডাইরেকশন এবং সর্বোত্তম অনুশীলনসমূহ

এন্টারপ্রাইজ ক্যাপটিভ পোর্টাল আর্কিটেকচারের উপর একটি সুনির্দিষ্ট প্রযুক্তিগত রেফারেন্স। এই গাইডটি সুরক্ষিত, ডেটা-সমৃদ্ধ গেস্ট WiFi নেটওয়ার্ক স্থাপনকারী IT লিডারদের জন্য নেটওয়ার্ক আইসোলেশন, DNS রিডাইরেকশন, RADIUS অথেন্টিকেশন এবং সিকিউরিটি কমপ্লায়েন্স উন্মোচন করে।

গাইডটি পড়ুন →