ডিজিটাল পাস ও অ্যাক্সেস কার্ডের জন্য মোবাইল অ্যাপ কীভাবে বানাবেন
QR ও NFC ব্যবহার করে ডিজিটাল পাস ও অ্যাক্সেস কার্ডের জন্য মোবাইল অ্যাপ কীভাবে পরিকল্পনা, নির্মাণ ও সুরক্ষিত করবেন—ইস্যু ফ্লো, টেস্টিং ও রোলআউট টিপস সহ।
ব্যবহার কেস এবং সাফল্যের মেট্রিক স্পষ্ট করুন
QR বনাম NFC — অথবা Apple Wallet বনাম ইন‑অ্যাপ পাস—বেছে নেওয়ার আগে আপনার প্রজেক্টে “ডিজিটাল পাস” কী বোঝায় তা নির্দিষ্ট করুন। একটি একক অ্যাপ , , , বা ইস্যু করতে পারে, এবং প্রতিটির পরিচয় যাচাই, রিভোকেশন, এবং ক্রেডেনশিয়াল কত ঘন ঘন বদলাবে—এসব আলাদা চাহিদা আছে।
Visitor pass: কোনো কর্মচারী স্পনসর করে; স্বয়ংক্রিয়ভাবে মেয়াদ শেষ; নির্দিষ্ট এলাকায় সীমাবদ্ধ হতে পারে।
প্রধান ব্যবহারকারীদের চিহ্নিত করুন (শুধু “এন্ড ইউজার” নয়)
যারা সিস্টেমে টাচ করে তাদের তালিকা এবং তাদের লক্ষ্য লিখে রাখুন:
Employees/customers/visitors: সহজ সেটআপ, নির্ভরযোগ্য এন্ট্রি, কম friction।
Admins/security staff: ইস্যু, রিভোক, অডিট, এক্সসেপশন হ্যান্ডল (হারানো ফোন, প্রবেশ না দেয়া)।
Front desk/event staff: দ্রুত যাচাই ও ব্যস্ত সময়ে ট্রাবলশুটিং।
মাপার যোগ্য সাফল্যের মেট্রিক নির্ধারণ করুন
ফলাফল ও অপারেশনের সঙ্গে মিল যায় এমন মেট্রিক বাছুন:
Activation rate: ইনভাইটেড ইউজারদের কত শতাংশ সফলভাবে পাস যোগ/সক্ষম করে।
Door-open success rate: প্রথম বারেই সফল আনলক/স্ক্যান হওয়া অনুপাত।
Time-to-issue: অনুরোধ/অনুমোদন থেকে ক্রেডেনশিয়াল ব্যবহারযোগ্য হওয়া পর্যন্ত সময়।
Support tickets: ভলিউম, প্রধান কারণ, ও সমাধানে গড় সময়।
অফিসলাইন অ্যাক্সেস (এবং সীমা) আগে থেকে ঠিক করুন
যদি দরজা বা স্ক্যানার নেটওয়ার্ক ছাড়াই কাজ করতে হবে, তাহলে কতক্ষণ অফিসলাইন অ্যাক্সেস বৈধ থাকবে (মিনিট, ঘণ্টা, দিন) এবং একটি পাস রিভোক করা হলে কী হবে তা নির্ধারণ করুন। এই সিদ্ধান্ত ক্রেডেনশিয়াল ডিজাইন, রিডার কনফিগারেশন এবং নিরাপত্তা মডেলকে প্রভাবিত করে।
পাস কীভাবে প্রদর্শিত হবে তা বেছে নিন: QR, NFC, এবং ফ্যালব্যাক
আপনার “ডিজিটাল পাস” শুধুমাত্র তখনই কার্যকর যখন এটা স্ক্যান বা ট্যাপ করা হয়। স্ক্রিন বানানোর আগে ঠিক করুন রিডার কী গ্রহণ করবে এবং ব্যবহারকারীরা বাস্তব অবস্থায় কীভাবে পাসটি নির্ভরযোগ্যভাবে দেখাতে পারে (ভিড়, খারাপ কানেকশন, ঠান্ডা, দস্তানা ইত্যাদি)।
প্রচলিত প্রদর্শন অপশন (এবং এগুলোর শক্তি)
QR কোড সর্বজনীন ও সস্তা: কোনো ক্যামেরা‑ভিত্তিক স্ক্যানার—অথবা ভিজ্যুয়াল যাচাইয়ের জন্য ফোন ক্যামেরাও—কাজ করবে। এগুলো প্রতি ব্যক্তিতে ধীর হতে পারে এবং স্ট্যাটিক কোডের উপর নির্ভর করলে কপি করা সহজ।
NFC (ট্যাপ) ফিজিক্যাল ব্যাজের ভালো বিকল্পের মতো লাগে। দ্রুত ও পরিচিত, কিন্তু উপযুক্ত দরজা রিডার ও ডিভাইস সাপোর্টের ওপর নির্ভর করে। এছাড়া প্ল্যাটফর্ম‑কনস্ট্রেইন্ট থাকতে পারে (উদাহরণ: আপনি কি কার এমুলেট করতে পারবেন নাকি Wallet‑ভিত্তিক ক্রেডেনশিয়াল ব্যবহার করতে হবে)।
Bluetooth (হ্যান্ডস‑ফ্রি) অ্যাক্সেসিবিলিটি ও গতি বাড়ায়, কিন্তু রেঞ্জ, ইন্টারফেরেন্স টিউন করতে জটিল এবং “কেন খুলল না?” ধাঁচের মুহূর্ত সৃষ্টি করতে পারে।
One-time links / in-app codes (রোটেটিং কোড, সাইনড টোকেন) শক্তিশালী ফ্যালব্যাক এবং ক্লোনিং ঝুঁকি কমাতে পারে। এগুলোতে অ্যাপ লজিক লাগে এবং ডিজাইনের ওপর নির্ভর করে মাঝে মাঝে নেটওয়ার্ক অ্যাক্সেস প্রয়োজন হতে পারে।
প্রযুক্তিকে আপনার সীমাবদ্ধতার সঙ্গে মিলান
প্রতিটি পদ্ধতিকে মিলান: বিদ্যমান রিডার হার্ডওয়্যার, থ্রুপুট (মানুষ/মিনিট), অফলাইন চাহিদা, বাজেট, এবং সাপোর্ট বোরডেন। উদাহরণ: উচ্চ‑ট্রাফিক টার্নস্টাইল সাধারণত NFC‑এর গতি দাবি করে; ভাড়া‑ভিত্তিক ইভেন্ট প্রবেশপথ QR‑কে সহ্য করতে পারে।
প্রধান পদ্ধতি এবং ইচ্ছাকৃত ফ্যালব্যাক নির্বাচন করুন
প্রায়োগিক প্যাটার্ন হল NFC প্রধান + QR ব্যাকআপ। NFC গতি হ্যান্ডেল করে; QR পুরনো ফোন, ব্রোকেন NFC বা কোন সাইটে NFC না থাকলে কাজ দেয়।
“খারাপ দিন” দৃশ্যপট পরিকল্পনা করুন
নথিভুক্ত করুন ঠিক কী হবে যখন:
ফোন লক আছে: পাস কি লক‑স্ক্রিন থেকে দেখানো যাবে (Wallet), না কি ইউজারকে অ্যাপ আনলক করতে হবে?
কোন নেটওয়ার্ক নেই: ক্রেডেনশিয়াল কি অফলাইন যাচাইযোগ্য (সাইনড টোকেন, ক্যাশড এন্টাইটলমেন্ট) এবং কতক্ষণ?
এই সিদ্ধান্তগুলো রিডার ইন্টিগ্রেশন, নিরাপত্তার দৃষ্টিভঙ্গি, এবং পরবর্তীতে ব্যবহারকারী সাপোর্ট প্লেবুককে গঠন করে।
ইন‑অ্যাপ পাস বনাম Apple Wallet ও Google Wallet নির্ধারণ করুন
ক্রেডেনশিয়াল কোথায় “থাকে” তা শুরু থেকেই সিদ্ধান্ত নিন কারণ এটা রিডার ইন্টিগ্রেশন, ব্যবহারকারীর অভিজ্ঞতা এবং নিরাপত্তা কনস্ট্রেইন্টকে প্রভাবিত করে।
অপশন A: ইন‑অ্যাপ পাস (আপনার অ্যাপের ভিতর)
ইন‑অ্যাপ পাস আপনার অ্যাপ দ্বারা রেন্ডার ও ম্যানেজ করা হয়। এতে UI, অথেনটিকেশন, অ্যানালিটিক্স এবং কাস্টম ওয়ার্কফ্লোতে সর্বোচ্চ নিয়ন্ত্রণ থাকে।
Pros: ব্র্যান্ডিং ও কাস্টম স্ক্রিন পূর্ণ নিয়ন্ত্রণ, ফ্লেক্সিবল অথ (বায়োমেট্রিক্স, step‑up), সমৃদ্ধ কনটেক্সট (সাইট ম্যাপ, নির্দেশ), এবং একাধিক ক্রেডেনশিয়াল টাইপ সহজে সাপোর্ট করা যায়।
Wallet পাস (উদাহরণ: PKPass iOS‑এ) দ্রুত প্রদর্শনের জন্য ডিজাইন করা।
Pros: উচ্চ বিশ্বাসযোগ্যতা ও ডিসকভারিবিলিটি, লক‑স্ক্রিন/কুইক এক্সেস, OS‑হ্যান্ডলিং দ্রুত “কোড দেখান” অভিজ্ঞতা দেয়।
Cons: প্ল্যাটফর্ম‑কনস্ট্রেইন্ট (সমর্থিত বারকোড/NFC ফরম্যাট, কাস্টম UI সীমা), আপডেট Wallet নিয়ম অনুসরন করে, এবং Apple/Google‑বিশেষ সেটআপ (সার্টিফিকেট, ইস্যুয়ার কনফিগারেশন, মাঝে মাঝে রিভিউ) দরকার হতে পারে। ডিপ টেলিমেট্রি সীমিত।
বাস্তবসম্মত সিদ্ধান্ত নিয়ম
যখন গতি, পরিচিতি এবং “সবসময় উপলব্ধ” প্রদর্শন জরুরি—Wallet ব্যবহার করুন (ভিজিটর, ইভেন্ট, সরল দরজা/বারকোড ওয়ার্কফ্লো)। যখন শক্তিশালী পরিচয় যাচাই, সমৃদ্ধ ওয়ার্কফ্লো বা জটিল ক্রেডেনশিয়াল লজিক দরকার—ইন‑অ্যাপ ব্যবহার করুন (মাল্টি‑সাইট স্টাফ এক্সেস, অনুমোদন, রোল‑বেসড অ্যাক্সেস)।
একাধিক পাস টাইপ, টেমপ্লেট এবং ব্র্যান্ডিং
আপনি যদি একাধিক প্রতিষ্ঠান সেবা দেন, প্রতিটি সংগঠনের জন্য টেমপ্লেট পরিকল্পনা করুন: লোগো, রং, নির্দেশ, এবং ভিন্ন ডেটা ফিল্ড। কিছু দল উভয়ই চালায়: দ্রুত প্রবেশের জন্য Wallet পাস এবং প্রশাসন ও সাপোর্টের জন্য ইন‑অ্যাপ ক্রেডেনশিয়াল।
পাস লাইফসাইকেল যা আপনাকে সাপোর্ট করতে হবে
কন্টেইনার যাই হোক, এই লাইফসাইকেল অ্যাকশানগুলো ট্রিগার করার যোগ্য করুন:
Access policy: নিয়ম যা ব্যবহারকারী/গ্রুপকে দরজা ও সময়সূচীর সাথে সংযুক্ত করে।
এই আলাদা বিভাজন ডিভাইস পরিবর্তনের সময় সহায়তা করে: pass ধারণাগতভাবে একই থাকতে পারে যখন credentials রোটেট করে এবং devices বদলায়।
পাস স্টেটস এবং লাইফসাইকেল
স্পষ্ট স্টেট সংজ্ঞায়িত করুন এবং কেবলই ইচ্ছাকৃত ট্রানজিশন অনুমোদন করুন:
pending (invited/enrolling)
active (usable)
suspended (temporarily blocked)
expired (time‑bound end reached)
revoked (permanently invalid)
উদাহরণ ট্রানজিশন: pending → active যাচাইয়ের পরে; active → suspended নীতি লঙ্ঘনের জন্য; active → revoked কর্মবিচ্ছেদের সময়; suspended → active অ্যাডমিন পুনঃসক্রিয়করণে।
আইডেন্টিফায়ার এবং রিডারে ম্যাপিং
দুই স্তরে ইউনিক ID পরিকল্পনা করুন:
একটি স্থায়ী pass_id (ইন্টারনাল) লাইফসাইকেল ও সাপোর্টের জন্য।
এক বা একাধিক credential_id / token_id মান যা রিডার যাচাই করতে পারে।
রিডার কীভাবে টোকেনকে অ্যাক্সেস রুলে ম্যাপ করবে তা সিদ্ধান্ত নিন: সরাসরি লুকআপ (token → user → policy) বা token → policy group (এজে দ্রুত)। আইডেন্টিফায়ারগুলো অনুমানযোগ্য না হওয়া উচিত (র্যান্ডম, সিরিয়াল নয়)।
অডিট লগ: কী রেকর্ড করবেন এবং কোথায়
অডিট লগকে অ্যাপেন্ড‑ওনলি এবং “কারেন্ট স্টেট” টেবিল থেকে আলাদা বিবেচনা করুন। অন্তত নিম্নলিখিত রেকর্ড করুন:
এই ইভেন্টগুলো ট্রাবলশুটিং, কমপ্লায়েন্স এবং অ্যাবিউজ ডিটেকশনের জন্য আপনার সোর্স‑অফ‑ট্রুথ হবে।
ইউজার এনরোলমেন্ট ও পাস ইস্যু ফ্লো নির্মাণ করুন
ডিজিটাল পাস প্রজেক্ট “প্রথম ৫ মিনিট” অভিজ্ঞতার উপর নির্ভর করে সফলতা: বাস্তবে একজন ব্যক্তি কত দ্রুত এনরোল, ক্রেডেনশিয়াল পায়, এবং পরবর্তী কী করতে হবে তা বুঝতে পারে।
এনরোলমেন্ট পথ (১–২ প্রাথমিক বেছে নিন)
সিকিউরিটি ও ডিপ্লয়মেন্ট সাইজ অনুযায়ী দলগুলো সাধারণত মিক্স সাপোর্ট করে:
Invite link: একটি অ্যাডমিন (বা HR সিস্টেম) টাইম‑লিমিটেড লিংক জেনারেট করে। ইউজার সেটা ফোনে খুলে সঠিক ফ্লোতে চলে যায়।
Email/SMS verification: ফোন নম্বর বা ইমেইল যাচাই করতে ওয়ান‑টাইম কোড পাঠান।
SSO: কর্মচারীদের জন্য SAML/OIDC ব্যবহার করুন যাতে পাস কেবল কর্পোরেট সাইন‑ইনের পরে ইস্যু হয়।
ইস্যু এমনভাবে ডিজাইন করুন যাতে ব্যবহারকারী “কিভাবে করবো” ভাবতে না হয়:
In‑app pass: ক্রেডেনশিয়াল আপনার অ্যাপেই থাকে; আপনি আপডেট ও UI নিয়ন্ত্রণ করেন। কাস্টম অথেনটিকেশন, অফলাইন রুল, বা বিশেষ রিডার আচরণের জন্য উপযুক্ত।
Wallet add: যাচাইয়ের পরে “Add to Apple Wallet” / “Add to Google Wallet” বোতাম দিন। ইনভাইট থেকে ওয়ালেট‑অ্যাড স্ক্রিন খোলার জন্য ডিপ লিংক সাপোর্ট করুন।
QR invitation fallback: অন‑সাইট, রিসেপশন কিওস্ক একটি QR দেখাতে পারে যা এনরোলমেন্ট লিংক খুলে (ইমেইল না পাওয়ার ক্ষেত্রে সহায়ক)।
কপিটি অত্যন্ত স্পষ্ট রাখুন: পাস কী জন্য, কোথায় দেখা যাবে (অ্যাপ বনাম ওয়ালেট), এবং দরজায় কী করতে হবে।
ডিভাইস পরিবর্তন ও রিইস্যু নীতি
এটি আগে থেকেই পরিকল্পনা করুন যাতে সাপোর্ট টিকিট কম হয়:
নতুন ফোন: সেলফ‑সার্ভ রিইনরোলমেন্ট দিন যা পরিচয় পুনর্ব্যবহার করে এবং পাস পুনরায় ইস্যু করে।
একাধিক ডিভাইস: অনুমতি দেবেন কিনা সিদ্ধান্ত নিন। অনুমতি দিলে সংখ্যা ক্যাপ করুন এবং সেটিংসে সক্রিয় ডিভাইস দেখান।
হারানো ডিভাইস: তৎক্ষণিক রিমোট রিভোক সক্ষম করুন, তারপর পুনরায় যাচাই করে রিইস্যু দিন।
বাস্তব‑দুনিয়ার ব্যর্থতার জন্য ব্যবহারকারী মেসেজ
বন্ধুত্বপূর্ণ, নির্দিষ্ট মেসেজ লিখুন:
Denied access (পরবর্তী পদক্ষেপ: “Security‑কে যোগাযোগ করুন” বনাম “রিফ্রেশ পরে চেষ্টা করুন”)
Expired pass (এক্সপায়ারি তারিখ এবং রিনিউ অ্যাকশন অন্তর্ভুক্ত করুন)
Connectivity issues (কি অফলাইনে কাজ করে এবং অনলাইনে কিভাবে রিকোভারি করতে হবে তা ব্যাখ্যা করুন)
ভাল ইস্যু করা কেবল “একটি পাস তৈরি” নয়—এটি একটি সম্পূর্ণ, বোধগম্য জার্নি যাতে প্রত্যাশিত রিকোভারি পথ থাকবে।
ব্যবহারকারী ও অ্যাডমিনদের জন্য অথেনটিকেশন ও অথরাইজেশন
ডিজিটাল পাসগুলো বিশ্বাসযোগ্য হবে যতটা পরিচয় ও পারমিশনগুলো নির্ভরযোগ্য। অথেনটিকেশন (আপনি কে) ও অথরাইজেশন (আপনি কী করতে পারবেন)—এগুলোকে প্রোডাক্ট ফিচার হিসেবে বিবেচনা করুন, শুধু প্লাম্বিং নয়।
অথেনটিকেশন পদ্ধতি বাছাই
আপনার দর্শক ও ঝুঁকি মাত্রার সঙ্গে মিলিয়ে লগইন পদ্ধতি বাছুন:
Email + one‑time passcode (OTP): কনজিউমারদের কাছে সহজ, পাসওয়ার্ড রিসেট কম।
Passwordless “magic link”: লো‑ফ্রিকশন এনরোলমেন্টের জন্য ভালো, তবে নির্ভরযোগ্য ইমেইল ডেলিভারি দরকার।
SSO / enterprise identity (SAML/OIDC): কর্মচারী, কন্ট্রাক্টর ও ক্যাম্পাসের জন্য সেরা; HR/IT পলিসির সাথে ইন্টিগ্রেট করে।
যদি আপনি একাধিক টেন্যান্ট সাপোর্ট করেন, আগে থেকে সিদ্ধান্ত নিন একটি ইউজার কি একাধিক টেন্যান্টে থাকতে পারবে এবং তারা কিভাবে কনটেক্সট সুইচ করবে।
অথরাইজেশন: রোল, স্কোপ এবং অডিটেবিলিটি
সরল ভাষায় রোল সংজ্ঞায়িত করুন (উদাহরণ: Pass Holder, Front Desk, Security Admin, Auditor) এবং সেগুলোকে পারমিশনে ম্যাপ করুন:
কে issue, reissue, revoke, বা suspend করতে পারবে
কে view access logs এবং রিপোর্ট এক্সপোর্ট করতে পারবে
কে facility rules (door groups, schedules) পরিবর্তন করতে পারবে
অথরাইজেশন চেকগুলো সার্ভারে রাখুন (শুধু UI‑তে নয়) এবং প্রতিটি সংবেদনশীল অ্যাকশন লগ করুন: who, what, when, where (IP/device), এবং ম্যানুয়াল অ্যাডমিন অ্যাকশনের জন্য reason ফিল্ড।
সেশন, ডিভাইস ট্রাস্ট ও ব্যবহারকারীর সুবিধা
শর্ট‑লিভড অ্যাক্সেস টোকেন ব্যবহার করুন রিফ্রেশ টোকেনসহ, এবং পাস দেখানোর জন্য নিরাপদ রি‑এন্ট্রি হিসেবে বায়োমেট্রিকস (Face ID/Touch ID) সমর্থন করুন।
উচ্চ‑সিকিউরিটি ডিপ্লয়মেন্টে ডিভাইস বাইন্ডিং যোগ করুন যাতে ক্রেডেনশিয়াল কেবল এনরোলড ডিভাইস(গুলো)তে কার্যকর থাকে। এটা কপি করা টোকেন অন্যত্র ব্যবহারে কঠিন করে।
অ্যাডমিন সেফগার্ডস যা ভুল ও আবিউজ কমায়
অ্যাডমিন টুলগুলোর জন্য অতিরিক্ত গার্ডরেইল দরকার:
Approval workflows বড় আকারে ইস্যু বা প্রিভিলেজড পাসের জন্য
Rate limits issuance/reissue এন্ডপয়েন্টে
Alerts অস্বাভাবিক প্যাটার্নের জন্য (একই ইমেইল ডোমেইনে অনেক পাস ইস্যু, আউটসাইড‑বিজনেস‑আওয়ার স্পাইক)
এই পলিসিগুলো একটি ইন্টারনাল রানবুকে ডকুমেন্ট করুন এবং অ্যাডমিন UI‑তে লিংক করুন (উদাহরণ: /docs/admin-security) যাতে অপারেশন কনসিস্টেন্ট থাকে।
সিকিউরিটি মডেল: ক্লোনিং, স্ক্রিনশট এবং রিপ্লে প্রতিরোধ
ডিজিটাল পাসের সিকিউরিটি হল “QR লুকিয়ে রাখা” মাত্র নয় — বরং সিদ্ধান্ত নেওয়া যে রিডার কী‑কে বিশ্বাস করবে। সঠিক মডেল নির্ভর করে কানেক্টিভিটি, রিডার ক্ষমতা, এবং রিভোকেশন দরকার কত দ্রুত।
রিডার কী যাচাই করে?
সাধারণত তিনটি প্যাটার্ন থাকে:
Signed payload (offline validation): QR/NFC‑এ একটি পে‑লোড থাকে যা আপনার সিস্টেম সাইন করেছে। রিডার লোকালি সিগনেচার যাচাই করে, তাই দরজাগুলো অফলাইনে কাজ করে। দ্রুত, কিন্তু রিভোকেশন কেবল রিডার আপডেটের গতি অনুসারে।
Server check (online validation): রিডার স্ক্যান করা টোকেন ব্যাকএন্ডে পাঠায় এবং রিয়েল‑টাইমে অনুমোদন/অস্বীকৃতি পায়। রিভোকেশন তাৎক্ষণিক, কিন্তু নেটওয়ার্ক আপটাইম ও লেটেন্সির ওপর নির্ভর করে।
Hybrid: রিডার প্রথমে সিগনেচার যাচাই করে (স্পষ্ট ফেক ব্লক করতে), তারপর সংযুক্তি থাকলে উচ্চ‑ঝুঁকিপূর্ণ এলাকায় সার্ভার কল করে।
QR কোড: স্ক্রিনশট ও রিপ্লে ঝুঁকি কমান
স্ট্যাটিক QR সহজে শেয়ার ও স্ক্রিনশট করা যায়। প্রেফার করুন রোটেটিং বা সময়‑সীমিত কোড:
স্বল্প-মেয়াদী টোকেন ব্যবহার করুন (উদাহরণ: 15–60 সেকেন্ড)।
সম্ভব হলে ডিভাইস/সেশন‑বাইন্ড করুন (এভাবে ফরওয়ার্ড করা স্ক্রিনশট কোথাও ভ্যালিড হবে না)।
অ্যান্টি‑রিপ্লে ডেটা (timestamp + nonce) অন্তর্ভুক্ত করুন এবং যেখানে “one‑time entry” লাগে সেখানে ব্যাকএন্ড ইতিমধ্যেই ব্যবহৃত টোকেন প্রত্যাখ্যান করবে।
অফলাইন QR ভেলিডেশন সাপোর্ট করলে QR‑টি টাইম‑বক্সড ও সাইন করা রাখুন, এবং বুঝে নিন যে রিয়েল‑টাইম রিভোকেশন ছাড়া কাজ চলবে না।
NFC ক্রেডেনশিয়াল: ডিভাইসে কী‑গুলো রক্ষা করুন
NFC‑এর জন্য পরিকল্পনা করুন কোথায় সিক্রেট থাকবে এবং কীভাবে ব্যবহার হবে:
Minutes: ঘন reader sync + স্বল্প‑মেয়াদী টোকেন কাজ করতে পারে।
Hours: কম‑ঝুঁকির এলাকায় পর্যাপ্ত হতে পারে।
এটি সিকিউরিটি ও অপারেশন SLO হিসেবে লিখে রাখুন; কারণ এটি রিডার কনফিগারেশন, ব্যাকএন্ড উপলব্ধতা এবং ইনসিডেন্ট রেসপন্সকে প্রভাবিত করে।
দরজা রিডার ও এক্সেস কন্ট্রোল সিস্টেমের সঙ্গে ইন্টিগ্রেট করুন
এটাই সেই জায়গা যেখানে আপনার ডিজিটাল পাস বাস্তবে মিলে: টার্নস্টাইল, দরজা কন্ট্রোলার, লিফট রিডার, এবং ফ্রন্ট‑ডেস্ক স্ক্যানার। এখানে নেওয়া ইন্টিগ্রেশন সিদ্ধান্তগুলো নির্ভরযোগ্যতা, গতি, এবং নেটওয়ার্ক না থাকলে কী ঘটে—এসবকে প্রভাবিত করে।
রিডার ভ্যালিডেশন পথ বেছে নিন
প্রচলিত ইন্টিগ্রেশন পথগুলো:
Reader → your API (cloud validation): রিডার (অথবা তার কন্ট্রোলার) প্রতিটি ট্যাপ/স্ক্যানের জন্য আপনার ভ্যালিডেশন এন্ডপয়েন্ট কল করে। নমনীয়, কিন্তু নেটওয়ার্ক‑কোয়ালিটি‑নির্ভর এবং রেট‑লিমিটিং কেয়ারফুল করা উচিত।
Reader → existing access control system (ACS): আপনার অ্যাপ এমন একটি ক্রেডেনশিয়াল ইস্যু করে যা ACS বুঝে, এবং ACS সিদ্ধান্ত নেয়। দরজায় কাস্টম লজিক কম থাকে, কিন্তু ডেটা এনকোডিং সীমাবদ্ধ হতে পারে।
Reader → local gateway (edge validation): রিডার অন‑সাইট সার্ভিসকে বলে ক্রেডেনশিয়াল লোকালি ভ্যালিডেট করতে, যা ব্যাকএন্ডের সাথে সিঙ্ক রাখে। রেসিলিয়েন্স বাড়ে এবং লেটেন্সি পূর্বানুমানযোগ্য থাকে।
রেসপন্স‑টাইম ও অফিসলাইন আচরণ টার্গেট নির্ধারণ করুন
শুরুতেই টার্গেট নির্ধারণ করুন (উদাহরণ: “আনলক সিদ্ধান্ত 300–500 ms‑এর মধ্যে”)। এছাড়া প্রতিটি সাইটে “অফলাইন” মানে কী তা ডকুমেন্ট করুন:
নেটওয়ার্ক ড্রপ করলে আপনি fail closed (সবই অস্বীকার) করবেন নাকি নির্দিষ্ট দরজাগুলোর জন্য fail open করবেন?
এসব অপস ড্যাশবোর্ডে দেখান এবং ক্রিটিক্যাল ইস্যুগুলো অন‑কল এ রুট করুন। “কেন আমাকে নাকচ করা হয়েছে?” দ্রুত জানার ওয়ার্কফ্লো রোলআউট সময় সাপোর্ট লোড কমায়।
ব্যাকএন্ড আর্কিটেকচার: API, সাইনিং, ও স্কেলিবিলিটি
ডিজিটাল পাস সিস্টেম ব্যাকএন্ডের উপর নির্ভর করে: এটি ক্রেডেনশিয়াল ইস্যু করে, ভ্যালিডিটি নিয়ন্ত্রণ করে, এবং দরজায় দাঁড়িয়ে পড়লে কী ঘটল—দ্রুত ও বিশ্বাসযোগ্যভাবে রেকর্ড করে।
কোর API‑গুলো (সহজ ও ভার্সনড রাখুন)
ছোট সেট এন্ডপয়েন্ট দিয়ে শুরু করুন যা আপনি বিকশিত করতে পারবেন:
POST /v1/passes/issue — ব্যবহারকারীর জন্য পাস তৈরি করুন, একটি activation link বা pass payload রিটার্ন করুন
POST /v1/passes/refresh — আইডেন্টিফায়ার রোটেট/এন্টাইটেলমেন্ট আপডেট করুন, সর্বশেষ পাস ডেটা রিটার্ন করুন
POST /v1/passes/revoke — তৎক্ষণিকভাবে পাস ইনভ্যালিড করুন (হারানো ফোন, অ্যাক্সেস স্থগিত)
POST /v1/events — এন্ট্রি চেষ্টা ও আউটকাম (accepted/denied/error) লগ করুন
কিছু ভ্যালিডেশন ডিভাইস বা রিডারে ঘটলেও, অডিট, রিমোট রিভোকেশন, ও “ব্রেক‑গ্লাস” অপারেশনের জন্য সার্ভার‑সাইড ভ্যালিডেশন API রাখুন।
সাইনিং ও কী ম্যানেজমেন্ট (কিভাবে নিরাপদে রোটেট করবেন)
আপনি যদি Apple Wallet (PKPass) বা অন্য সাইনড পে‑লোড সাপোর্ট করেন, সাইনিং কী‑গুলো প্রোডাকশন সিক্রেট হিসেবে ট্রিট করুন:
প্রাইভেট কী গুলো ম্যানেজড KMS/HSM‑এ রাখুন; অ্যাপ সার্ভার বা CI লগে কখনো রাখবেন না।
কী নির্ধারিত সময়ে বা ইন্ডিসিডেন্টে রোটেট করুন; ট্রানজিশনের সময় পুরোনো পাসগুলো কাজ করতে পারে—এজন্য একাধিক পাবলিক কী সক্রিয় রাখুন।
প্রতিটি সাইনিং অপারেশন অডিট করুন (কে/কি ইস্যু করলো, কাকে, কখন, কোন কী ভার্সন ব্যবহার করে)।
প্রায়োগিক প্যাটার্ন: একটি আলাদা “signing service” যা সরল ইন্টারফেস (উদাহরণ: “sign pass payload”) দেয় এবং অ্যাপلیکেশন থেকে আইসোলেটেড থাকে।
পিক এন্ট্রি টাইমে স্কেলিং ডিজাইন করুন
এন্ট্রি স্পাইক পূর্বানুমানযোগ্য (৯:০০ AM, ইভেন্ট স্টার্ট)। বর্শ্টি রিডের জন্য পরিকল্পনা করুন:
রিভোকেশন লিস্ট ও এন্টাইটেলমেন্ট লুকআপে ক্যাশিং ব্যবহার করুন, ইস্যুতে রিট্রাই ও আইডেম্পোটেন্সি কী ব্যবহার করুন, এবং অ্যানালিটিক্স/নোটিফিকেশন মত নন‑ক্রিটিক্যাল কাজগুলো কিউ করুন যাতে ভ্যালিডেশন দ্রুত থাকে। রিডার অনলাইন হলে ভ্যালিডেশন ল্যাটেন্সি কম রাখতে চ্যাটি ডিপেন্ডেন্সি এড়ান।
প্রাইভেসি কন্ট্রোল ও লগ রিটেনশন
ব্যক্তিগত ডেটা কম রাখুন: পাস রেকর্ডে নাম/ইমেইলের পরিবর্তে ইন্টারনাল ইউজার ID ব্যবহার করুন। রিটেনশন আগেই নির্ধারণ করুন (উদাহরণ: এন্ট্রি লগ 30–90 দিন রাখুন যদি না দীর্ঘমেয়াদি প্রয়োজন হয়), এবং অপারেশনাল লগ আলাদা রাখুন সিকিউরিটি/অডিট লগ থেকে কঠোর এক্সেস কন্ট্রোল দিয়ে।
দ্রুত বানান (লক‑ইন ছাড়া)
আপনি দ্রুত Iterate করলে—অ্যাডমিন পোর্টাল, ইস্যু API, এবং প্রাথমিক মোবাইল অভিজ্ঞতা—এর জন্য টুলগুলো (উদাহরণ: Koder.ai) ব্যবহার করে একটি ওয়াকিং পাইলট শর্ট‑টাইমে তৈরি করা যায়। পরে যখন নির্দিষ্ট ACS বা অন‑প্রেম গেটওয়ের সাথে ইন্টিগ্রেট করতে চান, তখন সোর্স কোড এক্সপোর্ট করা সহজ।
মোবাইল অ্যাপ UX: সেটআপ, প্রদর্শন, ও অ্যাক্সেসিবিলিটি
ডিজিটাল পাস সফলতা নির্ভর করে সেই স্ক্রিনের ওপর যার সামনে মানুষ দরজায় দাঁড়ায়। তিনটি মুহূর্ত অপ্টিমাইজ করুন: প্রথমবার সেটআপ, “এখন আমার পাস দেখান”, এবং “কিছু ভুল হয়েছে—দ্রুত সাহায্য”।
অ্যাপ পদ্ধতি বেছে নিন
Native (iOS/Android): NFC, Wallet ইন্টিগ্রেশন, ও পরিশীলিত সিস্টেম আচরণের জন্য শ্রেষ্ঠ।
Cross‑platform (Flutter/React Native): শেয়ার্ড UI ও দ্রুত ইটারেশন জন্য ভাল, কিন্তু NFC, ব্যাকগ্রাউন্ড আচরণ, ও Wallet হ্যান্ডঅফ দ্রুত ভ্যালিডেট করুন।
Web‑based companion: QR‑only প্রোগ্রামের জন্য ও দ্রুত পাইলটের জন্য কাজ করে, কিন্তু ক্যামেরা পারমিশন ও কানেক্টিভিটির ওপর বেশি নির্ভর করতে হবে।
আপনি যদি Apple Wallet / Google Wallet সাপোর্ট করেন, তা পরিষ্কার জানিয়ে দিন অ্যাপটি প্রভিশনিংয়ের পরে কি প্রয়োজন হবে কি না। অনেক ইউজার পছন্দ করে “add to wallet and forget”।
চাপের সময় কাজ করবে এমন পাস ডিসপ্লে
“প্রেজেন্ট পাস” স্ক্রিনটি বোর্ডিং পাসের মতো: তৎক্ষণিক, উজ্জ্বল, এবং পড়তে সহজ হওয়া উচিত।
QR রেন্ডারিং: হাই‑কনট্রাস্ট কোড, বড় কোয়াইট জোন, প্রয়োজনে অরিয়েন্টেশন লক, এবং “maximize brightness” প্রম্পট।
NFC ট্যাপ UI: সহজ “Hold near reader” স্টেট, পজিশনিং নির্দেশের অ্যানিমেশন, এবং পরিষ্কার সাফল্য কনফার্মেশন।
Wallet deep links: একটি এক‑ট্যাপ “Open in Wallet” / “Open in Google Wallet” অ্যাকশন দিন (ইউজারকে সরাসরি রুট করুন)।
পাস মেনুর আড়ালে লুকাবেন না। একটি পারসিস্টেন্ট হোম‑স্ক্রিন কার্ড বা একটিই প্রাইমারি বাটন দরজা‑দিলে বিলম্ব কমায়।
অ্যাক্সেসিবিলিটি ও স্পষ্টতা
Large Text, Dynamic Type, স্ক্রিন রিডার লেবেল (“Access pass QR code”), এবং high‑contrast থিম সাপোর্ট করুন। এরর স্টেটগুলো UX‑এর অংশ হিসেবে বিবেচনা করুন: ক্যামেরা ব্লক, NFC বন্ধ, পাস মেয়াদ শেষ, বা রিডার রেসপন্স না করা—প্রত্যেকটির জন্য প্লেইন‑ল্যাঙ্গুয়েজ ফিক্স ("Enable Camera in Settings") ও একটি ফ্যালব্যাক অ্যাকশন যোগ করুন।
এজ কেস ডিজাইন করুন
টাইমজোন ও ডিভাইস ক্লক‑ড্রিফট টাইম‑বেসড পাসকে “ভুল” দেখাতে পারে—সুতরাং ভেন্যুর টাইমজোন সহ সময় দেখান এবং একটি সূক্ষ্ম “Last synced” ইন্ডিকেটর যোগ করুন।
এছাড়া প্ল্যান করুন: airplane mode, লবি‑এ ব্য dic মার্কা reception, পারমিশন বাতিল (camera/NFC), ও লো‑ব্যাটারি মোড। একটি ছোট “Troubleshoot” লিংক /help/mobile-pass‑এ সাপোর্ট কিউ কমাতে পারে।
টেস্টিং স্ট্র্যাটেজি: ডিভাইস, রিডার, অফলাইন ও অ্যাবিউজ কেস
মোবাইল অ্যাক্সেস কার্ড অ্যাপের টেস্টিং হলো “এটি খোলে কি?” নয়— বরং “চাপের মধ্যে এটা প্রতিবার খুলে কি না?” হিসাবে ভাবুন। টেস্টিংকে একটি প্রোডাক্ট রিকোয়্যারমেন্ট হিসেবে দেখুন।
একটি ব্যবহারিক টেস্টিং ম্যাট্রিক্স তৈরি করুন
এটি এমন একটি ম্যাট্রিক্স দিয়ে শুরু করুন যা ব্যবহারকারীরা আসলে বহন করে এবং আপনার দরজাগুলো যেগুলো ব্যবহার করে তা প্রতিফলিত করে:
ডিভাইস: পুরনো ও নতুন iPhone/Android‑এর মিশ্র, বিভিন্ন স্ক্রিন সাইজ, এবং নীচ স্তরের ক্যামেরা মডেলগুলোর জন্য QR স্ক্যান টেস্ট।
OS ভার্সন: অন্তত বর্তমান ও একটি পূর্ববর্তী প্রধান iOS/Android ভার্সন অন্তর্ভুক্ত করুন।
রিডার মডেল: আপনি যে প্রতিটি দরজা রিডার ফার্মওয়্যার/ভার্সন সাপোর্ট করেন, টার্নস্টাইল ও হ্যান্ডহেল্ড স্ক্যানারসহ।
ইন‑অ্যাপ ক্রেডেনশিয়াল ও ওয়ালেট ফ্লো (Apple Wallet pass / Google Wallet pass) উভয়ই অন্তর্ভুক্ত করুন—কারণ PKPass আচরণ ও সিস্টেম UI‑র সময়িং ভিন্ন হতে পারে।
বাস্তব‑দুনিয়ার এন্ট্রি কন্ডিশন রিহার্স করুন
ল্যাব‑পারফেক্ট স্ক্যান বাস্তব লাইনের মতো হবে না। “রাশ টেস্ট” চালান যেখানে 20–50 জন মানুষ দ্রুত, ধারাবাহিকভাবে পাস উপস্থাপন করে, সাথে:
খারাপ আলো ও গ্লেয়ার (আউটডোর সান, ডিম লবি)
দুর্বল কানেক্টিভিটি (Wi‑Fi ড্রপ, দুর্বল LTE)
অফলাইন মোড (airplane mode + ডিভাইস রিবুট) ক্যাশড ক্রেডেনশিয়াল ও UX গাইডেন্স নিশ্চিত করতে
মেজার করুন median time‑to‑entry, failure rate, এবং recovery time (ব্যবহারকারী পরবর্তী কী করে)।
অ্যাবিউজ ও ব্যর্থতা দৃশ্যপট ভ্যালিডেট করুন
অ্যাকটিভলি টেস্ট করুন:
রিপ্লে চেষ্টা (একই QR তার ভ্যালিডিটি উইন্ডোর মধ্যে পুনরায় ব্যবহার)
স্ক্রিনশট ব্যবহার ও স্ক্রিন‑রিকর্ডিং এজ‑কেস
রিভোক করা পাসের চেষ্টা (সার্ভার‑সাইড রিভোকেশনের পরে তাৎক্ষণিক ডিনায়াল)
রেট লিমিট ও বারবার ব্যর্থতার জন্য লকআউট
প্রোডাকশনের মতো স্টেজ প্রস্তুত রাখুন
স্টেজিং এনভায়রনমেন্ট রাখুন টেস্ট রিডার ও সিনথেটিক ট্র্যাফিক দিয়ে যা পিক ইভেন্ট সিমুলেট করে। লোড‑এ পাস ইস্যু, আপডেট, ও রিভোকেশন যাচাই করুন, এবং লগিং এমন রাখুন যাতে “tap/scan → decision → door result” এন্ড‑টু‑এন্ড ট্রেস করা যায়।
লঞ্চ, রোলআউট, ও পর্যবেক্ষণীয় অপারেশন
সফল লঞ্চ বড় রিলিজ নয়—বরং প্রতিটি দরজায় প্রতিদিন পূর্বানুমানযোগ্য প্রবেশ নিশ্চিত করা। নিয়ন্ত্রিত রোলআউট, স্পষ্ট সাপোর্ট পথ, এবং মেট্রিক যা ঘর্ষণ লুকায় তা পরিকল্পনা করুন।
ফিজিক্যাল কার্ড থেকে মাইগ্রেট করুন ভাঙিয়ে না ফেলেই
অধিকাংশ সংস্থা ধাপে ধাপে রোলআউট করলে ভালো ফল পায়:
Pilot group first (security team, facilities, একটি অফিস/ফ্লোর) রিডার, এনরোলমেন্ট, ও এজ কেস যাচাই করার জন্য।
Dual‑credential period যেখানে কর্মচারীরা ফিজিক্যাল কার্ড অথবা ডিজিটাল পাস উভয়ের যে কোনোটা ব্যবহার করতে পারবে। একটি টার্গেট end date রাখুন, কিন্তু কন্ট্রাক্টর বা বিশেষ ডিভাইসের জন্য exception রাখুন।
Training and comms: সংক্ষিপ্ত “কিভাবে প্রবেশ করবেন” নির্দেশ, কোথায় ট্যাপ/স্ক্যান করবেন, ফোন ডেড হলে কী করবেন, এবং সাহায্য কিভাবে পাবেন।
ব্যবহারযোগ্য সাপোর্ট প্লেবুক
আপনার হেল্পডেস্ক ও অ্যাডমিনদের জন্য সহজ, পুনরাবৃত্তিযোগ্য ওয়ার্কফ্লো তৈরি করুন:
Lost phone: ত্বরজনাত রিভোক করুন; পরিচয় যাচাই করে নতুন ডিভাইসে রিইস্যু করুন।
Denied access: রিডার লগ চেক করুন, পাস স্ট্যাটাস (active/expired), ব্যবহারকারীর পারমিশন, টাইম শিডিউল; প্রয়োজনে সাময়িক ফ্যালব্যাক প্রদান করুন।
Device switch/upgrade: অটোমেটেড রিইনরোলমেন্ট যখন সম্ভব, রেট লিমিট ও অ্যাডমিন ওভাররাইড সহ।
Re‑issue: কখন আইডেন্টিফায়ার রোটেট করবেন বনাম একই পাস re‑activate করবেন তা সংজ্ঞায়িত করুন (জরুরি ফ্রড প্রতিরোধ ও অডিট ট্রেইলের জন্য গুরুত্বপূর্ণ)।
এই প্লেবুকগুলো এক জায়গায় রাখুন এবং অ্যাডমিন কনসোল ও ইন্টারনাল ডকসে লিংক রাখুন।
ইনস্ট্রুমেন্টেশন ও অপারেশনাল মেট্রিক
ইনস্ট্রুমেন্ট করে বাস্তব এন্ট্রি পারফরম্যান্স মেজার করুন, কেবল ইন্সটল নয়:
অ্যানালিটিক্স ড্যাশবোর্ড লাইভ এবং সাপ্তাহিক রিভিউ ক্যালেন্ডার
স্পষ্ট ইউজার কমস এবং সাহায্য অনুরোধের পথ (/contact)
কমার্শিয়াল ও স্কেলিং প্ল্যান নিশ্চিত (/pricing)
সাধারণ প্রশ্ন
অ্যাক্সেস-কার্ড অ্যাপে “ডিজিটাল পাস” ঠিক কী হিসেবে গণ্য হবে?
একটি ডিজিটাল পাস হলো ব্যবহারকারীর মুখমুখি “কার্ড” যা কেউ প্রবেশ বা অধিকার যাচাইয়ের জন্য প্রদর্শন করে (ব্যাজ, সদস্যপদ আইডি, টিকিট, ভিজিটর পাস)। ভেতরে এটা এক বা একাধিক ক্রেডেনশিয়াল (QR পে লোড, NFC টোকেন) দ্বারা সমর্থিত থাকে যেগুলো রিডার যাচাই করে, এবং একটি লাইফসাইকেল (issue, update, suspend, revoke, re-issue) থাকে যা অপারেশনালি আপনি পরিচালনা করতে পারেন।
QR/NFC বা Wallet/in-app নির্বাচন করার আগে আমি কিভাবে ব্যবহার কেস এবং সাফল্যের মেট্রিক সীমাবদ্ধ করব?
এন্ড-টু-এন্ড ওয়ার্কফ্লো (request → approval → issuance → entry → audit) লিখে শুরু করুন, তারপর পরিমাপযোগ্য মেট্রিকগুলো বাছাই করুন:
Activation rate (কত শতাংশ ইনভাইটেড ইউজার সফলভাবে পাস যোগ/সক্ষম করে)
First-try success rate (দরজায় প্রথম চেষ্টায় স্ক্যান/ট্যাপ কাজ করে)
Time-to-issue (অনুরোধ/অনুমোদন থেকে ব্যবহারযোগ্য ক্রেডেনশিয়াল পর্যন্ত সময়)
Support ticket volume এবং প্রধান কারণগুলো
এই মেট্রিকগুলো বাস্তব অপারেশনের সাথে “কাজ করে” কি না তা নিশ্চিত করবে।
কখন আমাকে ডিজিটাল পাসের জন্য QR কোড বনাম NFC ব্যবহার করা উচিত?
যদি বিস্তৃত কম্প্যাটিবিলিটি ও কম হার্ডওয়্যার খরচ দরকার হয় এবং আপনি ধীরতর প্রবাহ মেনে নিতে পারেন—তবে QR ব্যবহার করুন। দ্রুত, পরিচিত “ট্যাপ-টু-এন্টার” অভিজ্ঞতা এবং সামঞ্জস্যপূর্ণ রিডার থাকলে NFC ব্যবহার করুন।
একটা প্রচলিত, বাস্তবমুখী সেটআপ হল:
NFC প্রধান দ্রুততার জন্য
QR ব্যাকআপ পুরনো ফোন, ভাঙা NFC বা নন‑NFC সাইটগুলোর জন্য
দরজা ও স্ক্যানারের জন্য অফিসলাইন অ্যাক্সেস এবং রিভোকেশন সম্পর্কে আমি কিভাবে ভাবব?
তিনটি জিনিস সিদ্ধান্তে নিন (এবং ডকুমেন্ট করুন):
Offline validity window (মিনিট/ঘণ্টা/দিন)
Revocation behavior while offline (সিঙ্ক হওয়ার আগে ডিনাই করা হবে কি না, না হলে টেম্পোরারি অনুমোদন)
প্রতিটি দরজার/সাইটের fail open বনাম fail closed পলিসি
যদি প্রায়-তত্ক্ষণাত রিভোকেশন দরকার হয়, সাধারণত বা অত্যন্ত ঘন reader/gateway সিঙ্ক দরকার।
আমার পাস কি Apple/Google Wallet-এ থাকবে নাকি অ্যাপে থাকা উচিত?
যখন দ্রুত প্রদর্শন এবং লক-স্ক্রিন অ্যাক্সেস গুরুত্বপূর্ণ (ভিজিটর, ইভেন্ট, সরল বারকোড ওয়ার্কফ্লো) — তখন Wallet বেছে নিন। যখন আপনি সমৃদ্ধ ওয়ার্কফ্লো এবং কঠোর পরিচয় নিয়ন্ত্রণ চান (অনুমোদন, মাল্টি-সাইট এক্সেস, step-up auth) — তখন in-app বেছে নিন।
অনেক দল দুইটি চালায়:
দ্রুত প্রবেশের জন্য Wallet পাস
সাপোর্ট, আপডেট ও ট্রাবলশুটিং-এর জন্য ইন-অ্যাপ ক্রেডেনশিয়াল/অ্যাডমিন ভিউ
পাস, ক্রেডেনশিয়াল, ডিভাইস এবং দরজার জন্য আমাকে কি ডেটা মডেল রাখতে হবে?
কমপক্ষে এগুলো মডেল করুন:
User, Organization/Site
Pass (যা ব্যবহারকারী দেখে)
Credential (রিডার যা যাচাই করে)
Device (যেখানে ক্রেডেনশিয়াল স্টোর/ডিসপ্লে হয়)
আমি কোন পাস লাইফসাইকেল স্টেটগুলো সাপোর্ট করব (issue, suspend, revoke, re-issue)?
রাষ্ট্রীয়ভাবে স্টেটগুলো স্পষ্ট করুন এবং কেবল ইচ্ছাকৃত ট্রানজিশন অনুমোদন করুন:
pending → এনরোল হচ্ছে
active → ব্যবহারযোগ্য
suspended → অস্থায়ীভাবে ব্লক করা
expired → সময়সীমা শেষ
revoked → স্থায়ীভাবে অবৈধ
মোবাইল পাসের জন্য নিবন্ধন ও ইস্যু ফ্লো কেমন হওয়া উচিত?
“প্রথম ৫ মিনিট”‑এর জন্য ডিজাইন করুন:
Invite links ব্যবহার করুন যেগুলো ডিপ‑লিংক করে এনরোলমেন্টে নিয়ে যাবে
পরিচয় যাচাই করতে OTP (email/SMS) এবং/অথবা কর্মচারীর জন্য SSO ব্যবহার করুন
ভেরিফিকেশনের পরে সুস্পষ্ট Add to Wallet বা “Pass ready” স্ক্রিন দেখান
ইউজার ইমেইল না পেলে সাইটে দিয়ে ফ্যালব্যাক রাখুন
কিভাবে আমি QR স্ক্রিনশট, ক্লোনিং এবং রিপ্লে আক্রমণ প্রতিরোধ করব?
স্ট্যাটিক কোড এড়িয়ে চলুন। পছন্দযোগ্য:
রোটেটিং, স্বল্প-মেয়াদী QR টোকেন (উদাহরণ: 15–60 সেকেন্ড)
অফলাইন ভেলিডেশন বাধ্যতামূলক হলে সত্যিকারের রিয়েল-টাইম রিভোকেশন সম্ভব নয় বলে স্বীকার করুন এবং কম-মেয়াদী ভ্যালিডিটি উইন্ডো ও নিয়মিত রিডার আপডেট দিয়ে ক্ষতিটি কমান।
দরজা রিডার ও এক্সেস কন্ট্রোল সিস্টেমগুলোর সঙ্গে ইন্টিগ্রেশনের প্রধান পদ্ধতিগুলো কী?
তিনটি সাধারণ প্যাটার্ন আছে:
Reader → your API (cloud validation): রিডার প্রতিটি ট্যাপ/স্ক্যানের জন্য আপনার ভ্যালিডেশন এন্ডপয়েন্ট কল করে। নমনীয়, কিন্তু নেটওয়ার্ক‑নির্ভর।
Reader → existing ACS: আপনার অ্যাপ এমন ক্রেডেনশিয়াল ইস্যু করে যা ACS বুঝতে পারে, এবং ACS সিদ্ধান্ত নেয়। দরজায় কম কাস্টম লজিক লাগে কিন্তু ডেটা সীমাবদ্ধ হতে পারে।
Reader → local gateway (edge validation): রিডার একটি অন‑সাইট সার্ভিসকে বলে ক্রেডেনশিয়াল লোকালি ভ্যালিডেট করতে, যা ব্যাকএন্ডের সাথে সিঙ্ক করে। স্থায়িত্ব বাড়ে এবং লেটেন্সি পূর্বানুমানযোগ্য থাকে।
online validation
Reader/Door এবং Access policy
pass এবং credential আলাদা রাখলে ডিভাইস বদল বা ক্রেডেনশিয়াল রোটেশনের সময় পরিচয় বা ইতিহাস ধরে রাখা সহজ হয়।
কোন actor (user, admin, automated policy) কী ট্রিগার করতে পারে তা নির্ধারণ করুন এবং প্রতিটি পরিবর্তনactor, timestamp ও কারণসহ লগ করুন।
কিওস্ক QR
আরও: নতুন ফোনের জন্য সেলফ-সার্ভ রিইনরোলমেন্ট এবং হারানো ডিভাইসের জন্য তাৎক্ষণিক রিমোট রিভোকেশন পরিকল্পনা রাখুন।
ডিজিটাল পাস ও অ্যাক্সেস কার্ডের জন্য মোবাইল অ্যাপ কীভাবে বানাবেন | Koder.ai
