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

WeChat WiFi অথেন্টিকেশন ইন্টিগ্রেশন: APAC গ্রাহকদের জন্য Captive Portal অনবোর্ডিং

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

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

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

পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
ক্যাপটিভ পোর্টালের জন্য কীভাবে WECHAT OAUTH প্রমাণীকরণ কনফিগার করবেন Purple-এর একটি প্রযুক্তিগত সংক্ষিপ্ত বিবরণ - প্রায় ১০ মিনিট ভূমিকা এবং প্রেক্ষাপট (প্রায় ১ মিনিট) আপনাকে স্বাগত। আপনি যদি কোনো হোটেল, রিটেল চেইন, স্টেডিয়াম বা কনফারেন্স সেন্টারে গেস্ট WiFi-এর দায়িত্বে থাকেন যা চীনা দর্শকদের পরিষেবা দেয়, তবে এই সংক্ষিপ্ত বিবরণটি আপনার জন্য। Tencent-এর নিজস্ব তথ্য অনুযায়ী, ২০২৫ সালের মধ্যে WeChat-এর মাসিক সক্রিয় ব্যবহারকারীর সংখ্যা ১.৪১ বিলিয়ন। এর সিংহভাগ চীনে থাকলেও, আন্তর্জাতিক ক্ষেত্রেও এই প্ল্যাটফর্মটির একটি উল্লেখযোগ্য উপস্থিতি রয়েছে। মালয়েশিয়ায় ১২ মিলিয়ন WeChat ব্যবহারকারী রয়েছে। জাপানে রয়েছে ৫.৫ মিলিয়ন। দক্ষিণ কোরিয়ায় ৫০ লক্ষ। এবং দক্ষিণ-পূর্ব এশিয়া, মধ্যপ্রাচ্য ও ইউরোপ জুড়ে এই সংখ্যা ক্রমাগত বৃদ্ধি পাচ্ছে। যখন কোনো চীনা অতিথি আপনার WiFi-এ সংযুক্ত হন এবং শুধুমাত্র ইমেল, Facebook বা কোনো ভাউচার কোড সহ একটি লগইন পেজ দেখতে পান, তখন তারা তাৎক্ষণিক বাধার সম্মুখীন হন। সেই ডিভাইসে তাদের কোনো স্থানীয় ইমেল অ্যাড্রেস সেট আপ নাও থাকতে পারে। তবে তাদের প্রায় নিশ্চিতভাবেই WeChat থাকে। তাই প্রশ্নটি এটি নয় যে আপনার WeChat লগইন অফার করা উচিত কিনা। প্রশ্নটি হলো আপনি কীভাবে এটি সঠিকভাবে, নিরাপদে এবং এমন একটি উপায়ে কনফিগার করবেন যা ফার্স্ট-পার্টি ডেটা তৈরি করে যা আপনি আসলেই ব্যবহার করতে পারবেন। আজ আমরা সেই বিষয়টিই আলোচনা করতে যাচ্ছি। আমরা OAuth 2.0 ফ্লো, আপনার প্রয়োজনীয় দুটি প্ল্যাটফর্ম রেজিস্ট্রেশন, স্কোপের সিদ্ধান্ত যা নির্ধারণ করে আপনি কী ডেটা সংগ্রহ করবেন, নেটওয়ার্ক-সাইড এনফোর্সমেন্ট মেকানিজম এবং ২০২৬ সালে গুরুত্বপূর্ণ কমপ্লায়েন্স সংক্রান্ত বিষয়গুলো বিস্তারিত জানব। প্রযুক্তিগত গভীর আলোচনা (প্রায় ৫ মিনিট) আসুন আর্কিটেকচার দিয়ে শুরু করা যাক। একটি Captive Portal একটি অপ্রমাণিত ডিভাইস থেকে আসা HTTP ট্রাফিককে বাধা দেয় এবং সেটিকে একটি লগইন পেজে রিডাইরেক্ট করে। সেই লগইন পেজটি একটি পোর্টাল সার্ভারে হোস্ট করা থাকে, তা অন-প্রেমিসেস বা ক্লাউডে হতে পারে। যখন আপনি WeChat OAuth যুক্ত করেন, তখন আপনি সেই ফ্লোতে একটি থার্ড-পার্টি আইডেন্টিটি প্রোভাইডার অন্তর্ভুক্ত করছেন। এখানে সিকোয়েন্সটি দেওয়া হলো। গেস্ট আপনার SSID-এর সাথে সংযুক্ত হন। অ্যাক্সেস পয়েন্ট বা ওয়্যারলেস কন্ট্রোলার সনাক্ত করে যে ডিভাইসটির কোনো প্রমাণিত সেশন নেই এবং সমস্ত HTTP ট্রাফিক আপনার Captive Portal URL-এ রিডাইরেক্ট করে। পোর্টাল পেজটি লোড হয় এবং WeChat সহ লগইন অপশনগুলো প্রদর্শন করে। গেস্ট WeChat লগইনে ট্যাপ করেন। আপনার পোর্টাল সার্ভার ব্রাউজারটিকে WeChat-এর অথরাইজেশন এন্ডপয়েন্টে রিডাইরেক্ট করে, যেখানে আপনার AppID, রিডাইরেক্ট URI, কোডের রেসপন্স টাইপ এবং স্কোপ পাস করা হয়। WeChat সম্পূর্ণভাবে নিজস্ব সার্ভারে এই প্রমাণীকরণ পরিচালনা করে। গেস্ট যদি ইতিমধ্যেই তাদের ব্রাউজারে WeChat-এ লগইন করে থাকেন, তবে তারা একটি কনসেন্ট স্ক্রিন দেখতে পান। তারা যদি WeChat ইন-অ্যাপ ব্রাউজার ব্যবহার করেন, তবে snsapi বেস স্কোপের সাথে অভিজ্ঞতাটি কোনো কনসেন্ট প্রম্পট ছাড়াই নীরব হতে পারে। এরপর WeChat একটি অস্থায়ী অথরাইজেশন কোড সহ আপনার পোর্টালের রিডাইরেক্ট URI-তে ফেরত রিডাইরেক্ট করে। আপনার পোর্টাল সার্ভার WeChat API কল করে একটি অ্যাক্সেস টোকেনের বিনিময়ে সেই কোডটি এক্সচেঞ্জ করে। WeChat একটি অ্যাক্সেস টোকেন, একটি রিফ্রেশ টোকেন, ব্যবহারকারীর OpenID এবং মঞ্জুর করা স্কোপ ফেরত পাঠায়। আপনি যদি snsapi userinfo স্কোপের অনুরোধ করে থাকেন, তবে আপনি ব্যবহারকারীর ডাকনাম, প্রোফাইল ছবি, লিঙ্গ এবং শহর পাওয়ার জন্য দ্বিতীয়বার API কল করতে পারেন। এখন, প্ল্যাটফর্মের দুটি রেজিস্ট্রেশনের বিষয়ে আসা যাক। এখানেই বেশিরভাগ ইমপ্লিমেন্টেশন ভুল হয়ে থাকে। WeChat-এর দুটি পৃথক ডেভেলপার প্ল্যাটফর্ম রয়েছে। WeChat Open Platform ওয়েবসাইট অ্যাপ্লিকেশন এবং মোবাইল অ্যাপস পরিচালনা করে। WeChat Official Accounts Platform পাবলিক অ্যাকাউন্ট পরিচালনা করে, যা আসলে বেশিরভাগ ভেন্যুর প্রয়োজন হয়। WeChat ইন-অ্যাপ ব্রাউজারের অভ্যন্তরে অতিথিদের পরিষেবা প্রদানকারী একটি Captive Portal-এর জন্য, আপনার Official Accounts Platform-এ একটি Service Account প্রয়োজন। একটি Subscription Account কাজ করবে না। এটিতে OAuth ওয়েব পেজ অথরাইজেশন পারমিশন নেই। একটি Service Account-এ এটি আছে এবং এটি snsapi base এবং snsapi userinfo উভয় স্কোপই সমর্থন করে। WeChat-এর বাইরে একটি স্ট্যান্ডার্ড মোবাইল ব্রাউজার থেকে অ্যাক্সেস করা Captive Portal-এর জন্য, যেমন Android-এ Chrome বা iOS-এ Safari, আপনার Open Platform-এ নিবন্ধিত একটি Website Application প্রয়োজন। এটি snsapi login স্কোপ ব্যবহার করে এবং একটি QR কোড প্রদর্শন করে যা ব্যবহারকারী তাদের WeChat অ্যাপ দিয়ে স্ক্যান করেন। বাস্তবে, বেশিরভাগ ভেন্যু ডেপ্লয়মেন্টে উভয়ই ব্যবহৃত হয়। একটি হোটেলের অতিথি হয়তো Chrome-এ পোর্টালটি ওপেন করতে পারেন, একটি QR কোড দেখতে পারেন, WeChat দিয়ে এটি স্ক্যান করতে পারেন এবং অথেন্টিকেট করতে পারেন। অথবা তারা WeChat-এর ভেতরের কোনো লিঙ্ক অনুসরণ করতে পারেন, ইন-অ্যাপ ব্রাউজারে প্রবেশ করতে পারেন এবং snsapi base দিয়ে নীরবেই অথেন্টিকেট করতে পারেন। আসুন স্কোপ নির্বাচন সম্পর্কে কথা বলি, কারণ এটি একটি প্রকৃত সিদ্ধান্ত নেওয়ার বিষয়। snsapi base স্কোপটি কেবল OpenID রিটার্ন করে। এটি আপনার Official Account-এর মধ্যে সেই ব্যবহারকারীর জন্য একটি অনন্য আইডেন্টিফায়ার। এর জন্য কোনো ব্যবহারকারীর সম্মতির প্রম্পটের প্রয়োজন হয় না। অথেন্টিকেশনটি ব্যবহারকারীর কাছে অদৃশ্য থাকে। এটি ফিরে আসা অতিথিদের জন্য আদর্শ যাদের প্রোফাইল আপনি ইতিমধ্যেই তৈরি করেছেন, অথবা এমন ভেন্যুর জন্য যেখানে আপনি শূন্য নতুন ডেটার বিনিময়ে শূন্য ঘর্ষণ চান। snsapi userinfo স্কোপটি OpenID-এর পাশাপাশি ব্যবহারকারীর WeChat ডাকনাম, প্রোফাইল ছবি, লিঙ্গ, ভাষা সেটিং এবং শহর রিটার্ন করে। এর জন্য একটি স্পষ্ট সম্মতি স্ক্রীনের প্রয়োজন হয়। ব্যবহারকারী একটি প্রম্পট দেখতে পান যেখানে জিজ্ঞাসা করা হয় যে তারা আপনার Official Account-কে তাদের তথ্য অ্যাক্সেস করার অনুমতি দিচ্ছেন কিনা। বেশিরভাগ ব্যবহারকারী এটি গ্রহণ করেন, তবে এতে কিছুটা ঘর্ষণ রয়েছে। সঠিক পছন্দটি আপনার ব্যবহারের ক্ষেত্রের ওপর নির্ভর করে। প্রথমবার অতিথি নিবন্ধনের জন্য যেখানে আপনি একটি প্রোফাইল তৈরি করতে চান, সেখানে snsapi userinfo ব্যবহার করুন এবং আপনার পোর্টাল পেজে একটি GDPR-সম্মত সম্মতি স্তরের সাথে এটি যুক্ত করুন। ফিরে আসা অতিথির জন্য যিনি ইতিমধ্যেই সম্মতি দিয়েছেন এবং যার প্রোফাইল আপনার কাছে ইতিমধ্যেই রয়েছে, নীরব রি-অথেন্টিকেশনের জন্য snsapi base ব্যবহার করুন। এখন, নেটওয়ার্ক প্রয়োগের দিকটি দেখা যাক। একটি OAuth টোকেন পাওয়া পরিচয় প্রমাণ করে, কিন্তু এটি স্বয়ংক্রিয়ভাবে নেটওয়ার্ক খোলে না। সফল অথরাইজেশনকে নেটওয়ার্ক অ্যাক্সেসে রূপান্তর করার জন্য আপনার একটি মেকানিজম প্রয়োজন। দুটি স্ট্যান্ডার্ড পদ্ধতি হলো RADIUS Change of Authorisation, যা RFC 3576-এ সংজ্ঞায়িত এবং MAC অ্যাড্রেস বাইপাস। RADIUS CoA-এর মাধ্যমে, সফল OAuth-এর পর আপনার পোর্টাল সার্ভার নেটওয়ার্ক কন্ট্রোলারে একটি CoA অনুরোধ পাঠায় এবং কন্ট্রোলার ডিভাইসটিকে আনঅথেন্টিকেটেড VLAN থেকে গেস্ট VLAN-এ স্থানান্তরিত করে। এটি Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks এবং Fortinet-এর সাথে কাজ করে। MAC bypass-এর ক্ষেত্রে, পোর্টাল সার্ভার ডিভাইসের MAC address-টিকে একটি অনুমোদিত ক্লায়েন্ট হিসেবে রেজিস্টার করে এবং কন্ট্রোলার এটিকে অনুমতি দেয়। MAC bypass প্রয়োগ করা সহজ কিন্তু কম সুরক্ষিত, কারণ MAC address স্পুফ করা যেতে পারে এবং আধুনিক স্মার্টফোনগুলি ক্রমবর্ধমানভাবে MAC address randomisation ব্যবহার করে, যা পুনরায় কানেক্ট করার সময় মেকানিজমটিকে ভেঙে দেয়। Purple-এর গেস্ট WiFi প্ল্যাটফর্ম উভয় মেকানিজমই পরিচালনা করে। WeChat OAuth সম্পন্ন হওয়ার পর, Purple-এর ক্লাউড ওভারলে অন্তর্নিহিত হার্ডওয়্যারে উপযুক্ত সংকেত পাঠায়। ভেন্যু অপারেটরকে সেই অনুবাদটি ম্যানুয়ালি পরিচালনা করতে হয় না। বাস্তবায়ন সংক্রান্ত সুপারিশ এবং সমস্যাসমূহ (প্রায় ২ মিনিট) WeChat OAuth captive portal বাস্তবায়ন ব্যর্থ হওয়ার পাঁচটি কারণ আমি আপনাকে বলছি। প্রথম: redirect URI অমিল। WeChat আপনার রেজিস্টার করা অনুমোদিত ডোমেনের বিপরীতে redirect URI যাচাই করে। আপনার পোর্টাল সার্ভার যদি ভিন্ন সাবডোমেন, ভিন্ন পাথ বা HTTPS-এর পরিবর্তে HTTP ব্যবহার করে, তবে OAuth ফ্লো 40029 ত্রুটি সহ ব্যর্থ হয়, যার অর্থ অবৈধ কোড। আপনার ব্যবহৃত প্রতিটি ডোমেন ভেরিয়েন্ট রেজিস্টার করুন, যার মধ্যে স্টেজিং এনভায়রনমেন্টও অন্তর্ভুক্ত। দ্বিতীয়: ক্লায়েন্ট সাইডে AppSecret। আপনার AppSecret কখনই ক্লায়েন্ট-সাইড JavaScript বা কোনো মোবাইল অ্যাপ বাইনারিতে থাকা উচিত নয়। এটি আপনার সার্ভারে থাকা উচিত। এটি প্রকাশ হয়ে গেলে, যে কেউ আপনার অ্যাপ্লিকেশনের ছদ্মবেশ ধারণ করতে পারে এবং আপনার পক্ষে WeChat-এর API কল করতে পারে। তৃতীয়: অনুপস্থিত CSRF সুরক্ষা। OAuth রিকোয়েস্টে state প্যারামিটারটি বিশেষভাবে cross-site request forgery প্রতিরোধ করার জন্য রয়েছে। একটি ক্রিপ্টোগ্রাফিকভাবে র্যান্ডম state ভ্যালু তৈরি করুন, এটি ব্যবহারকারীর সেশনে সংরক্ষণ করুন এবং WeChat রিডাইরেক্ট ব্যাক করার সময় এটি যাচাই করুন। এটি এড়িয়ে গেলে আপনি একটি বাস্তব দুর্বলতার সম্মুখীন হবেন। চতুর্থ: ইন-অ্যাপ ব্রাউজার সনাক্তকরণের অভাব। WeChat-এর ইন-অ্যাপ ব্রাউজার একটি নির্দিষ্ট ইউজার এজেন্ট স্ট্রিং সেট করে যাতে MicroMessenger থাকে। আপনার পোর্টাল যদি এটি সনাক্ত করতে এবং সঠিক OAuth ফ্লো প্রদান করতে না পারে, তবে ব্যবহারকারীরা একটি ত্রুটিপূর্ণ অভিজ্ঞতা বা একটি এরর পাবেন। পঞ্চম: GDPR এবং PIPL-এর সাথে সামঞ্জস্যতা। আপনি যদি ইউরোপীয় ভিজিটরদের পরিষেবা প্রদান করেন, তবে WeChat OAuth-এর মাধ্যমে আপনার সংগ্রহ করা ডেটার ক্ষেত্রে GDPR প্রযোজ্য হবে। আপনি যদি চীনা ভিজিটরদের পরিষেবা প্রদান করেন, তবে চীনের Personal Information Protection Law, যা PIPL নামে পরিচিত, আপনি কীভাবে তাদের ডেটা প্রসেস করছেন তার উপর প্রযোজ্য হবে। উভয়ের জন্যই প্রসেসিংয়ের একটি বৈধ আইনি ভিত্তি, স্পষ্ট উদ্দেশ্যের সীমাবদ্ধতা এবং ডেটা মিনিমাইজেশন প্রয়োজন। snsapi base স্কোপটি snsapi userinfo-এর চেয়ে ডেটা মিনিমাইজেশন নীতিমালার অধীনে ন্যায়সঙ্গত করা সহজ। আপনি যা-ই সংগ্রহ করুন না কেন, আপনার আইনি ভিত্তি এবং আপনার ডেটা ধরে রাখার সময়কাল নথিবদ্ধ করুন। দ্রুত প্রশ্নোত্তর (প্রায় ১ মিনিট) প্রশ্ন: আমি কি এমন একটি পোর্টালে WeChat লগইন ব্যবহার করতে পারি যা ইমেল এবং SMS লগইনও অফার করে? হ্যাঁ। Purple সহ বেশিরভাগ এন্টারপ্রাইজ পোর্টাল প্ল্যাটফর্ম একই পোর্টাল পেজে একাধিক প্রমাণীকরণ পদ্ধতি সমর্থন করে। অন্যান্য বিকল্পগুলির পাশাপাশি WeChat একটি বিকল্প হিসেবে উপস্থিত থাকে। প্রশ্ন: WeChat OAuth কি iOS-এ কাজ করে? হ্যাঁ, তবে একটি সূক্ষ্ম বিষয় রয়েছে। Apple-এর App Tracking Transparency ফ্রেমওয়ার্ক সার্ভার-সাইড OAuth ফ্লোকে প্রভাবিত করে না। iOS-এ Safari-তে WeChat লগইন QR code ফ্লো বা রিডাইরেক্ট ফ্লো-এর মাধ্যমে কাজ করে। WeChat অ্যাপটি নিজেই প্রমাণীকরণ পরিচালনা করে।প্রশ্ন: WeChat-এর API উপলব্ধ না হলে কী হবে? আপনার পোর্টালে একটি ফলব্যাক ব্যবস্থা থাকা উচিত। WeChat API কল টাইমআউট হলে বা কোনো ত্রুটি দেখালে, ব্যবহারকারীকে একটি বিকল্প লগইন পদ্ধতিতে রিডাইরেক্ট করুন। তাদের একটি খালি স্ক্রিন দেখাবেন না। প্রশ্ন: আমি কি একটি স্থায়ী গ্রাহক শনাক্তকারী হিসেবে OpenID ব্যবহার করতে পারি? আপনার Official Account-এর মধ্যে, হ্যাঁ। একটি নির্দিষ্ট ব্যবহারকারী এবং একটি নির্দিষ্ট Official Account-এর জন্য OpenID অপরিবর্তিত থাকে। আপনার যদি একাধিক Official Account থাকে, তবে একই ব্যবহারকারীর জন্য আলাদা আলাদা OpenIDs থাকবে। অ্যাকাউন্টগুলির মধ্যে পরিচয় শনাক্তকরণের জন্য WeChat একটি UnionID প্রদান করে, যার জন্য Open Platform-এ আপনার অ্যাকাউন্টগুলি লিঙ্ক করা থাকা আবশ্যক। সারসংক্ষেপ এবং পরবর্তী পদক্ষেপ (আনুমানিক ১ মিনিট) সংক্ষেপে বলতে গেলে, Captive Portal-এর জন্য WeChat OAuth অথেন্টিকেশন হলো একটি দুটি প্ল্যাটফর্মের রেজিস্ট্রেশন প্রক্রিয়া, স্কোপ নির্ধারণ, নেটওয়ার্ক এনফোর্সমেন্ট ইন্টিগ্রেশন এবং একটি কমপ্লায়েন্স পর্যালোচনা। এই চারটি বিষয় সঠিকভাবে সম্পন্ন করলে আপনি এমন একটি লগইন পদ্ধতি পাবেন যা কোনো পাসওয়ার্ডের ঝামেলা ছাড়াই এক বিলিয়নেরও বেশি সম্ভাব্য ব্যবহারকারীকে সেবা দিতে পারবে। পরবর্তী বাস্তব পদক্ষেপগুলি হলো - প্রথমত, আপনার ভিজিটররা WeChat-এর ইন-অ্যাপ ব্রাউজারে নাকি একটি সাধারণ মোবাইল ব্রাউজারে পোর্টালটি দেখছেন তা নির্ধারণ করুন। এটিই আপনার প্রয়োজনীয় প্ল্যাটফর্ম রেজিস্ট্রেশনটি নির্ধারণ করবে। দ্বিতীয়ত, স্কোপের বিষয়ে সিদ্ধান্ত নিন। ফিরে আসা অতিথিদের জন্য snsapi base এবং সম্মতির মাধ্যমে প্রথমবারের রেজিস্ট্রেশনের জন্য snsapi userinfo ব্যবহার করুন। তৃতীয়ত, আপনার নেটওয়ার্ক হার্ডওয়্যার RADIUS CoA সমর্থন করে কিনা তা নিশ্চিত করুন অথবা বিকল্প হিসেবে MAC bypass কনফিগার করুন। চতুর্থত, GDPR এবং PIPL-এর প্রয়োজনীয়তার বিপরীতে আপনার গোপনীয়তা নীতি এবং সম্মতি প্রক্রিয়াটি পর্যালোচনা করুন। পঞ্চমত, লাইভ করার আগে রিডাইরেক্ট URI, স্টেট প্যারামিটার ভ্যালিডেশন এবং ইন-অ্যাপ ব্রাউজার ডিটেকশন পরীক্ষা করুন। আপনি যদি দেখতে চান যে ২০২৪ সালে ৮০,০০০ ভেন্যু এবং ৪৪০ মিলিয়ন লগইনের মধ্যে একটি সামগ্রিক গেস্ট WiFi এবং অ্যানালিটিক্স প্ল্যাটফর্মের অংশ হিসেবে Purple কীভাবে WeChat OAuth পরিচালনা করে, তবে purple.ai ভিজিট করুন অথবা আপনার অ্যাকাউন্ট টিমের সাথে কথা বলুন। শোনার জন্য ধন্যবাদ।

