WeChat WiFi অথেন্টিকেশন ইন্টিগ্রেশন: APAC গ্রাহকদের জন্য Captive Portal অনবোর্ডিং
WeChat-এর ১.৪১ বিলিয়ন মাসিক সক্রিয় ব্যবহারকারী রয়েছে, যা এটিকে বিশ্বব্যাপী চীনা গ্রাহকদের জন্য প্রাথমিক ডিজিটাল পরিচয় করে তুলেছে। এই নির্দেশিকাটি ব্যাখ্যা করে কীভাবে APAC ভেন্যুগুলির জন্য এন্টারপ্রাইজ captive portals-এ WeChat OAuth 2.0 অথেন্টিকেশন ইন্টিগ্রেট করতে হয়, যার মধ্যে প্ল্যাটফর্ম রেজিস্ট্রেশন, স্কোপ নির্বাচন, RADIUS Change of Authorisation প্রয়োগ এবং GDPR ও চীনের PIPL-এর সাথে দ্বৈত-কাঠামো সম্মতি অন্তর্ভুক্ত রয়েছে। এটি আইটি ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং ভেন্যু অপারেশন ডিরেক্টরদের উদ্দেশ্যে তৈরি করা হয়েছে যাদের এই ত্রৈমাসিকে পদক্ষেপ নেওয়া প্রয়োজন।
এই গাইডটি শুনুন
পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
কার্যনির্বাহী সারসংক্ষেপ
APAC অঞ্চল জুড়ে পরিচালিত এন্টারপ্রাইজ ভেন্যুগুলির জন্য, বা বিশ্বব্যাপী চীনা পর্যটকদের পরিষেবা দেওয়ার জন্য, WeChat WiFi অথেন্টিকেশন এখন আর ঐচ্ছিক নয়। ২০২৫ সাল পর্যন্ত ১.৪১ বিলিয়ন মাসিক সক্রিয় ব্যবহারকারী সহ (উৎস: Tencent), WeChat হলো চীনা গ্রাহকদের জন্য প্রাথমিক ডিজিটাল পরিচয়। একজন অতিথি যিনি আপনার SSID-এর সাথে সংযুক্ত হন এবং কেবল ইমেল বা Facebook লগইন বিকল্পগুলি দেখেন, তিনি তাত্ক্ষণিক ঘর্ষণের সম্মুখীন হন। তাদের প্রায় নিশ্চিতভাবেই WeChat আছে। তারা প্রায় নিশ্চিতভাবেই সেই ডিভাইসে কোনো স্থানীয় ইমেল ঠিকানা কনফিগার করেনি।
এই নির্দেশিকাটি বিস্তারিতভাবে ব্যাখ্যা করে কীভাবে একটি captive portal-এ WeChat OAuth 2.0 ইন্টিগ্রেট করতে হয়। আমরা Tencent-এর প্রয়োজনীয় দুটি পৃথক প্ল্যাটফর্ম রেজিস্ট্রেশন, আপনি কোন ফার্স্ট-পার্টি ডেটা সংগ্রহ করবেন তা নির্ধারণকারী স্কোপ সিদ্ধান্ত এবং RADIUS Change of Authorisation (CoA) মেকানিজম কভার করি যা একটি সফল OAuth বিনিময়কে প্রকৃত নেটওয়ার্ক অ্যাক্সেসে রূপান্তর করে। আমরা GDPR এবং চীনের Personal Information Protection Law (PIPL)-এর ওভারল্যাপিং সম্মতির প্রয়োজনীয়তাগুলিও সমাধান করি।
Purple-এর Guest WiFi প্ল্যাটফর্ম Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet হার্ডওয়্যার জুড়ে নেটওয়ার্ক প্রয়োগের স্তরটিকে স্বয়ংক্রিয় করে। Purple ৮০,০০০+-এরও বেশি লাইভ ভেন্যু জুড়ে কাজ করে এবং ২০২৪ সালে ৪৪০ মিলিয়ন লগইন রেকর্ড করেছে (Purple অভ্যন্তরীণ ডেটা)।
টেকনিক্যাল ডিপ-ডাইভ
OAuth 2.0 ফ্লো
একটি captive portal (একটি ওয়েব-ভিত্তিক অথেন্টিকেশন গেটওয়ে যা আন-অথেন্টিকেটেড ডিভাইস থেকে HTTP ট্রাফিককে বাধা দেয়) অতিথিদের একটি পোর্টাল সার্ভারে হোস্ট করা লগইন পৃষ্ঠায় রিডাইরেক্ট করে, যা অন-প্রিমিসেস বা ক্লাউডে হতে পারে। WeChat OAuth যোগ করা সেই ফ্লোতে Tencent-এর পরিচয় অবকাঠামোকে যুক্ত করে।
সিকোয়েন্সটি নিম্নরূপ চলে। অতিথি SSID-এর সাথে যুক্ত হন। ওয়্যারলেস কন্ট্রোলার একটি অথেন্টিকেটেড সেশনের অনুপস্থিতি সনাক্ত করে এবং সমস্ত HTTP ট্রাফিককে captive portal URL-এ রিডাইরেক্ট করে। পোর্টাল পৃষ্ঠাটি লোড হয় এবং WeChat সহ লগইন বিকল্পগুলি উপস্থাপন করে। অতিথি WeChat নির্বাচন করেন। পোর্টাল সার্ভার open.weixin.qq.com-এ WeChat-এর অথরাইজেশন এন্ডপয়েন্টে একটি রিডাইরেক্ট তৈরি করে, চারটি প্যারামিটার পাস করে: AppID, রিডাইরেক্ট URI, code হিসেবে সেট করা রেসপন্স টাইপ এবং অনুরোধ করা স্কোপ।
WeChat সম্পূর্ণ নিজস্ব অবকাঠামোতে ব্যবহারকারীকে অথেন্টিকেট করে। ব্যবহারকারী যদি ইতিমধ্যে WeChat ইন-অ্যাপ ব্রাউজারের মাধ্যমে সাইন ইন করে থাকেন, তবে snsapi_base স্কোপ কোনো দৃশ্যমান প্রম্পট ছাড়াই নীরব অথেন্টিকেশনের অনুমতি দেয়। WeChat একটি স্বল্পস্থায়ী অথরাইজেশন কোড সহ পোর্টালের রেজিস্টার্ড রিডাইরেক্ট URI-তে ফিরে রিডাইরেক্ট করে। পোর্টাল সার্ভার AppID, AppSecret, কোড এবং গ্রান্ট টাইপ সহ api.weixin.qq.com/sns/oauth2/access_token কল করে একটি অ্যাক্সেস টোকেনের জন্য এই কোডটি বিনিময় করে। WeChat একটি অ্যাক্সেস টোকেন, একটি রিফ্রেশ টোকেন, ব্যবহারকারীর OpenID এবং মঞ্জুর করা স্কোপ ফেরত দেয়। যদি snsapi_userinfo অনুরোধ করা হয়ে থাকে, তবে api.weixin.qq.com/sns/userinfo-এ একটি দ্বিতীয় API কল ব্যবহারকারীর ডাকনাম, প্রোফাইল ছবি, লিঙ্গ এবং শহর পুনরুদ্ধার করে।
প্ল্যাটফর্ম রেজিস্ট্রেশন: যে সিদ্ধান্তটি বেশিরভাগ ডেপ্লয়মেন্টকে বাধাগ্রস্ত করে
Tencent দুটি পৃথক ডেভেলপার প্ল্যাটফর্ম পরিচালনা করে এবং ভুলটি নির্বাচন করা ব্যর্থ বাস্তবায়নের সবচেয়ে সাধারণ কারণ।
| অ্যাক্সেস কনটেক্সট | প্রয়োজনীয় রেজিস্ট্রেশন | প্ল্যাটফর্ম URL | সমর্থিত স্কোপ |
|---|---|---|---|
| WeChat ইন-অ্যাপ ব্রাউজার | Service Account (Official Accounts Platform) | mp.weixin.qq.com | snsapi_base, snsapi_userinfo |
| স্ট্যান্ডার্ড মোবাইল ব্রাউজার (Chrome, Safari) | Website Application (Open Platform) | open.weixin.qq.com | snsapi_login (QR কোড ফ্লো) |
Official Accounts Platform-এ একটি Subscription Account কাজ করবে না। এটির OAuth ওয়েব পেজ অথরাইজেশন অনুমতির অভাব রয়েছে। কেবল একটি Service Account-এর সেই অনুমতিগুলি রয়েছে।
Hospitality এবং Retail -এ বেশিরভাগ এন্টারপ্রাইজ ডেপ্লয়মেন্ট উভয় রেজিস্ট্রেশনই প্রয়োগ করে। একটি হোটেলের অতিথি Chrome-এ পোর্টালটি খুলতে পারেন, WeChat দিয়ে একটি QR কোড স্ক্যান করতে পারেন এবং Open Platform ফ্লোর মাধ্যমে অথেন্টিকেট করতে পারেন। অথবা তারা WeChat-এর ভিতরে একটি লিঙ্ক অনুসরণ করতে পারেন, ইন-অ্যাপ ব্রাউজারে ল্যান্ড করতে পারেন এবং Official Accounts ফ্লোর মাধ্যমে নীরবে অথেন্টিকেট করতে পারেন। উভয় পথই পরিচালনা করতে হবে।
স্কোপ নির্বাচন এবং ডেটা সংগ্রহ
OAuth স্কোপ একটি প্রকৃত আর্কিটেকচারাল সিদ্ধান্ত, কোনো কনফিগারেশন বিবরণ নয়। এটি ব্যবহারকারী যে ঘর্ষণের সম্মুখীন হন এবং আপনার WiFi Analytics প্ল্যাটফর্ম যে ডেটা গ্রহণ করে তা নির্ধারণ করে।
snsapi_base কেবল OpenID ফেরত দেয় - আপনার Official Account-এর মধ্যে সেই ব্যবহারকারীর জন্য একটি স্থিতিশীল, অনন্য আইডেন্টিফায়ার। এর জন্য কোনো ব্যবহারকারীর সম্মতি প্রম্পটের প্রয়োজন হয় না। অথেন্টিকেশনটি অদৃশ্য। এটি ফিরে আসা অতিথিদের জন্য ব্যবহার করুন যাদের প্রোফাইল আপনার কাছে ইতিমধ্যে রয়েছে, অথবা স্টেডিয়াম এবং পরিবহন হাবের মতো উচ্চ-থ্রুপুট পরিবেশের জন্য যেখানে সংযোগের গতি অগ্রাধিকার পায়।
snsapi_userinfo OpenID-এর সাথে ডাকনাম, প্রোফাইল ছবি, লিঙ্গ, ভাষা সেটিং এবং শহর ফেরত দেয়। এটি একটি স্পষ্ট সম্মতি স্ক্রিন ট্রিগার করে। পোর্টাল পৃষ্ঠায় একটি PIPL-সম্মত এবং GDPR-সম্মত সম্মতি স্তরের সাথে যুক্ত করে একটি ফার্স্ট-পার্টি ডেটা প্রোফাইল তৈরি করতে প্রথমবার আসা অতিথির রেজিস্ট্রেশনের জন্য এটি ব্যবহার করুন।
ব্যবহারিক নিয়ম: গতির জন্য snsapi_base, ডেটার জন্য snsapi_userinfo ব্যবহার করুন। ব্যবহারকারীর OpenID ইতিমধ্যে আপনার ডেটাবেসে বিদ্যমান কিনা তা পরীক্ষা করে আপনি উভয়ই প্রয়োগ করতে পারেন। যদি থাকে, তবে snsapi_base অনুরোধ করুন। যদি না থাকে, তবে snsapi_userinfo অনুরোধ করুন।
নেটওয়ার্ক প্রয়োগ: RADIUS CoA এবং MAC বাইপাস
একটি OAuth টোকেন পরিচয় প্রমাণ করেএটি নেটওয়ার্ক উন্মুক্ত করে না। সফল প্রমাণীকরণকে একটি নেটওয়ার্ক পলিসি পরিবর্তনে রূপান্তর করতে একটি পৃথক মেকানিজম ব্যবহার করা আবশ্যক।
RADIUS Change of Authorisation (CoA), যা RFC 3576-এ সংজ্ঞায়িত, হলো স্ট্যান্ডার্ড পদ্ধতি। পোর্টাল সার্ভার একটি বৈধ OAuth টোকেন পাওয়ার পর, এটি ওয়্যারলেস কন্ট্রোলারে একটি CoA অনুরোধ পাঠায়। কন্ট্রোলার সেশনটি আপডেট করে, ডিভাইসটিকে walled garden VLAN (একটি সীমাবদ্ধ নেটওয়ার্ক সেগমেন্ট যা কেবল পোর্টাল ট্রাফিকের অনুমতি দেয়) থেকে সম্পূর্ণ গেস্ট VLAN-এ স্থানান্তরিত করে। এটি Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet-এর সাথে কাজ করে।
MAC address bypass সফল OAuth-এর পর ডিভাইসের MAC address-টিকে একটি অনুমোদিত ক্লায়েন্ট হিসেবে রেজিস্টার করে। কন্ট্রোলার তখন কোনো অতিরিক্ত চ্যালেঞ্জ ছাড়াই সেই অ্যাড্রেস থেকে ট্রাফিকের অনুমতি দেয়। এটি প্রয়োগ করা সহজ কিন্তু এতে দুটি ঝুঁকি রয়েছে: MAC address স্পুফ (spoof) করা যেতে পারে, এবং iOS 14 ও Android 10 থেকে পরবর্তী সংস্করণগুলো ডিফল্টভাবে MAC address র্যান্ডমাইজেশন ব্যবহার করে, যা পুনরায় সংযোগ করার সময় এই মেকানিজমটিকে নিষ্ক্রিয় করে দেয়।
নিরাপত্তা গুরুত্বপূর্ণ এমন যেকোনো স্থাপনার (deployment) জন্য, RADIUS CoA হলো সঠিক পছন্দ। গেস্ট নেটওয়ার্ক সুরক্ষিত করার বিষয়ে আরও জানতে, What Is Secure WiFi: ব্যবসায়িক গাইড ২০২৬ এবং Enterprise WiFi Security: ২০২৬ সালের একটি সম্পূর্ণ গাইড দেখুন।
ইমপ্লিমেন্টেশন গাইড
ডেপ্লয়মেন্ট-পূর্ব চেকলিস্ট
কনফিগারেশনের একটি লাইন লেখার আগেও, এই পাঁচটি ধাপ সম্পন্ন করুন।
প্রথমত, অ্যাক্সেস কনটেক্সট নির্ধারণ করুন। আপনার ভেন্যুটি জরিপ করুন এবং চিহ্নিত করুন যে অতিথিরা WeChat ইন-অ্যাপ ব্রাউজারের ভেতরে, একটি স্ট্যান্ডার্ড মোবাইল ব্রাউজারে, নাকি উভয় ক্ষেত্রেই পোর্টালটির মুখোমুখি হবেন। এই উত্তরটি আপনার প্ল্যাটফর্ম রেজিস্ট্রেশনের প্রয়োজনীয়তা নির্ধারণ করে।
can দ্বিতীয়ত, সঠিক প্ল্যাটফর্মে রেজিস্টার করুন। ইন-অ্যাপ ব্রাউজার অ্যাক্সেসের জন্য, WeChat Official Accounts Platform-এ একটি Service Account তৈরি করুন। স্ট্যান্ডার্ড ব্রাউজার অ্যাক্সেসের জন্য, WeChat Open Platform-এ একটি Website Application রেজিস্টার করুন। প্রতিটির জন্য আপনার AppID এবং AppSecret নোট করে রাখুন।
তৃতীয়ত, আপনার রিডাইরেক্ট URIs কনফিগার করুন। স্টেজিং এনভায়রনমেন্ট সহ আপনার পোর্টাল ব্যবহার করে এমন প্রতিটি ডোমেন এবং সাবডোমেন রেজিস্টার করুন। WeChat হুবহু মিল (exact-match) যাচাইকরণ প্রয়োগ করে। অমিল হলে error 40029 দেখাবে।
চতুর্থত, সার্ভার-সাইড টোকেন এক্সচেঞ্জ প্রয়োগ করুন। AppSecret কখনই ক্লায়েন্ট-সাইড কোডে প্রদর্শিত হওয়া উচিত নয়। একটি সার্ভার-সাইড এন্ডপয়েন্ট তৈরি করুন যা অথরাইজেশন কোড গ্রহণ করে, এটিকে একটি টোকেনের সাথে বিনিময় করে এবং কেবল আপনার পোর্টালের প্রয়োজনীয় ডেটা ফেরত দেয়।
পঞ্চমত, CSRF সুরক্ষার জন্য state প্যারামিটার প্রয়োগ করুন। একটি ক্রিপ্টোগ্রাফিকভাবে র্যান্ডম মান তৈরি করুন, এটি ব্যবহারকারীর সেশনে সংরক্ষণ করুন, OAuth অনুরোধে এটি পাস করুন এবং ফিরে আসার সময় এটি যাচাই করুন।
Ruckus SmartZone-এর জন্য কনফিগারেশন ধাপসমূহ
যেসব ভেন্যুতে Ruckus SmartZone চলছে, সেগুলোর জন্য WeChat পোর্টাল কনফিগারেশনটি Services and Profiles, তারপর Hotspots and Portals, এবং এরপর WeChat ট্যাবের অধীনে থাকে। আপনি Authentication URL (আপনার পোর্টাল সার্ভারের WeChat কলব্যাক এন্ডপয়েন্ট), DNAT Destination (যে সার্ভারটি অপ্রমাণিত ক্লায়েন্ট রিডাইরেক্ট পরিচালনা করে) এবং Grace Period (যে সময়ের মধ্যে সম্প্রতি সংযোগ বিচ্ছিন্ন হওয়া ব্যবহারকারী পুনরায় প্রমাণীকরণ ছাড়াই আবার সংযোগ করতে পারেন, যা ডিফল্টভাবে ৬০ মিনিট থাকে) কনফিগার করবেন। প্রমাণীকরণ পর্বের সময় WeChat-এর API এন্ডপয়েন্টগুলোতে ট্রাফিকের অনুমতি দেওয়ার জন্য আপনি walled garden হোয়াইটলিস্টও কনফিগার করবেন। অনুরূপ কন্ট্রোলার কনফিগারেশন প্যাটার্নের জন্য ধাপ-ভিত্তিক গাইড: গেস্ট WiFi Captive Portals-এর জন্য Ruijie ওয়্যারলেস কন্ট্রোলার কনফিগার করা দেখুন।
ইন-অ্যাপ ব্রাউজার সনাক্তকরণ
WeChat-এর ইন-অ্যাপ ব্রাউজার একটি ইউজার এজেন্ট স্ট্রিং সেট করে যাতে MicroMessenger থাকে। আপনার পোর্টালকে অবশ্যই এই স্ট্রিংটি সনাক্ত করতে হবে এবং উপযুক্ত OAuth ফ্লো প্রদান করতে হবে। যদি MicroMessenger উপস্থিত থাকে, তবে Official Accounts ফ্লো ব্যবহার করুন। অনুপস্থিত থাকলে, Open Platform QR কোড ফ্লো ব্যবহার করুন। এটি সঠিকভাবে সনাক্ত করতে ব্যর্থ হলে ত্রুটিপূর্ণ অভিজ্ঞতা বা প্রমাণীকরণ ত্রুটি তৈরি হতে পারে।
সর্বোত্তম অনুশীলনসমূহ
ডেটা মিনিমাইজেশন এবং ডুয়াল-ফ্রেমওয়ার্ক কমপ্লায়েন্স
GDPR (ইউরোপীয় দর্শকদের জন্য প্রযোজ্য) এবং PIPL (চীনা নাগরিকদের জন্য প্রযোজ্য) উভয়েরই ব্যক্তিগত ডেটা প্রক্রিয়াকরণের জন্য একটি আইনি ভিত্তি, স্পষ্ট উদ্দেশ্যের সীমাবদ্ধতা এবং ডেটা মিনিমাইজেশন প্রয়োজন। snsapi_base স্কোপটি ডেটা মিনিমাইজেশন নীতির অধীনে snsapi_userinfo-এর চেয়ে সহজে যুক্তিযুক্ত করা যায়। আপনি যখন snsapi_userinfo-এর মাধ্যমে ডেমোগ্রাফিক ডেটা সংগ্রহ করবেন, তখন আপনার আইনি ভিত্তি, আপনার ডেটা সংরক্ষণের সময়কাল এবং Tencent-এর সাথে আপনার ডেটা প্রক্রিয়াকরণ চুক্তিটি নথিবদ্ধ করুন।
PILP, যা নভেম্বর ২০২১ থেকে কার্যকর, সংবেদনশীল ব্যক্তিগত তথ্যের জন্য স্পষ্ট সম্মতির প্রয়োজন হয় এবং নির্দেশ দেয় যে চীনের বাইরের ডেটা প্রসেসরদের সমমানের সুরক্ষা মানদণ্ড প্রয়োগ করতে হবে। যদি আপনার পোর্টাল সার্ভারটি মূল ভূখণ্ড চীনের বাইরে অবস্থিত হয়, তবে আপনাকে মূল্যায়ন করতে হবে যে আপনার প্রাপ্ত WeChat OpenID এবং প্রোফাইল ডেটার ক্ষেত্রে আন্তঃসীমান্ত ডেটা স্থানান্তর নিয়ম প্রযোজ্য কিনা।
বহু-সম্পত্তি ডেপ্লয়মেন্টের জন্য UnionID
প্রতিটি Official Account-এর জন্য প্রতি ব্যবহারকারীর OpenID অনন্য। আপনি যদি বিভিন্ন সম্পত্তিতে একাধিক Official Account পরিচালনা করেন, তবে একই অতিথির প্রতিটিতে আলাদা OpenID থাকবে। WeChat একটি UnionID প্রদান করে যা একই Open Platform রেজিস্ট্রেশনের সাথে লিঙ্কযুক্ত সমস্ত অ্যাকাউন্টে অভিন্ন থাকে। হোটেল চেইন, রিটেইল গ্রুপ বা বিমানবন্দর অপারেটর যারা একাধিক ভেন্যু পরিচালনা করছেন, তাদের জন্য শুরু থেকেই UnionID-ভিত্তিক পরিচয় রেজোলিউশন প্রয়োগ করুন।
সিকিউরিটি হার্ডেনিং
AppSecret-টি একটি এনভায়রনমেন্ট ভেরিয়েবল বা সিক্রেটস ম্যানেজারে সংরক্ষণ করুন, কখনই সোর্স কোডে নয়। যদি আপনি এটি উন্মুক্ত হওয়ার সন্দেহ করেন তবে অবিলম্বে এটি পরিবর্তন (rotate) করুন। অপব্যবহার রোধ করতে আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্টে রেট লিমিটিং প্রয়োগ করুন। সমস্ত OAuth ত্রুটি লগ করুন, বিশেষ করে 40029 (অবৈধ কোড) এবং 40163 (কোডের মেয়াদ শেষ), কারণ এগুলো ভুল কনফিগারেশন বা সক্রিয় অনুসন্ধানের ইঙ্গিত দেয়।
গেস্ট নেটওয়ার্ক সিকিউরিটি আর্কিটেকচারের আরও বিস্তৃত ধারণার জন্য, কেন কনজিউমার WiFi গিয়ার আপনার গেস্ট নেটওয়ার্কের জন্য উপযুক্ত নয় দেখুন।
কেস স্টাডিজ
লাক্সারি হোটেল চেইন, সিঙ্গাপুর
সিঙ্গাপুরের একটি ৩৫০-রুমের লাক্সারি হোটেল, যা মূলত চীনা ব্যবসায়িক ভ্রমণকারীদের সেবা প্রদান করে, তাদের বিদ্যমান ইমেল লগইন অপশনের পাশাপাশি WeChat WiFi প্রমাণীকরণ প্রয়োগ করেছে। এটি বাস্তবায়নের আগে, ফ্রন্ট-ডেস্ক কর্মীরা গড়ে একটিWiFi লগইন জটিলতা নিয়ে প্রতিদিন ১৫টি অতিথি অভিযোগ আসছিল। চীনা অতিথিরা এমন ইমেল ঠিকানা ব্যবহার করার চেষ্টা করছিলেন যা তারা তাদের ভ্রমণ ডিভাইসে কনফিগার করেননি।
হোটেলটি WeChat অফিসিয়াল অ্যাকাউন্টস প্ল্যাটফর্মে একটি সার্ভিস অ্যাকাউন্ট এবং ওপেন প্ল্যাটফর্ম-এ একটি ওয়েবসাইট অ্যাপ্লিকেশন রেজিস্টার করেছে। তারা প্রথমবার সংযোগের জন্য snsapi_userinfo এবং MAC অ্যাড্রেস দ্বারা চিহ্নিত ফিরে আসা অতিথিদের জন্য snsapi_base কনফিগার করেছে। সেশন প্রমোশন পরিচালনা করার জন্য HPE Aruba কন্ট্রোলারটি RADIUS CoA-এর জন্য কনফিগার করা হয়েছিল।
৩০ দিনের মধ্যে, অতিথি WiFi লগইন সংক্রান্ত অভিযোগ প্রতিদিন দুটির নিচে নেমে এসেছে। প্রথম মাসেই হোটেলের WiFi অ্যানালিটিক্স ডেটাবেস ৪,২০০টি যাচাইকৃত ফার্স্ট-পার্টি প্রোফাইল দ্বারা বৃদ্ধি পেয়েছে, যেখানে শহর-স্তরের ডেমোগ্রাফিক ডেটা থাকা-পরবর্তী টার্গেটেড যোগাযোগ সক্ষম করেছে।
আন্তর্জাতিক রিটেইল মল, কুয়ালালামপুর
শুধুমাত্র মালয়েশিয়াতেই ১২ মিলিয়ন WeChat ব্যবহারকারী থাকা কুয়ালালামপুরের একটি প্রিমিয়াম রিটেইল মলের এমন একটি WiFi অনবোর্ডিং অভিজ্ঞতার প্রয়োজন ছিল যা তার ক্রেতাদের ডিজিটাল প্রত্যাশার সাথে সামঞ্জস্যপূর্ণ হয়। মলটি ১৮০,০০০ বর্গমিটার রিটেইল ফ্লোর জুড়ে Cisco Meraki অ্যাক্সেস পয়েন্ট পরিচালনা করত।
এই ডেপ্লয়মেন্টে ক্লাউড ওভারলে হিসেবে Purple-এর গেস্ট WiFi প্ল্যাটফর্ম ব্যবহার করা হয়েছিল, যেখানে প্রাথমিক অথেন্টিকেশন পদ্ধতি হিসেবে WeChat OAuth এবং ফলব্যাক হিসেবে SMS OTP ব্যবহার করা হয়েছিল। Purple-এর হার্ডওয়্যার-নিরপেক্ষ আর্কিটেকচার কোনো কাস্টম ডেভেলপমেন্ট ছাড়াই Cisco Meraki-এর সাথে RADIUS CoA ইন্টিগ্রেশন পরিচালনা করেছে।
ডেপ্লয়মেন্টের পর প্রথম প্রান্তিকে মলটি WiFi সেশন শুরুর ক্ষেত্রে ৩৪% বৃদ্ধি রেকর্ড করেছে, যার কারণ ছিল WeChat ব্যবহারকারীদের জন্য অনবোর্ডিং জটিলতা হ্রাস পাওয়া। snsapi_userinfo সম্মতি প্রবাহের মাধ্যমে সংগৃহীত ফার্স্ট-পার্টি ডেটা মলের মার্কেটিং টিমকে টার্গেটেড ক্যাম্পেইন ডেলিভারির জন্য ক্রেতাদের তাদের নিজ শহর অনুযায়ী সেগমেন্ট করতে সক্ষম করেছে।
ট্রাবলশুটিং এবং ঝুঁকি প্রশমন
| ত্রুটি | কারণ | সমাধান |
|---|---|---|
| 40029 invalid code | Redirect URI অমিল বা কোডের পুনরায় ব্যবহার | রেজিস্টারকৃত URI-গুলো হুবহু মিলছে কিনা তা যাচাই করুন; কোডগুলো একবারই ব্যবহারযোগ্য |
| 40163 code expired | টোকেন এক্সচেঞ্জ ৫ মিনিটের বেশি বিলম্বিত হয়েছে | সার্ভার-সাইড প্রসেসিং সময় হ্রাস করুন; রিট্রাই লজিক প্রয়োগ করুন |
| অথেন্টিকেশনের পর ফাঁকা স্ক্রিন | RADIUS CoA কনফিগার করা হয়নি বা ব্যর্থ হচ্ছে | UDP পোর্ট ৩৭৯৯-এ কন্ট্রোলার CoA সেটিংস এবং ফায়ারওয়াল নিয়মগুলো পরীক্ষা করুন |
| MAC র্যান্ডমাইজেশন ফিরে আসা অতিথির প্রবাহকে ব্যাহত করে | iOS/Android MAC র্যান্ডমাইজেশন | OpenID-ভিত্তিক সেশন ট্র্যাকিংয়ে স্থানান্তরিত হন; শুধুমাত্র MAC-ভিত্তিক সনাক্তকরণ এড়িয়ে চলুন |
| snsapi_userinfo খালি ফিল্ড রিটার্ন করে | ব্যবহারকারী WeChat প্রাইভেসি সীমাবদ্ধতা সেট করেছেন | নাল (null) ফিল্ডগুলো সঠিকভাবে হ্যান্ডেল করুন; অ্যাক্সেসের জন্য প্রোফাইল ডেটার বাধ্যবাধকতা রাখবেন না |
ROI এবং ব্যবসায়িক প্রভাব
WeChat WiFi অথেন্টিকেশনের ব্যবসায়িক গুরুত্ব তিনটি পরিমাপযোগ্য ফলাফলের ওপর নির্ভর করে।
ফার্স্ট-পার্টি ডেটা সংগ্রহ। প্রতিটি snsapi_userinfo অথেন্টিকেশন ডেমোগ্রাফিক ডেটা সহ একটি যাচাইকৃত অতিথি প্রোফাইল তৈরি করে। ৭০% অকুপেন্সি এবং ৪০% চীনা অতিথি থাকা একটি ২০০ রুমের হোটেলের জন্য, এটি বছরে প্রায় ২০,০০০ নতুন যাচাইকৃত প্রোফাইলের প্রতিনিধিত্ব করে, যার প্রতিটি একটি WeChat আইডির সাথে যুক্ত থাকে যা চলমান পুনরায় যুক্ত করার প্রক্রিয়াকে সমর্থন করে।
সাপোর্ট প্রদানের চাপ হ্রাস। লগইন জটিলতা হলো অতিথি WiFi সাপোর্ট কলের প্রধান কারণ। যেসব ভেন্যু বিদ্যমান বিকল্পগুলোর পাশাপাশি WeChat অথেন্টিকেশন যুক্ত করে, তারা ক্রমাগত WiFi-সম্পর্কিত ফ্রন্ট-ডেস্ক জিজ্ঞাসার হার হ্রাসের কথা জানায়, যা কর্মীদের আরও গুরুত্বপূর্ণ কাজে সময় দেওয়ার সুযোগ করে দেয়।
মার্কেটিং পরিধি। WeChat অফিসিয়াল অ্যাকাউন্টস ভেন্যুগুলোকে ফলোয়ারদের কাছে নোটিফিকেশন পুশ করার অনুমতি দেয়। আপনার অফিসিয়াল অ্যাকাউন্টের মাধ্যমে অথেন্টিকেট করা কোনো অতিথিকে এটি ফলো করার জন্য অনুরোধ জানানো যেতে পারে, যা WeChat-এর ইকোসিস্টেমের মধ্যে একটি সরাসরি যোগাযোগের চ্যানেল তৈরি করে, যেখানে চীনা ভোক্তারা প্রতিদিন গড়ে ৮২ মিনিট সময় ব্যয় করেন (উৎস: Walk the Chat)।
Purple-এর Engage প্ল্যান এটিকে আরও প্রসারিত করে, যা WiFi অথেন্টিকেশনের সময় সংগৃহীত ফার্স্ট-পার্টি ডেটার ওপর ভিত্তি করে তৈরি করা অটোমেটেড পোস্ট-ভিজিট মেসেজিং, লয়্যালটি ট্রিগার এবং সেগমেন্টেড ক্যাম্পেইন সক্ষম করে।
মূল সংজ্ঞাসমূহ
Captive portal
একটি ওয়েব-ভিত্তিক অথেন্টিকেশন গেটওয়ে যা একটি আন-অথেন্টিকেটেড ডিভাইস থেকে HTTP ট্রাফিককে বাধা দেয় এবং নেটওয়ার্ক অ্যাক্সেস দেওয়ার আগে এটিকে একটি লগইন পৃষ্ঠায় রিডাইরেক্ট করে।
যে মেকানিজমের মাধ্যমে অতিথিদের WiFi অথেন্টিকেশন ব্যবহারকারীদের কাছে উপস্থাপন করা হয়। WeChat OAuth হলো কয়েকটি অথেন্টিকেশন পদ্ধতির মধ্যে একটি যা একটি captive portal অফার করতে পারে।
OAuth 2.0
একটি ইন্ডাস্ট্রি-স্ট্যান্ডার্ড অথরাইজেশন প্রোটোকল যা একটি তৃতীয় পক্ষের অ্যাপ্লিকেশনকে (captive portal) ব্যবহারকারীর পক্ষে একটি ওয়েব পরিষেবাতে (WeChat) সীমিত অ্যাক্সেস পাওয়ার অনুমতি দেয়, ব্যবহারকারীকে তৃতীয় পক্ষের সাথে তাদের পাসওয়ার্ড শেয়ার না করেই।
অন্তর্নিহিত ফ্রেমওয়ার্ক যা WeChat লগইনকে সম্ভব করে তোলে। পোর্টাল কখনই ব্যবহারকারীর WeChat ক্রেডেনশিয়াল দেখতে পায় না; এটি কেবল একটি টোকেন পায় যা নিশ্চিত করে যে WeChat তাদের অথেন্টিকেট করেছে।
RADIUS CoA
Change of Authorisation। RFC 3576-এ সংজ্ঞায়িত একটি মেকানিজম যা একটি RADIUS সার্ভারকে একটি সক্রিয় নেটওয়ার্ক ক্লায়েন্টের সেশন অথরাইজেশন বৈশিষ্ট্যগুলি গতিশীলভাবে সংশোধন করার অনুমতি দেয়, যেমন VLAN অ্যাসাইনমেন্ট পরিবর্তন করা।
নেটওয়ার্ক প্রয়োগের মেকানিজম যা একটি সফল WeChat OAuth বিনিময়কে প্রকৃত নেটওয়ার্ক অ্যাক্সেসে রূপান্তর করে। CoA ছাড়া, অতিথি অথেন্টিকেট হয় কিন্তু কন্ট্রোলার নেটওয়ার্ক খুলতে জানে না।
OpenID
একটি নির্দিষ্ট Official Account বা Website Application-এর জন্য একটি নির্দিষ্ট ব্যবহারকারীকে WeChat দ্বারা বরাদ্দ করা একটি অনন্য আইডেন্টিফায়ার। এটি সেশন জুড়ে স্থিতিশীল কিন্তু অ্যাকাউন্ট জুড়ে ভিন্ন হয়।
আপনার WiFi অ্যানালিটিক্স ডেটাবেসে একজন অতিথিকে সনাক্ত করতে ব্যবহৃত প্রাথমিক কী। আপনি যদি একাধিক Official Accounts পরিচালনা করেন এবং ক্রস-অ্যাকাউন্ট পরিচয় রেজোলিউশনের প্রয়োজন হয় তবে পরিবর্তে UnionID ব্যবহার করুন।
snsapi_base
একটি WeChat OAuth স্কোপ যা সম্মতি প্রম্পট প্রদর্শন না করেই কেবল ব্যবহারকারীর OpenID ফেরত দিয়ে নীরব অথেন্টিকেশন সক্ষম করে।
ফিরে আসা অতিথি বা উচ্চ-থ্রুপুট পরিবেশের জন্য ব্যবহার করুন যেখানে সংযোগের গতি অগ্রাধিকার পায়। OpenID ছাড়া অন্য কোনো ডেমোগ্রাফিক ডেটা ফেরত দেয় না।
snsapi_userinfo
একটি WeChat OAuth স্কোপ যা ব্যবহারকারীর OpenID, ডাকনাম, প্রোফাইল ছবি, লিঙ্গ, ভাষা এবং শহর ফেরত দেয়, যার জন্য একটি স্পষ্ট ব্যবহারকারীর সম্মতি স্ক্রিন প্রয়োজন।
একটি ফার্স্ট-পার্টি ডেটা প্রোফাইল তৈরি করতে প্রথমবার আসা অতিথির রেজিস্ট্রেশনের জন্য ব্যবহার করুন। অবশ্যই একটি GDPR এবং PIPL-সম্মত সম্মতি স্তরের সাথে যুক্ত হতে হবে।
PIPL
Personal Information Protection Law। চীনের ব্যাপক ডেটা গোপনীয়তা আইন, যা নভেম্বর ২০২১ থেকে কার্যকর হয়েছে, যা চীনা নাগরিকদের ব্যক্তিগত ডেটা কীভাবে সংগ্রহ, প্রক্রিয়াকরণ এবং স্থানান্তর করতে হবে তা নিয়ন্ত্রণ করে।
যেকোনো ভেন্যুর ক্ষেত্রে প্রযোজ্য যা WeChat OAuth-এর মাধ্যমে চীনা নাগরিকদের কাছ থেকে ডেটা সংগ্রহ করে, ভেন্যুটি যেখানেই অবস্থিত হোক না কেন। এর জন্য স্পষ্ট সম্মতি, উদ্দেশ্যের সীমাবদ্ধতা এবং ডেটা মিনিমাইজেশন প্রয়োজন।
AppSecret
WeChat দ্বারা জারি করা একটি গোপনীয় ক্রিপ্টোগ্রাফিক কী যা আপনার অ্যাপ্লিকেশনটিকে অথেন্টিকেট করে যখন এটি WeChat-এর টোকেন বিনিময় API কল করে।
শুধুমাত্র সার্ভার সাইডে সংরক্ষণ করতে হবে। ক্লায়েন্ট-সাইড কোডে প্রকাশ পেলে যেকোনো পক্ষকে আপনার অ্যাপ্লিকেশনের ছদ্মবেশ ধারণ করতে এবং WeChat-এ অননুমোদিত API কল করার অনুমতি দেয়।
VLAN
Virtual Local Area Network। একটি লজিক্যাল নেটওয়ার্ক সেগমেন্ট যা ডেটা লিঙ্ক স্তরে ট্রাফিককে আলাদা করে, একটি একক ফিজিক্যাল নেটওয়ার্ককে একাধিক বিচ্ছিন্ন ট্রাফিক স্ট্রিম বহন করার অনুমতি দেয়।
আন-অথেন্টিকেটেড ডিভাইসগুলিকে (walled garden VLAN) অথেন্টিকেটেড অতিথিদের (গেস্ট VLAN) থেকে আলাদা করতে captive portal ডেপ্লয়মেন্টে ব্যবহৃত হয়। সফল অথেন্টিকেশনের পর RADIUS CoA একটি ডিভাইসকে VLAN-এর মধ্যে স্থানান্তরিত করে।
UnionID
একটি WeChat আইডেন্টিফায়ার যা একই Open Platform রেজিস্ট্রেশনের সাথে লিঙ্কযুক্ত সমস্ত Official Accounts এবং Website Applications জুড়ে একটি নির্দিষ্ট ব্যবহারকারীর জন্য সামঞ্জস্যপূর্ণ থাকে।
হোটেল চেইন, রিটেইল গ্রুপ এবং বহু-ভেন্যু অপারেটরদের জন্য অপরিহার্য যাদের একাধিক প্রপার্টি জুড়ে একই অতিথিকে চিনতে হবে, যার প্রতিটির নিজস্ব Official Account রয়েছে।
সমাধানকৃত উদাহরণসমূহ
সিঙ্গাপুরের একটি ২০০-রুমের বিলাসবহুল হোটেল HPE Aruba কন্ট্রোলার ব্যবহার করে এবং প্রচুর পরিমাণে চীনা ব্যবসায়িক ভ্রমণকারীদের পরিষেবা দেয়। তারা প্রথমবার আসা অতিথিদের কাছ থেকে ডেমোগ্রাফিক ডেটা সংগ্রহ করতে চায় এবং ফিরে আসা অতিথিরা যাতে পোর্টালটি পুনরায় না দেখেই স্বয়ংক্রিয়ভাবে সংযুক্ত হতে পারে তা নিশ্চিত করতে চায়। তাদের কীভাবে WeChat OAuth ইন্টিগ্রেশন কনফিগার করা উচিত?
ধাপ ১: WeChat ইন-অ্যাপ ব্রাউজারের ভিতরে পোর্টাল অ্যাক্সেস করা অতিথিদের পরিচালনা করতে WeChat Official Accounts Platform (mp.weixin.qq.com)-এ একটি Service Account রেজিস্টার করুন। স্ট্যান্ডার্ড মোবাইল ব্রাউজারে থাকা অতিথিদের জন্য WeChat Open Platform (open.weixin.qq.com)-এ একটি Website Application রেজিস্টার করুন।
ধাপ ২: MicroMessenger ইউজার এজেন্ট স্ট্রিং সনাক্ত করতে captive portal কনফিগার করুন। ইন-অ্যাপ ব্রাউজার ব্যবহারকারীদের জন্য Official Accounts OAuth ফ্লো এবং স্ট্যান্ডার্ড ব্রাউজার ব্যবহারকারীদের জন্য Open Platform QR কোড ফ্লো পরিবেশন করুন।
ধাপ ৩: প্রথমবার সংযোগের জন্য (ডেটাবেসে কোনো বিদ্যমান OpenID নেই), snsapi_userinfo স্কোপের অনুরোধ করুন। OAuth রিডাইরেক্টের আগে একটি PIPL-সম্মত সম্মতি স্ক্রিন প্রদর্শন করুন। ফিরে আসা OpenID, ডাকনাম, শহর এবং লিঙ্গ অতিথি প্রোফাইল ডেটাবেসে সংরক্ষণ করুন।
ধাপ ৪: ফিরে আসা অতিথিদের জন্য (ডেটাবেসে OpenID বিদ্যমান), snsapi_base স্কোপের অনুরোধ করুন। এটি ব্যবহারকারীর কাছে দৃশ্যমান কোনো প্রম্পট ছাড়াই নীরবে অথেন্টিকেট করে।
ধাপ ৫: UDP পোর্ট ৩৭৯৯-এ RADIUS CoA-এর জন্য HPE Aruba কন্ট্রোলার কনফিগার করুন। সফল OAuth-এর পরে, পোর্টাল সার্ভার ডিভাইসটিকে ওয়াল্ড গার্ডেন VLAN থেকে গেস্ট VLAN-এ উন্নীত করার জন্য একটি CoA অনুরোধ পাঠায়।
ধাপ ৬: ফিরে আসা অতিথি সনাক্তকরণ পরিচালনা করতে OpenID-এর পাশাপাশি MAC অ্যাড্রেস লগিং প্রয়োগ করুন। মনে রাখবেন যে MAC র্যান্ডমাইজেশনের জন্য প্রাথমিক আইডেন্টিফায়ার হিসেবে OpenID প্রয়োজন, শুধুমাত্র MAC অ্যাড্রেস নয়।
একটি রিটেইল চেইনের আইটি টিম তিনটি মল লোকেশন জুড়ে WeChat WiFi লগইনের উচ্চ ব্যর্থতার হারের রিপোর্ট করেছে। ব্যবহারকারীরা WeChat-এ অথেন্টিকেট করেন কিন্তু একটি ত্রুটি সহ পোর্টাল পৃষ্ঠায় ফিরে আসেন। পোর্টাল লগগুলি ত্রুটি 40029 দেখায়। এর সম্ভাব্য কারণ কী এবং আপনি কীভাবে এটি সমাধান করবেন?
ত্রুটি 40029-এর অর্থ হলো টোকেন বিনিময়ের সময় WeChat অথরাইজেশন কোডটি প্রত্যাখ্যান করেছে। দুটি সবচেয়ে সাধারণ কারণ হলো রিডাইরেক্ট URI অমিল এবং কোডের পুনরায় ব্যবহার।
ধাপ ১: Official Accounts Platform এবং Open Platform উভয়ের জন্য WeChat ডেভেলপার কনসোলে লগ ইন করুন। OAuth সেটিংসে যান এবং সমস্ত রেজিস্টার্ড রিডাইরেক্ট URI তালিকাভুক্ত করুন।
ধাপ ২: তিনটি লোকেশন জুড়েই প্রোডাকশনে আপনার পোর্টাল সার্ভার যে প্রকৃত রিডাইরেক্ট URI ব্যবহার করে সেগুলির সাথে এগুলি তুলনা করুন। সাবডোমেন পার্থক্য (portal.brand.com বনাম brand.com), প্রোটোকল পার্থক্য (HTTP বনাম HTTPS), এবং পাথ পার্থক্য (/callback বনাম /wechat/callback) পরীক্ষা করুন।
ধাপ ৩: WeChat কনসোলে প্রতিটি ভেরিয়েন্ট রেজিস্টার করুন। WeChat হুবহু মিল (exact-match) যাচাইকরণ করে, প্রিফিক্স মিল নয়।
ধাপ ৪: যদি URI-গুলি মিলে যায়, তবে আপনার পোর্টাল সার্ভার অথরাইজেশন কোডগুলি পুনরায় ব্যবহার করার চেষ্টা করছে কিনা তা তদন্ত করুন। WeChat কোডগুলি একবার ব্যবহারযোগ্য এবং পাঁচ মিনিট পরে মেয়াদ শেষ হয়ে যায়। যদি আপনার সার্ভার একই কোড দিয়ে টোকেন বিনিময় পুনরায় চেষ্টা করে, তবে এটি দ্বিতীয় চেষ্টায় 40029 ত্রুটি পাবে।
ধাপ ৫: ডুপ্লিকেট অনুরোধ প্রতিরোধ করতে টোকেন বিনিময় এন্ডপয়েন্টে আইডেমপোটেন্সি (idempotency) প্রয়োগ করুন।
অনুশীলনী প্রশ্নসমূহ
Q1. আপনি একটি ৬০,০০০-ক্ষমতার স্টেডিয়ামের জন্য একটি captive portal ডেপ্লয় করছেন যা উল্লেখযোগ্য চীনা ফ্যান বেস সহ আন্তর্জাতিক ইভেন্টগুলি হোস্ট করে। সেলুলার কনজেশন কমাতে দরজা খোলার প্রথম ১৫ মিনিটের মধ্যে সমস্ত উপস্থিতিদের অনলাইন করা অগ্রাধিকার। মার্কেটিং ডেটা সংগ্রহ একটি গৌণ উদ্দেশ্য। আপনার কোন WeChat OAuth স্কোপ কনফিগার করা উচিত এবং কেন?
ইঙ্গিত: একটি পোর্টাল সার্ভারে ১৫,০০০ যুগপৎ ব্যবহারকারীর কাছে প্রদর্শিত সম্মতি স্ক্রিনের প্রভাব বিবেচনা করুন।
মডেল উত্তর দেখুন
snsapi_base স্কোপ কনফিগার করুন। এটি ব্যবহারকারীর সম্মতি প্রম্পট ছাড়াই নীরব অথেন্টিকেশন সক্ষম করে, যা দ্রুততম অনবোর্ডিং অভিজ্ঞতা প্রদান করে। স্টেডিয়ামের স্কেলে, একটি সম্মতি স্ক্রিন ঘর্ষণ যোগ করে যা হাজার হাজার যুগপৎ সংযোগ জুড়ে বাড়ে এবং পোর্টাল সার্ভার লোড স্পাইক ঘটাতে পারে। snsapi_base কেবল OpenID ফেরত দেয়, যা সেশন লগ করতে এবং ফিরে আসা ভক্তদের সনাক্ত করতে যথেষ্ট। প্রথমবার আসা ভক্তদের জন্য যেখানে আপনি ডেমোগ্রাফিক ডেটা চান, আপনি অথেন্টিকেশন গেটের পরিবর্তে সংযোগ-পরবর্তী সমীক্ষার মাধ্যমে প্রোফাইল সম্পূর্ণ করার জন্য অনুরোধ করতে পারেন।
Q2. আপনার টিমের একজন নেটওয়ার্ক আর্কিটেক্ট ব্রাউজার থেকে সরাসরি টোকেন বিনিময় কল করে সার্ভার রাউন্ড-ট্রিপ কমাতে captive portal-এর ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টে WeChat AppSecret সংরক্ষণ করার প্রস্তাব করেছেন। এই পদ্ধতিটি কেন একটি গুরুতর নিরাপত্তা ব্যর্থতা এবং সঠিক আর্কিটেকচার কী তা ব্যাখ্যা করুন।
ইঙ্গিত: ক্লায়েন্ট-সাইড কোড কে দেখতে পারে এবং AppSecret তাদের কী করার অনুমতি দেয় তা বিবেচনা করুন।
মডেল উত্তর দেখুন
ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টে AppSecret সংরক্ষণ করা এটিকে এমন যেকোনো ব্যক্তির কাছে উন্মুক্ত করে দেয় যে পৃষ্ঠার সোর্স কোড দেখে বা নেটওয়ার্ক ট্রাফিক ইন্টারসেপ্ট করে। AppSecret আপনার অ্যাপ্লিকেশনটিকে WeChat-এর API-এর কাছে অথেন্টিকেট করে। এটির সাহায্যে, একজন ক্ষতিকারক ব্যক্তি আপনার অ্যাপ্লিকেশনের ছদ্মবেশ ধারণ করতে পারে, যেকোনো বৈধ অথরাইজেশন কোড দিয়ে WeChat-এর টোকেন বিনিময় এন্ডপয়েন্ট কল করতে পারে, ব্যবহারকারীর OpenID এবং প্রোফাইল ডেটা পুনরুদ্ধার করতে পারে এবং সম্ভাব্যভাবে আপনার API রেট লিমিট শেষ করে দিতে পারে। সঠিক আর্কিটেকচার হলো একটি সার্ভার-সাইড টোকেন বিনিময় এন্ডপয়েন্ট। ব্রাউজার WeChat থেকে অথরাইজেশন কোড গ্রহণ করে এবং এটি আপনার সার্ভারে পাঠায়। আপনার সার্ভার, একটি এনভায়রনমেন্ট ভেরিয়েবল বা সিক্রেটস ম্যানেজারে সংরক্ষিত AppSecret ব্যবহার করে, টোকেনের জন্য কোডটি বিনিময় করে এবং কেবল পোর্টালের প্রয়োজনীয় ডেটা ফেরত দেয়। AppSecret কখনই আপনার সার্ভার ছেড়ে যায় না।
Q3. আপনার ভেন্যুটি বিভিন্ন শহরে তিনটি হোটেল প্রপার্টি পরিচালনা করে, যার প্রতিটির নিজস্ব WeChat Official Account রয়েছে। একজন লয়্যালটি প্রোগ্রামের সদস্য যিনি তিনটি প্রপার্টিতেই অথেন্টিকেট করেছেন তার আপনার ডেটাবেসে তিনটি ভিন্ন OpenID রয়েছে। আপনি কীভাবে এটিকে একটি একক অতিথি পরিচয়ে সমাধান করবেন?
ইঙ্গিত: WeChat ক্রস-অ্যাকাউন্ট পরিচয় রেজোলিউশনের জন্য একটি মেকানিজম প্রদান করে যার জন্য একটি নির্দিষ্ট প্ল্যাটফর্ম কনফিগারেশন প্রয়োজন।
মডেল উত্তর দেখুন
WeChat-এর UnionID মেকানিজম প্রয়োগ করুন। open.weixin.qq.com-এ একই Open Platform রেজিস্ট্রেশনের সাথে তিনটি Official Accounts-ই লিঙ্ক করুন। একবার লিঙ্ক হয়ে গেলে, WeChat snsapi_userinfo রেসপন্সে OpenID-এর পাশাপাশি একটি UnionID ফেরত দেয়। একই Open Platform রেজিস্ট্রেশনের সাথে লিঙ্কযুক্ত সমস্ত অ্যাকাউন্ট জুড়ে একটি নির্দিষ্ট ব্যবহারকারীর জন্য UnionID সামঞ্জস্যপূর্ণ থাকে। ক্রস-প্রপার্টি রেকর্ডের জন্য UnionID-কে প্রাথমিক অতিথি আইডেন্টিফায়ার হিসেবে ব্যবহার করতে আপনার ডেটাবেস মাইগ্রেট করুন, অ্যাকাউন্ট-নির্দিষ্ট API কলের জন্য প্রতি-অ্যাকাউন্ট OpenID বজায় রাখুন। UnionID প্রয়োগ করার আগে অথেন্টিকেট করা অতিথিদের জন্য, UnionID ক্যাপচার করতে তাদের পরবর্তী ভিজিটে snsapi_userinfo সহ একটি রি-অথেন্টিকেশন ট্রিগার করুন।
Q4. Cisco Meraki অ্যাক্সেস পয়েন্ট চালিত একটি রিটেইল ভেন্যুতে WeChat WiFi অথেন্টিকেশন ডেপ্লয় করার পরে, অতিথিরা রিপোর্ট করছেন যে তারা সফলভাবে WeChat লগইন সম্পন্ন করেছেন কিন্তু পোর্টাল পৃষ্ঠায় ফিরে এসেছেন এবং ইন্টারনেট ব্রাউজ করতে পারছেন না। পোর্টাল সার্ভার লগগুলি সফল টোকেন পুনরুদ্ধার দেখায়। সবচেয়ে সম্ভাব্য কারণ কী এবং আপনি কীভাবে এটি নির্ণয় করবেন?
ইঙ্গিত: পোর্টাল পরিচয় যাচাই করেছে। এখনও কী ঘটেনি?
মডেল উত্তর দেখুন
RADIUS Change of Authorisation (CoA) সম্পন্ন হচ্ছে না। পোর্টাল সার্ভার WeChat OAuth-এর মাধ্যমে অতিথির পরিচয় যাচাই করেছে কিন্তু ডিভাইসটিকে ওয়াল্ড গার্ডেন VLAN থেকে গেস্ট VLAN-এ স্থানান্তরিত করার জন্য Cisco Meraki কন্ট্রোলারকে সফলভাবে নির্দেশ দেয়নি। এটি পরীক্ষা করে নির্ণয় করুন: (১) Meraki কন্ট্রোলারে RADIUS CoA সক্ষম করা আছে কিনা এবং পোর্টাল সার্ভারের IP একটি অনুমোদিত CoA ক্লায়েন্ট হিসেবে তালিকাভুক্ত আছে কিনা; (২) পোর্টাল সার্ভার এবং কন্ট্রোলারের মধ্যে UDP পোর্ট ৩৭৯৯ খোলা আছে কিনা; (৩) CoA অনুরোধের ত্রুটি বা টাইমআউটের জন্য পোর্টাল সার্ভার লগ; এবং (৪) উভয় পাশে কনফিগার করা শেয়ার্ড সিক্রেট মেলে কিনা। যদি আপনার Meraki লাইসেন্স টায়ারে CoA সমর্থিত না হয়, তবে MAC অ্যাড্রেস বাইপাস হলো ফলব্যাক, যদিও এটি নির্দেশিকায় উল্লিখিত MAC র্যান্ডমাইজেশনের ঝুঁকি বহন করে।
এই সিরিজে পড়া চালিয়ে যান
Starlink-এ কীভাবে একটি Captive Portal সেট আপ করবেন: দূরবর্তী এবং সামুদ্রিক ভেন্যুগুলোর জন্য একটি নির্দেশিকা
এই নির্দেশিকাটিতে কীভাবে নেটিভ Starlink হার্ডওয়্যার বাইপাস করতে হয় এবং এন্টারপ্রাইজ রাউটিং সরঞ্জাম ব্যবহার করে একটি ক্লাউড-পরিচালিত captive portal সংহত করতে হয় তা বিস্তারিতভাবে আলোচনা করা হয়েছে। আপনি কীভাবে CGNAT সীমাবদ্ধতা কাটিয়ে উঠবেন, VLAN সেগমেন্টেশন প্রয়োগ করবেন, স্যাটেলাইট ব্যান্ডউইথ সীমাবদ্ধতা পরিচালনা করবেন এবং নিয়ন্ত্রক সম্মতি নিশ্চিত করবেন তা শিখবেন।
Captive Portal-এর সর্বোত্তম অনুশীলনসমূহ: উচ্চ কনভার্সন এবং কমপ্লায়েন্সের জন্য ডিজাইন
এই টেকনিক্যাল গাইডটি IT ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং ভেন্যু অপারেশন ডিরেক্টরদের জন্য নেটওয়ার্ক সিকিউরিটির সাথে উচ্চ ইউজার কনভার্সনের ভারসাম্য বজায় রেখে captive portals স্থাপনের একটি সম্পূর্ণ ব্লুপ্রিন্ট প্রদান করে। এটি VLAN সেগমেন্টেশন এবং RADIUS অথেন্টিকেশন থেকে শুরু করে GDPR-সম্মত সম্মতি (consent) ডিজাইন এবং অথেন্টিকেশন পদ্ধতি নির্বাচন পর্যন্ত সম্পূর্ণ আর্কিটেকচার কভার করে। ২০২৪ সালে ৮০,০০০-এরও বেশি ভেন্যু এবং ৪৪০ মিলিয়ন লগইনে Purple-এর অপারেশনাল অভিজ্ঞতা থেকে নেওয়া প্রতিটি সুপারিশ বাস্তব ডিপ্লয়মেন্ট ডেটার ওপর ভিত্তি করে তৈরি।
সর্বোচ্চ নেটওয়ার্ক নিরাপত্তা এবং ব্যবহারকারী রূপান্তরের জন্য কীভাবে Captive Portals অপ্টিমাইজ করবেন
এই নির্দেশিকাটি এন্টারপ্রাইজ ভেন্যু জুড়ে captive portals অপ্টিমাইজ করার জন্য একটি সম্পূর্ণ প্রযুক্তিগত ব্লুপ্রিন্ট প্রদান করে, যার মধ্যে নেটওয়ার্ক সেগমেন্টেশন আর্কিটেকচার, প্রমাণীকরণ পদ্ধতি নির্বাচন, GDPR-সম্মত সম্মতি ডিজাইন এবং রূপান্তর অপ্টিমাইজেশন অন্তর্ভুক্ত রয়েছে। এটি হোটেল, রিটেইল চেইন, স্টেডিয়াম এবং পাবলিক-সেক্টর সংস্থাগুলির আইটি ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং CTO-দের জন্য লেখা হয়েছে যাদের ফার্স্ট-পার্টি ডেটা সংগ্রহের সাথে নেটওয়ার্ক নিরাপত্তার ভারসাম্য বজায় রাখতে হবে। Purple ২০২৪ সালে ৪৪০ মিলিয়ন লগইন সহ ৮০,০০০+ ভেন্যুতে captive portal অবকাঠামো পরিচালনা করে এবং এখানকার ফ্রেমওয়ার্কগুলি সেই কর্মক্ষম অভিজ্ঞতারই প্রতিফলন ঘটায়।