📚 আমাদের মূল সিরিজের অংশ: Captive Portal Guide

header_image.png

এক্সিকিউটিভ সামারি

APAC অঞ্চল জুড়ে পরিচালিত এন্টারপ্রাইজ ভেন্যুগুলির জন্য, বা বিশ্বব্যাপী চীনা পর্যটকদের পরিষেবা দেওয়ার জন্য, WeChat WiFi অথেন্টিকেশন আর ঐচ্ছিক নয়। ২০২৫ সালের হিসাবে ১.৪১ বিলিয়ন মাসিক সক্রিয় ব্যবহারকারীর (উৎস: Tencent) সাথে, WeChat হলো চীনা গ্রাহকদের প্রাথমিক ডিজিটাল পরিচয়। একজন অতিথি যিনি আপনার SSID-এর সাথে যুক্ত হন এবং শুধুমাত্র ইমেল বা Facebook লগইন অপশন দেখতে পান, তিনি তাৎক্ষণিক সমস্যার সম্মুখীন হন। তাদের অবশ্যই WeChat আছে। তাদের সেই ডিভাইসে কোনো স্থানীয় ইমেল ঠিকানা কনফিগার করা না থাকার সম্ভাবনাই সবচেয়ে বেশি।

এই নির্দেশিকাটি কীভাবে একটি captive portal-এ WeChat OAuth 2.0 সংহত করা যায় তা বিস্তারিতভাবে আলোচনা করে। আমরা Tencent-এর প্রয়োজনীয় দুটি ভিন্ন প্ল্যাটফর্ম রেজিস্ট্রেশন, ফার্স্ট-পার্টি ডেটা সংগ্রহের স্কোপ সিদ্ধান্ত এবং একটি সফল OAuth বিনিময়কে প্রকৃত নেটওয়ার্ক অ্যাক্সেসে রূপান্তরকারী RADIUS Change of Authorisation (CoA) প্রক্রিয়া কভার করেছি। আমরা 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 নির্বাচন করেন। পোর্টাল সার্ভার WeChat-এর অথরাইজেশন এন্ডপয়েন্ট open.weixin.qq.com-এ একটি রিডাইরেক্ট তৈরি করে, যেখানে চারটি প্যারামিটার পাস করা হয়: 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 কল ব্যবহারকারীর ডাকনাম, প্রোফাইল ইমেজ, লিঙ্গ এবং শহর পুনরুদ্ধার করে।

architecture_overview.png

প্ল্যাটফর্ম নিবন্ধন: যে সিদ্ধান্তটি বেশিরভাগ স্থাপনাকে বাধাগ্রস্ত করে

Tencent দুটি পৃথক ডেভলপার প্ল্যাটফর্ম পরিচালনা করে, এবং ভুলটি নির্বাচন করা ব্যর্থ বাস্তবায়নের সবচেয়ে সাধারণ কারণ।

অ্যাক্সেস প্রসঙ্গ প্রয়োজনীয় নিবন্ধন প্ল্যাটফর্ম URL সমর্থিত স্কোপ
WeChat ইন-অ্যাপ ব্রাউজার সার্ভিস অ্যাকাউন্ট (অফিসিয়াল অ্যাকাউন্টস প্ল্যাটফর্ম) mp.weixin.qq.com snsapi_base, snsapi_userinfo
স্ট্যান্ডার্ড মোবাইল ব্রাউজার (Chrome, Safari) ওয়েবসাইট অ্যাপ্লিকেশন (ওপেন প্ল্যাটফর্ম) open.weixin.qq.com snsapi_login (QR কোড ফ্লো)

অফিসিয়াল অ্যাকাউন্টস প্ল্যাটফর্মের একটি সাবস্ক্রিপশন অ্যাকাউন্ট কাজ করবে না। এটিতে OAuth ওয়েব পেজ অথরাইজেশন অনুমতির অভাব রয়েছে। শুধুমাত্র একটি সার্ভিস অ্যাকাউন্ট এই অনুমতিগুলি বহন করে।

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

স্কোপ নির্বাচন এবং ডেটা সংগ্রহ

OAuth স্কোপ একটি প্রকৃত আর্কিটেকচারাল সিদ্ধান্ত, কোনো কনফিগারেশন বিবরণ নয়। ব্যবহারকারী কী ধরনের বাধা অনুভব করবেন এবং আপনার WiFi Analytics প্ল্যাটফর্ম কী ডেটা পাবে তা এটি নির্ধারণ করে।

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

বাস্তবসম্মত নিয়ম: দ্রুততার জন্য snsapi_base ব্যবহার করুন, আর ডেটার জন্য snsapi_userinfo ব্যবহার করুন। ব্যবহারকারীর ওপেনআইডি (OpenID) আপনার ডাটাবেসে ইতিমধ্যে উপস্থিত আছে কিনা তা পরীক্ষা করে আপনি উভয়ই বাস্তবায়ন করতে পারেন। যদি থাকে, তবে snsapi_base এর জন্য অনুরোধ করুন। যদি না থাকে, তবে snsapi_userinfo এর জন্য অনুরোধ করুন।

নেটওয়ার্ক প্রয়োগ: RADIUS CoA এবং MAC বাইপাস

একটি OAuth টোকেন কেবল পরিচয় প্রমাণ করে। এটি নেটওয়ার্ক অ্যাক্সেস উন্মুক্ত করে না। সফল প্রমাণীকরণকে নেটওয়ার্ক নীতি পরিবর্তনে রূপান্তর করতে একটি পৃথক মেকানিজম ব্যবহার করতে হবে।

RADIUS Change of Authorisation (CoA), যা RFC 3576 এ সংজ্ঞায়িত করা হয়েছে, এটি একটি স্ট্যান্ডার্ড পদ্ধতি। পোর্টাল সার্ভার একটি বৈধ OAuth টোকেন পাওয়ার পর, এটি ওয়্যারলেস কন্ট্রোলারের কাছে একটি CoA অনুরোধ পাঠায়। কন্ট্রোলার সেশনটি আপডেট করে, ডিভাইসটিকে ওয়াল্ড গার্ডেন VLAN (একটি সীমাবদ্ধ নেটওয়ার্ক সেগমেন্ট যা কেবল পোর্টাল ট্রাফিকের অনুমতি দেয়) থেকে সম্পূর্ণ গেস্ট VLAN-এ স্থানান্তরিত করে। এটি Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet এর সাথে কাজ করে।

MAC address bypass সফল OAuth এর পরে ডিভাইসটির MAC অ্যাড্রেসকে একটি অনুমোদিত ক্লায়েন্ট হিসেবে নিবন্ধন করে। এরপর কন্ট্রোলার আর কোনো যাচাইকরণ ছাড়াই সেই অ্যাড্রেস থেকে ট্রাফিকের অনুমতি দেয়। এটি বাস্তবায়ন করা সহজ কিন্তু এতে দুটি ঝুঁকি রয়েছে: MAC অ্যাড্রেস স্পুফ (spoof) করা যেতে পারে এবং iOS 14 ও Android 10 থেকে শুরু করে ডিভাইসগুলো ডিফল্টরূপে MAC অ্যাড্রেস র্যান্ডমাইজেশন ব্যবহার করে, যা পুনরায় সংযোগ করার সময় এই মেকানিজমটিকে ব্যাহত করে।

নিরাপত্তা যেখানে গুরুত্বপূর্ণ, এমন যেকোনো সেটআপের জন্য RADIUS CoA সঠিক পছন্দ। গেস্ট নেটওয়ার্ক সুরক্ষিত করার বিষয়ে আরও জানতে, What Is Secure WiFi: Essential Guide for Business 2026 এবং Enterprise WiFi Security: A Complete Guide for 2026 দেখুন।

বাস্তবায়ন নির্দেশিকা

প্রি-ডিপ্লয়মেন্ট চেকলিস্ট

কনফিগারেশনের একটি লাইন লেখার আগেও, এই পাঁচটি ধাপ সম্পন্ন করুন।

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

দ্বিতীয়ত, সঠিক প্ল্যাটফর্মে নিবন্ধন করুন। ইন-অ্যাপ ব্রাউজার অ্যাক্সেসের জন্য, WeChat Official Accounts Platform-এ একটি সার্ভিস অ্যাকাউন্ট তৈরি করুন। স্ট্যান্ডার্ড ব্রাউজার অ্যাক্সেসের জন্য, WeChat Open Platform-এ একটি ওয়েবসাইট অ্যাপ্লিকেশন নিবন্ধন করুন। প্রতিটির জন্য আপনার AppID এবং AppSecret লিখে রাখুন।

তৃতীয়ত, আপনার রিডাইরেক্ট URI সমূহ কনফিগার করুন। স্টেজিং এনভায়রনমেন্ট সহ আপনার পোর্টাল ব্যবহার করে এমন প্রতিটি ডোমেন এবং সাবডোমেন নিবন্ধন করুন। WeChat হুবহু মিল যাচাইকরণ প্রয়োগ করে। অমিল হলে 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 এন্ডপয়েন্টগুলোতে ট্র্যাফিক অনুমতি দেওয়ার জন্য আপনি ওয়াল্ড গার্ডেন হোয়াইটলিস্টও কনফিগার করবেন। সমতুল্য কন্ট্রোলার কনফিগারেশন প্যাটার্নের জন্য Step-by-Step Guide: Configuring Ruijie Wireless Controllers for Guest WiFi Captive Portals গাইডটিও দেখুন।

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

WeChat-এর ইন-অ্যাপ ব্রাউজার একটি ইউজার এজেন্ট স্ট্রিং সেট করে যার মধ্যে MicroMessenger থাকে। আপনার পোর্টালকে অবশ্যই এই স্ট্রিংটি সনাক্ত করতে হবে এবং উপযুক্ত OAuth ফ্লো পরিবেশন করতে হবে। যদি MicroMessenger উপস্থিত থাকে, তবে Official Accounts ফ্লো ব্যবহার করুন। যদি অনুপস্থিত থাকে, তবে Open Platform QR কোড ফ্লো ব্যবহার করুন। এটি সঠিকভাবে সনাক্ত করতে ব্যর্থ হলে ত্রুটিপূর্ণ অভিজ্ঞতা বা প্রমাণীকরণ ত্রুটি তৈরি হয়।

সর্বোত্তম অনুশীলনসমূহ

ডেটা মিনিমাইজেশন এবং দ্বৈত-ফ্রেমওয়ার্ক সম্মতি

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

নভেম্বর ২০২১ থেকে কার্যকর হওয়া PIPL-এর জন্য সংবেদনশীল ব্যক্তিগত তথ্যের জন্য স্পষ্ট সম্মতি প্রয়োজন এবং চীনের বাইরের ডেটা প্রসেসরদের সমতুল্য সুরক্ষা মানদণ্ড প্রয়োগ করার নির্দেশ দেয়। যদি আপনার পোর্টাল সার্ভারটি চীনের মূল ভূখণ্ডের বাইরে অবস্থিত হয়, তবে আপনি যে WeChat OpenID এবং প্রোফাইল ডেটা গ্রহণ করছেন তার ক্ষেত্রে আন্তঃসীমান্ত ডেটা স্থানান্তর নিয়ম প্রযোজ্য কিনা তা আপনাকে মূল্যায়ন করতে হবে।

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

প্রতিটি Official Account-এ প্রতি ব্যবহারকারীর জন্য OpenID অনন্য। আপনি যদি বিভিন্ন প্রপার্টি জুড়ে একাধিক Official Account পরিচালনা করেন, তবে একই অতিথির প্রতিটিতে আলাদা আলাদা OpenID থাকবে। WeChat একটি UnionID প্রদান করে যা একই Open Platform নিবন্ধনের সাথে লিঙ্কযুক্ত সমস্ত অ্যাকাউন্ট জুড়ে সামঞ্জস্যপূর্ণ থাকে। হোটেল চেইন, খুচরা গ্রুপ, বা বিমানবন্দর অপারেটরদের জন্য যারা একাধিক ভেন্যু পরিচালনা করছেন, তারা শুরু থেকেই UnionID-ভিত্তিক পরিচয় রেজোলিউশন বাস্তবায়ন করুন।

সিকিউরিটি হার্ডেনিং

AppSecret-টি একটি এনভায়রনমেন্ট ভেরিয়েবল বা সিক্রেটস ম্যানেজারে সংরক্ষণ করুন, কখনোই সোর্স কোডে নয়। যদি আপনার সন্দেহ হয় যে এটি প্রকাশ হয়ে পড়েছে, তাহলে অবিলম্বে এটি পরিবর্তন করুন। অপব্যবহার রোধ করতে আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্টে রেট লিমিটিং প্রয়োগ করুন। সমস্ত OAuth ত্রুটিগুলি লগ করুন, বিশেষ করে 40029 (অবৈধ কোড) এবং 40163 (কোড মেয়াদোত্তীর্ণ), কারণ এগুলি ভুল কনফিগারেশন বা সক্রিয় অনুসন্ধান নির্দেশ করে।

গেস্ট নেটওয়ার্ক সিকিউরিটি আর্কিটেকচারের আরও বিস্তারিত বিবরণের জন্য, দেখুন কেন আপনার গেস্ট নেটওয়ার্কে কনজিউমার WiFi গিয়ার ব্যবহার করা উচিত নয়

কেস স্টাডিজ

লাক্সারি হোটেল চেইন, সিঙ্গাপুর

সিঙ্গাপুরের একটি ৩৫০-রুমের লাক্সারি হোটেল যা প্রধানত চীনা বিজনেস ট্রাভেলারদের সেবা প্রদান করে, তারা তাদের বিদ্যমান ইমেল লগইন বিকল্পের সাথে WeChat WiFi প্রমাণীকরণ ব্যবস্থা প্রয়োগ করেছে। এটি প্রয়োগ করার আগে, ফ্রন্ট-ডেস্ক কর্মীরা WiFi লগইন জটিলতা নিয়ে প্রতিদিন গড়ে ১৫টি গেস্টদের অভিযোগের কথা জানিয়েছিলেন। চীনা অতিথিরা এমন ইমেল ঠিকানা ব্যবহার করার চেষ্টা করছিলেন যা তারা তাদের ভ্রমণ ডিভাইসে কনফিগার করেননি।

হোটেলটি WeChat অফিশিয়াল অ্যাকাউন্টস প্ল্যাটফর্মে একটি সার্ভিস অ্যাকাউন্ট এবং ওপেন প্ল্যাটফর্মে একটি ওয়েবসাইট অ্যাপ্লিকেশন রেজিস্টার করেছে। তারা প্রথমবারের সংযোগের জন্য snsapi_userinfo এবং MAC অ্যাড্রেস দ্বারা চিহ্নিত ফিরে আসা অতিথিদের জন্য snsapi_base কনফিগার করেছে। সেশন প্রমোশন পরিচালনা করার জন্য HPE Aruba কন্ট্রোলারটি RADIUS CoA-এর জন্য কনফিগার করা হয়েছিল।

৩০ দিনের মধ্যে, গেস্ট WiFi লগইন সংক্রান্ত অভিযোগ প্রতিদিন দুটির নিচে নেমে আসে। প্রথম মাসেই হোটেলের WiFi Analytics ডাটাবেসে ৪,২০০টি যাচাইকৃত ফার্স্ট-পার্টি প্রোফাইল যুক্ত হয়, যেখানে শহর-স্তরের ডেমোগ্রাফিক ডেটা থাকার কারণে পরবর্তী সময়ে টার্গেটেড যোগাযোগ করা সহজ হয়েছে।

আন্তর্জাতিক রিটেল মল, কুয়ালালামপুর

কুয়ালালামপুরের একটি প্রিমিয়াম রিটেল মল যার শুধুমাত্র মালয়েশিয়াতেই ১২ মিলিয়ন WeChat ব্যবহারকারী রয়েছে, তাদের ক্রেতাদের ডিজিটাল প্রত্যাশার সাথে সামঞ্জস্যপূর্ণ একটি WiFi অনবোর্ডিং অভিজ্ঞতার প্রয়োজন ছিল। মলটি ১,৮০,০০০ বর্গমিটার রিটেল ফ্লোর জুড়ে Cisco Meraki অ্যাক্সেস পয়েন্ট পরিচালনা করছিল।

এই সেটআপে ক্লাউড ওভারলে হিসেবে Purple-এর Guest WiFi প্ল্যাটফর্ম ব্যবহার করা হয়েছিল, যেখানে প্রাথমিক প্রমাণীকরণ পদ্ধতি হিসেবে WeChat OAuth এবং ব্যাকআপ হিসেবে SMS OTP ব্যবহার করা হয়েছিল। Purple-এর হার্ডওয়্যার-স্বাধীন আর্কিটেকচার কোনো কাস্টম ডেভেলপমেন্ট ছাড়াই Cisco Meraki-এর সাথে RADIUS CoA ইন্টিগ্রেশন সম্পন্ন করেছে।

মলটি বাস্তবায়নের পর প্রথম কোয়ার্টারে WiFi সেশন শুরুর সংখ্যায় ৩৪% বৃদ্ধি রেকর্ড করেছে, যার কারণ ছিল WeChat ব্যবহারকারীদের জন্য অনবোর্ডিংয়ের জটিলতা হ্রাস পাওয়া। snsapi_userinfo কনসেন্ট ফ্লোর মাধ্যমে সংগৃহীত ফার্স্ট-পার্টি ডেটা মলের মার্কেটিং টিমকে টার্গেটেড ক্যাম্পেইন পরিচালনার জন্য ক্রেতাদের তাদের নিজ শহর অনুযায়ী ভাগ করার সুবিধা দিয়েছে।

retail_venue_wechat_wifi.png

ট্রাবলশুটিং এবং ঝুঁকি হ্রাসকরণ

ত্রুটি কারণ সমাধান
40029 invalid code রিডাইরেক্ট URI অমিল বা কোডের পুনরায় ব্যবহার রেজিস্টার করা URIs হুবহু মিলেছে কিনা তা যাচাই করুন; কোডগুলি এককালীন ব্যবহারের জন্য
অথেন্টিকেশনের পর স্ক্রিন ফাঁকা দেখাচ্ছে RADIUS CoA কনফিগার করা হয়নি বা ব্যর্থ হচ্ছে কন্ট্রোলার CoA সেটিংস এবং UDP পোর্ট 3799-এ ফায়ারওয়াল রুলগুলি পরীক্ষা করুন
MAC র্যান্ডমাইজেশনের কারণে পূর্ববর্তী গেস্ট ফ্লো বাধাগ্রস্ত হচ্ছে iOS/Android MAC র্যান্ডমাইজেশন OpenID-ভিত্তিক সেশন ট্র্যাকিংয়ে মাইগ্রেট করুন; শুধুমাত্র MAC-ভিত্তিক আইডেন্টিফিকেশন পরিহার করুন
snsapi_userinfo খালি ফিল্ড রিটার্ন করছে ব্যবহারকারী WeChat প্রাইভেসি রেস্ট্রিকশন সেট করেছেন নাল ফিল্ডগুলো সহজভাবে পরিচালনা করুন; অ্যাক্সেসের জন্য প্রোফাইল ডেটা বাধ্যতামূলক করবেন না

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

Captive Portal ডেপ্লয়মেন্টে আনঅথেন্টিকেটেড ডিভাইস (walled garden VLAN) এবং অথেন্টিকেটেড গেস্টদের (guest VLAN) আলাদা করতে ব্যবহৃত হয়। RADIUS CoA সফল অথেন্টিকেশনের পর একটি ডিভাইসকে এক VLAN থেকে অন্য VLAN-এ স্থানান্তর করে।

UnionID

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

হোটেল চেইন, রিটেল গ্রুপ এবং মাল্টি-ভেন্যু অপারেটরদের জন্য অত্যন্ত প্রয়োজনীয় যাদের একাধিক প্রপার্টিজুড়ে একই গেস্টকে চিনে নেওয়ার প্রয়োজন হয়, যেখানে প্রতিটির নিজস্ব Official Account রয়েছে।

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

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

ধাপ ১: WeChat ইন-অ্যাপ ব্রাউজারের অভ্যন্তরে পোর্টালে অ্যাক্সেস করা অতিথিদের পরিচালনা করতে WeChat Official Accounts Platform-এ (mp.weixin.qq.com) একটি সার্ভিস অ্যাকাউন্ট রেজিস্টার করুন। স্ট্যান্ডার্ড মোবাইল ব্রাউজার ব্যবহারকারী অতিথিদের জন্য WeChat Open Platform-এ (open.weixin.qq.com) একটি ওয়েবসাইট অ্যাপ্লিকেশন রেজিস্টার করুন।

ধাপ ২: 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 র্যান্ডমাইজেশনের জন্য শুধুমাত্র MAC অ্যাড্রেস নয়, বরং OpenID-কে প্রাথমিক আইডেন্টিফায়ার হিসেবে ব্যবহার করা প্রয়োজন।

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

একটি রিটেইল চেইনের IT টিম তিনটি মল লোকেশন জুড়ে WeChat WiFi লগইনে উচ্চ ব্যর্থতার হার রিপোর্ট করেছে। ব্যবহারকারীরা WeChat-এ অথেন্টিকেট হন কিন্তু একটি ত্রুটি সহ পোর্টাল পৃষ্ঠায় ফিরে আসেন। পোর্টাল লগগুলি ৪০২৯ ত্রুটি প্রদর্শন করে। এর সম্ভাব্য কারণ কী এবং আপনি কীভাবে এটি সমাধান করবেন?

ত্রুটি ৪০২৯-এর অর্থ হলো টোকেন বিনিময়ের সময় WeChat অথরাইজেশন কোডটি প্রত্যাখ্যান করেছে। এর দুটি সবচেয়ে সাধারণ কারণ হলো রিডাইরেক্ট URI অমিল এবং কোডের পুনরায় ব্যবহার।

ধাপ ১: Official Accounts Platform এবং Open Platform উভয়ের জন্যই WeChat ডেভেলপার কনসোলে লগ ইন করুন। OAuth সেটিংসে যান এবং সমস্ত রেজিস্টার্ড রিডাইরেক্ট URI তালিকাভুক্ত করুন।

ধাপ ২: তিনটি মল লোকেশন জুড়ে আপনার পোর্টাল সার্ভার উৎপাদনে যে আসল রিডাইরেক্ট URIগুলি ব্যবহার করে সেগুলির সাথে এগুলি তুলনা করুন। সাবডোমেন পার্থক্য (portal.brand.com বনাম brand.com), প্রোটোকল পার্থক্য (HTTP বনাম HTTPS), এবং পাথ পার্থক্য (/callback বনাম /wechat/callback) পরীক্ষা করুন।

ধাপ ৩: WeChat কনসোলে প্রতিটি বৈকল্পিক রেজিস্টার করুন। WeChat সঠিক-মিল ভ্যালিডেশন সম্পাদন করে, প্রিফিক্স মিল নয়।

ধাপ ৪: যদি URIগুলি মিলে যায়, তবে আপনার পোর্টাল সার্ভার অথরাইজেশন কোডগুলি পুনরায় ব্যবহার করার চেষ্টা করছে কিনা তা তদন্ত করুন। WeChat কোডগুলি একক ব্যবহারের জন্য এবং পাঁচ মিনিট পরে মেয়াদ শেষ হয়ে যায়। যদি আপনার সার্ভার একই কোড দিয়ে টোকেন বিনিময় পুনরায় চেষ্টা করে, তবে এটি দ্বিতীয় প্রচেষ্টায় ৪০২৯ ত্রুটি পাবে।

ধাপ ৫: ডুপ্লিকেট অনুরোধ প্রতিরোধ করতে টোকেন এক্সচেঞ্জ এন্ডপয়েন্টে ইডেমপোটেন্সি প্রয়োগ করুন।

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

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

Q1. আপনি একটি ৬০,০০০ ধারণক্ষমতার স্টেডিয়ামের জন্য একটি Captive Portal স্থাপন করছেন যা একটি উল্লেখযোগ্য চীনা ফ্যান বেস সহ আন্তর্জাতিক ইভেন্টগুলি হোস্ট করছে। মূল অগ্রাধিকার হল সেলুলার কনজেশন কমাতে দরজা খোলার প্রথম ১৫ মিনিটের মধ্যে সমস্ত দর্শকদের অনলাইন করা। মার্কেটিং ডেটা সংগ্রহ একটি গৌণ উদ্দেশ্য। আপনার কোন WeChat OAuth স্কোপ কনফিগার করা উচিত এবং কেন?

ইঙ্গিত: একটি পোর্টাল সার্ভারে ১৫,০০০ সমসাময়িক ব্যবহারকারীর সামনে প্রদর্শিত সম্মতি স্ক্রিনের প্রভাব বিবেচনা করুন।

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

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

Q2. আপনার টিমের একজন নেটওয়ার্ক আর্কিটেক্ট ব্রাউজার থেকে সরাসরি টোকেন বিনিময় কল করে সার্ভার রাউন্ড-ট্রিপ কমাতে Captive Portal-এর ক্লায়েন্ট-সাইড JavaScript-এ WeChat AppSecret সংরক্ষণ করার প্রস্তাব করেছেন। কেন এই পদ্ধতিটি একটি গুরুতর নিরাপত্তা ব্যর্থতা এবং সঠিক আর্কিটেকচারটি কী তা ব্যাখ্যা করুন।

ইঙ্গিত: ক্লায়েন্ট-সাইড কোড কে দেখতে পারে এবং AppSecret তাদের কী করার অনুমতি দেয় তা বিবেচনা করুন।

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

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

Q3. আপনার ভেন্যুটি বিভিন্ন শহরে তিনটি হোটেল প্রপার্টি পরিচালনা করে, যার প্রতিটির নিজস্ব WeChat অফিশিয়াল অ্যাকাউন্ট রয়েছে। একজন লয়্যালটি প্রোগ্রাম মেম্বার যিনি তিনটি প্রপার্টিতেই প্রমাণীকরণ করেছেন, আপনার ডাটাবেসে তার তিনটি ভিন্ন OpenID রয়েছে। আপনি কীভাবে এটিকে একটি একক অতিথি পরিচয়ে সমাধান করবেন?

ইঙ্গিত: WeChat ক্রস-অ্যাকাউন্ট পরিচয় রেজোলিউশনের জন্য একটি প্রক্রিয়া প্রদান করে যার জন্য একটি নির্দিষ্ট প্ল্যাটফর্ম কনফিগারেশন প্রয়োজন।

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

WeChat-এর UnionID প্রক্রিয়াটি প্রয়োগ করুন। open.weixin.qq.com-এ একই ওপেন প্ল্যাটফর্ম রেজিস্ট্রেশনের সাথে তিনটি অফিশিয়াল অ্যাকাউন্টকেই লিঙ্ক করুন। একবার লিঙ্ক হয়ে গেলে, WeChat snsapi_userinfo রেসপন্সে OpenID-এর পাশাপাশি একটি UnionID ফেরত দেয়। একই ওপেন প্ল্যাটফর্ম রেজিস্ট্রেশনের সাথে লিঙ্কযুক্ত সমস্ত অ্যাকাউন্টে একটি নির্দিষ্ট ব্যবহারকারীর জন্য UnionID সামঞ্জস্যপূর্ণ থাকে। ক্রস-প্রপার্টি রেকর্ডের জন্য প্রাথমিক অতিথি সনাক্তকারী হিসাবে UnionID ব্যবহার করতে আপনার ডাটাবেসটি স্থানান্তরিত করুন, অ্যাকাউন্ট-নির্দিষ্ট API কলের জন্য প্রতি-অ্যাকাউন্ট OpenID সংরক্ষণ করুন। UnionID প্রয়োগ করার আগে যে সমস্ত অতিথিরা প্রমাণীকরণ করেছিলেন তাদের জন্য, UnionID ক্যাপচার করতে তাদের পরবর্তী ভিজিটে snsapi_userinfo সহ একটি পুনরায় প্রমাণীকরণ ট্রিগার করুন।

Q4. Cisco Meraki অ্যাক্সেস পয়েন্ট চালিত একটি রিটেল ভেন্যুতে WeChat WiFi প্রমাণীকরণ স্থাপন করার পরে, অতিথিরা রিপোর্ট করছেন যে তারা সফলভাবে WeChat লগইন সম্পন্ন করেছেন কিন্তু পোর্টাল পৃষ্ঠায় ফিরে এসেছেন এবং ইন্টারনেট ব্রাউজ করতে পারছেন না। পোর্টাল সার্ভার লগগুলি সফল টোকেন পুনরুদ্ধারের ইঙ্গিত দেখায়। এর সবচেয়ে সম্ভাব্য কারণ কী এবং আপনি কীভাবে এটি নির্ণয় করবেন?

ইঙ্গিত: পোর্টাল পরিচয় যাচাই করেছে। কিন্তু এখনও কোন কাজটি সম্পন্ন হয়নি?

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

RADIUS Change of Authorisation (CoA) সম্পন্ন হচ্ছে না। পোর্টাল সার্ভার WeChat OAuth-এর মাধ্যমে অতিথির পরিচয় যাচাই করেছে কিন্তু ডিভাইসটিকে walled garden VLAN থেকে গেস্ট VLAN-এ স্থানান্তর করার জন্য Cisco Meraki কন্ট্রোলারকে সফলভাবে নির্দেশ দিতে পারেনি। সমস্যাটি নির্ণয় করতে এগুলি পরীক্ষা করুন: (১) Meraki কন্ট্রোলারে RADIUS CoA সক্রিয় আছে কিনা এবং পোর্টাল সার্ভারের IP-টি একটি অনুমোদিত CoA ক্লায়েন্ট হিসেবে তালিকাভুক্ত আছে কিনা; (২) পোর্টাল সার্ভার এবং কন্ট্রোলারের মধ্যে UDP পোর্ট ৩৭৯৯ খোলা আছে কিনা; (৩) CoA অনুরোধের ত্রুটি বা টাইমআউটের জন্য পোর্টাল সার্ভারের লগগুলি দেখুন; এবং (৪) উভয় পাশে কনফিগার করা শেয়ার্ড সিক্রেটটি মিলছে কিনা। যদি আপনার Meraki লাইসেন্স স্তরে CoA সমর্থিত না হয়, তবে বিকল্প সমাধান হিসেবে MAC অ্যাড্রেস বাইপাস ব্যবহার করা যেতে পারে, যদিও এতে গাইডে উল্লিখিত MAC র্যান্ডমাইজেশনের ঝুঁকি থাকে।

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

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

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

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

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

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

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

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

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

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