মোবাইল API-এ JSON বনাম Protobuf: পে-লোড আকার, সামঞ্জস্য ও ডিবাগিং
মোবাইল API-এ JSON vs Protobuf: পে-লোড সাইজ, সামঞ্জস্য এবং ডিবাগিং ট্রেডঅফ ব্যাখ্যা—কখন টেক্সট বা বাইনারি বেছে নেবেন সে সম্পর্কে ব্যবহারিক নিয়ম।
দস্তাবেজ-কেন্দ্রিক অ্যাপের জন্য ফাইল আপলোডে ভাইরাস স্ক্যানিং ব্যাখ্যা: কোয়ারেন্টাইন স্টোরেজ, স্ক্যানিং কিউ, অ্যাক্সেস কন্ট্রোল, রিট্রাই এবং নিরাপদ রিলিজ ওয়ার্কফ্লো।

quarantine/<tenant_id>/<upload_id> এবং clean/<tenant_id>/<document_id>, ব্যবহারকারীর দেওয়া নাম নয়। একই পথ বিভিন্ন স্টেটের জন্য পুনঃব্যবহার কখনই করবেন না।\n\nএই নিয়মগুলো মনে রাখবেন:\n\n- কোয়ারেন্টাইনে পাবলিক রিড অনুমোদন করবেন না, এমনকি অস্থায়ীও নয়।\n- সার্ভার-সাইড অবজেক্ট নাম জেনারেট করুন, ক্লায়েন্ট নাম নয়।\n- ব্লাস্ট রেডিয়াস কমাতে টেন্যান্ট বা অ্যাকাউন্ট অনুযায়ী পার্টিশন করুন।\n- মেটাডেটা (মালিক, স্ট্যাটাস, চেকসাম) ফাইলনেমে না রেখে আপনার ডাটাবেসে স্টোর করুন।\n\nরেস্টে এনক্রিপ্ট করুন, এবং কে ডিক্রিপ্ট করতে পারবে তা কঠোরভাবে নিয়ন্ত্রণ করুন। আপলোড API কোয়ারেন্টাইন-এ লিখতে পারবে, স্ক্যানার কোয়ারেন্টাইন থেকে পড়তে ও ক্লিন-এ লিখতে পারবে, এবং পাবলিক-ফেসিং অ্যাপ কেবল ক্লিন থেকে পড়বে। আপনার ক্লাউড যদি কী পলিসি সাপোর্ট করে, ডিক্রিপশন রাইট ছোট সম্ভব রোলে বেঁধে দিন।\n\nবড় ফাইল বেশি যত্ন দাবি করে। মাল্টি-পার্ট আপলোডের জন্য, চূড়ান্ত পার্ট কমিট হওয়া এবং প্রত্যাশিত সাইজ ও চেকসাম রেকর্ড করা না হলে অবজেক্টকে "রেডি" হিসেবে চিহ্নিত করবেন না। একটি সাধারণ নিরাপদ পদ্ধতি হল পার্টগুলো কোয়ারেন্টাইন-এ আপলোড করা, তারপর স্ক্যান পাস হলে অবজেক্ট কপি বা প্রোমোট করা।\n\nউদাহরণ: AppMaster দিয়ে তৈরি একটি কাস্টমার পোর্টালে প্রতিটি আপলোডকে "pending" হিসেবে ধরে, সেটি একটি কোয়ারেন্টাইন বালতিতে রাখুন, এবং ডাউনলোড বোতামটি কেবল স্ক্যান ফলাফল স্ট্যাটাস "clean" হলে দেখান।\n\n## স্থাপত্য অপশন: inline স্ক্যান বনাম ব্যাকগ্রাউন্ড স্ক্যান\n\nফাইল আপলোডে ভাইরাস স্ক্যানিং যোগ করলে সাধারণত দুইটি ফ্লো থেকে বেছে নেন: inline স্ক্যান (ব্যবহারকারী অপেক্ষা করে) অথবা ব্যাকগ্রাউন্ড স্ক্যান (অ্যাসিঙ্ক)। সঠিক পছন্দ সাধারণত নিরাপত্তার মাত্রার চেয়ে বেশি নির্ভর করে গতি, নির্ভরযোগ্যতা এবং আপলোড ফ্রিকোয়েন্সির উপর।\n\n### অপশন 1: Inline স্ক্যান (ব্যবহারকারী অপেক্ষা করে)\n\nInline স্ক্যানিং মানে আপলোড রিকোয়েস্ট শেষ হবে না যতক্ষণ না স্ক্যানার রেজাল্ট দেয়। এটি সরল মনে হয় কারণ একটি ধাপ: আপলোড, স্ক্যান, গ্রহণ বা প্রত্যাখ্যান।\n\nInline স্ক্যান সাধারণত তখন গ্রহণযোগ্য যখন ফাইল ছোট, আপলোড বিরল এবং আপনি অপেক্ষার সময় পূর্বানুমানযোগ্য রাখতে পারেন। উদাহরণস্বরূপ, এমন একটি টিম টুল যেখানে ব্যবহারকারীরা দিনে কয়েকটা PDF আপলোড করে—এখানে ৩ থেকে ১০ সেকেন্ডের দেরি মেনে নেওয়া যেতে পারে। downside: ধীর স্ক্যান অ্যাপকে ধীর করে তোলে। টাইমআউট, রিট্রাই এবং মোবাইল নেটওয়ার্ক ক্লিন ফাইলকেও খারাপ UX-এ পরিণত করতে পারে।\n\n### অপশন 2: ব্যাকগ্রাউন্ড স্ক্যান (অ্যাসিঙ্ক)\n\nঅ্যাসিঙ্ক স্ক্যানিং ফাইলটিকে প্রথমে স্টোর করে, এটিকে "quarantined" হিসেবে চিহ্নিত করে এবং একটি স্ক্যানিং কাজ কিউতে রাখে। ব্যবহারকারী দ্রুত "আপলোড গ্রহণ করা হয়েছে" রেসপন্স পায়, কিন্তু ফাইল ক্লিয়ার না হওয়া পর্যন্ত ডাউনলোড বা প্রিভিউ করা যায় না।\n\nএই পদ্ধতি উচ্চ ভলিউম, বড় ফাইল এবং ব্যস্ত সময়ের জন্য ভাল কারণ এটি কাজ ছড়িয়ে দেয় এবং আপনার অ্যাপটি রেসপন্সিভ রাখে। এটি স্ক্যানিং ওয়ার্কারদের আপনার মূল ওয়েব বা API সার্ভার থেকে আলাদা করে স্কেল করতেও দেয়।\n\nএকটি বাস্তবসম্মত হাইব্রিড হল: দ্রুত চেকগুলো inline চালান (ফাইল টাইপ allowlist, সাইজ লিমিট, বেসিক ফরম্যাট ভ্যালিডেশন), তারপর পূর্ণ অ্যান্টিভাইরাস স্ক্যান ব্যাকগ্রাউন্ডে করুন। এটি স্পষ্ট সমস্যাগুলো দ্রুত ধরবে এবং সব ব্যবহারকারীকে অপেক্ষা করাতে হবে না।\n\nনির্বাচনের একটি সহজ নিয়ম:\n\n- ছোট ফাইল, কম ভলিউম, কড়া "এখনই জানতে হবে" ওয়ার্কফ্লো: inline scan\n- বড় ফাইল, অনেক আপলোড, বা অনিশ্চিত স্ক্যান সময়: background scan\n- আপলোড রেসপন্সিভিটির কড়া SLA: background scan + স্পষ্ট স্ট্যাটাস UI\n- মিশ্র ওয়ার্কলোড: হাইব্রিড (প্রথমে দ্রুত চেক, পূর্ণ স্ক্যান অ্যাসিঙ্ক)\n\nAppMaster-এ নির্মাণ করলে এই পছন্দ সাধারণত একটি synchronous API endpoint (inline) বা একটি Business Process যা স্ক্যানিং কাজ কিউতে জমা করে ও ফলাফল আসলে ফাইল স্ট্যাটাস আপডেট করে—এখন সেইদিকেই ম্যাপ করে।\n\n## ধাপে ধাপে: একটি অ্যাসিঙ্ক স্ক্যানিং কিউ তৈরি করা\n\nঅ্যাসিঙ্ক স্ক্যানিং মানে আপনি একটি আপলোড গ্রহণ করবেন, সেটি কোয়ারেন্টাইন-এ লক করবেন, এবং পটভূমিতে স্ক্যান করবেন। ব্যবহারকারীরা স্ক্যানার নিরাপদ বলার পরই অ্যাক্সেস পাবে না। দস্তাবেজ-কেন্দ্রিক অ্যাপগুলোর জন্য এটি সাধারণত সবচেয়ে ব্যবহারিক ম্যালওয়্যার স্ক্যানিং আর্কিটেকচার।\n\n### 1) কিউ মেসেজ নির্ধারণ করুন (সেটি ছোট রাখুন)\n\nকিউকে একটি টু-ডু তালিকা হিসেবে চিন্তা করুন। প্রতিটি আপলোড একটি মেসেজ তৈরি করে যা ফাইলের পয়েন্টার দেয়, ফাইল নিজেরাই নয়।\n\nএকটি সাধারণ মেসেজে সাধারণত থাকে:\n\n- ফাইল ID (অথবা অবজেক্ট কী) এবং টেন্যান্ট বা প্রজেক্ট ID\n- আপলোড করেছে ওই ইউজারের ID\n- আপলোড টাইমস্ট্যাম্প এবং একটি চেকসাম (ঐচ্ছিক কিন্তু সহায়ক)\n- অ্যাটেম্পট নম্বর (অথবা আলাদা রিট্রাই কাউন্টার)\n\nকিউতে কাঁচা বাইট রাখা এড়িয়ে চলুন। বড় পে-লোড লিমিট ভাঙতে পারে, খরচ বাড়ায় এবং এক্সপোজার বাড়ায়।\n\n### 2) ওয়ার্কার ফ্লো তৈরি করুন (ফেচ, স্ক্যান, রেকর্ড)\n\nএকটি ওয়ার্কার মেসেজ টেনে নেয়, কোয়ারেন্টাইন স্টোরেজ থেকে ফাইল ফেচ করে, স্ক্যান চালায়, তারপর সিদ্ধান্ত লিখে।\n\nএকটি স্পষ্ট ফ্লো হলো:\n\n- কোয়ারেন্টাইন স্টোরেজ থেকে ID দিয়ে ফাইল ফেচ করুন (প্রাইভেট বালতি বা প্রাইভেট ভলিউম)\n- স্ক্যানার চালান (AV ইঞ্জিন বা স্ক্যানিং সার্ভিস)\n- ফলাফল আপনার ডাটাবেসে লিখুন: স্ট্যাটাস (clean, infected, error), স্ক্যানার নাম/ভার্সন, এবং টাইমস্ট্যাম্প\n- clean হলে: ফাইলকে অনুমোদিত স্টোরেজে সরান বা একটি অ্যাক্সেস ফ্ল্যাগ ফ্লিপ করুন যাতে এটি ডাউনলোডযোগ্য হয়\n- infected হলে: কোয়ারেন্টাইনে রাখুন (অথবা মুছে ফেলুন) এবং সংশ্লিষ্ট মানুষদের নোটিফাই করুন\n\n### 3) ইডেম্পোটেন্ট রাখুন (পুনরায় প্রক্রিয়া নিরাপদ করে)\n\nওয়ার্কার ক্র্যাশ করবে, মেসেজ দুবার ডেলিভার হবে, এবং রিট্রাই হবে। ডিজাইন এমনভাবে করুন যাতে একই ফাইলকে দুবার স্ক্যান করলেও ক্ষতি না হয়। files.status মতো একক সত্যের উত্স ব্যবহার করুন এবং শুধু বৈধ ট্রানজিশনকে অনুমোদন করুন, উদাহরণ: uploaded -> scanning -> clean/infected/error. যদি একটি ওয়ার্কার clean দেখে, তাহলে সেটি বন্ধ করে মেসেজ অ্যাকনলেজ করবে।\n\n### 4) কনকারেন্সি নিয়ন্ত্রণ করুন (স্ক্যানিং স্টর্ম এড়ান)\n\nওয়ার্কার এবং টেন্যান্ট অনুযায়ী লিমিট সেট করুন। একই সাথে কতগুলো স্ক্যান চালাতে পারবেন তা ক্যাপ করুন, এবং বড় ফাইলের জন্য আলাদা কিউ বিবেচনা করুন। এটি একটি ব্যস্ত কাস্টমারের কারণে সব স্ক্যানার ক্যাপাসিটি খেয়ে ফেলার সম্ভাবনা কমায়।\n\n### 5) ত্রুটি হ্যান্ডেলিং: রিট্রাই ও অডিট ট্রেইল\n\nটেম্পোরারি ত্রুটিগুলোর জন্য রিট্রাই ব্যবহার করুন (স্ক্যানার টাইমআউট, নেটওয়ার্ক সমস্যা) ছোট সর্বোচ্চ অ্যাটেম্পট সহ। এর পরে ম্যানুয়াল রিভিউয়ের জন্য মেসেজ ডেড-লেটার কিউতে পাঠান।\n\nঅডিট ট্রেইল রাখুন: কে ডকুমেন্ট আপলোড করেছে, কবে কোয়ারেন্টাইন এ ঢুকেছে, কোন স্ক্যানার চালানো হয়েছে, কি সিদ্ধান্ত হয়েছে, এবং কে অনুমোদন বা মুছে ফেলেছে—এসব লগ ভাইরাস স্ক্যানিং-এর চাইতেও গুরুত্বপুর্ণ, বিশেষ করে কাস্টমার পোর্টাল ও কমপ্লায়েন্সের জন্য।\n\n## অ্যাক্সেস কন্ট্রোল: কোয়ারেন্টাইন করা ফাইলগুলো সত্যিকারের প্রাইভেট রাখুন\n\nকোয়ারেন্টাইন শুধুমাত্র ডাটাবেসে একটি স্ট্যাটাস নয়। এটি একটি প্রতিশ্রুতি যে ফাইল প্রমাণ না হওয়া পর্যন্ত কেউ খুলবে না। সবচেয়ে নিরাপদ নিয়ম সহজ: কোয়ারেন্টাইন করা ফাইল কখনও পাবলিক URL-এ সার্ভ করবেন না, এমনকি অস্থায়ী হলেও।\n\nএকটি ভালো ডাউনলোড ফ্লো বোরিংভাবে কঠোর হওয়া উচিত। অ্যাপকে প্রতিটি ডাউনলোডকে একটি প্রোটেক্টেড অ্যাকশন হিসেবে দেখতে হবে, ইমেজ ফেচ করার মতো নয়।\n\nএকটি ভালো ডাউনলোড ফ্লো:\n\n1) ডাউনলোড রিকোয়েস্ট\n2) নির্দিষ্ট ফাইলটির উপর ইউজারের পারমিশন চেক\n3) ফাইলের স্ট্যাটাস চেক করুন (quarantined, clean, rejected)\n4) স্ট্যাটাস clean হলে কেবল ফাইল ডেলিভার করুন\n\nআপনি যদি সাইনড URL ব্যবহার করেন, ধারণাটা একই রাখুন: পারমিশন ও স্ট্যাটাস চেকের পরে কেবল সেগুলো জেনারেট করুন এবং অল্প সময়ের জন্যই সক্রিয় রাখুন। লিংক লিক হলে ক্ষতি কমাতে শর্ট এক্সপায়ারি দরকার।\n\nরোল-বেসড অ্যাক্সেস স্পেশাল-কেস লজিককে রোধ করে। দস্তাবেজ-কেন্দ্রিক অ্যাপগুলোর জন্য সাধারণ রোলগুলো হল:\n\n- Uploader: তাদের নিজস্ব আপলোড ও স্ক্যান স্ট্যাটাস দেখতে পারে\n- Reviewer: clean ফাইল দেখতে পারে, এবং নিরাপদ রিভিউ টুলে কোয়ারেন্টাইন ফাইল দেখতে পারে (শর্তসাপেক্ষ)\n- Admin: তদন্ত, পুনঃস্ক্যান এবং ওভাররাইড করতে পারে যখন প্রয়োজন\n- External user: কেবল সেই ডকুমেন্টগুলো অ্যাক্সেস করতে পারে যা স্পষ্টভাবে শেয়ার করা হয়েছে\n\nID অনুমান থেকেও সুরক্ষিত রাখুন। ইনক্রিমেন্টাল ফাইল ID (যেমন 12345) যেন প্রকাশ করা না হয়। অপাকে ID ব্যবহার করুন এবং প্রতি ইউজার ও প্রতিটি ফাইলে অথরাইজেশন চেক করান (শুধু "লগইন করা" ইউজার নয়)। এমনকি যদি আপনার স্টোরেজ বালতি প্রাইভেট হয়, একটি carelessness API এন্ডপয়েন্ট কোয়ারেন্টাইন কন্টেন্ট লিক করতে পারে।\n\nফাইল আপলোডের ভাইরাস স্ক্যানিং বানালে, অ্যাক্সেস লেয়ারই বাস্তব জগতের বেশির ভাগ ব্যর্থতার কারণ হয়। AppMaster-এর মত প্ল্যাটফর্মে আপনি এই চেকগুলো API এন্ডপয়েন্ট ও বিজনেস লজিকে প্রয়োগ করবেন যাতে কোয়ারেন্টাইন ডিফল্টভিত্তিতে প্রাইভেট থাকে।\n\n## রিলিজ, প্রত্যাখ্যান ও রিট্রাই: স্ক্যান ফলাফলের হ্যান্ডলিং\n\nএকবার ফাইল স্ক্যান শেষ হলে, সবচেয়ে গুরুত্বপূর্ণ কাজ হল এটিকে একটি স্পষ্ট স্টেটে নিয়ে আসা এবং পরবর্তী ধাপকে পূর্বানুমানযোগ্য করা। ফাইল আপলোডের ভাইরাস স্ক্যানিং তৈরি করলে স্ক্যান ফলাফলকে একটি গেট হিসেবে বিবেচনা করুন: গেট না খুললে কিছুই ডাউনলোডযোগ্য হবে না।\n\nএকটি সাধারণ আউটকাম সেট বেশিরভাগ সিস্টেমকে কভার করে:\n\n- Clean: কোয়ারেন্টাইন থেকে রিলিজ করুন এবং সাধারণ অ্যাক্সেস অনুমোদন করুন।\n- Infected: স্থায়ীভাবে অ্যাক্সেস ব্লক করুন এবং ইনফেক্টেড-ফাইল ওয়ার্কফ্লো চালু করুন।\n- Unsupported: স্ক্যানার এই টাইপ মূল্যায়ন করতে পারে না (অথবা পাসওয়ার্ড-পুত অ্যাচাইভ)। ব্লক করে রাখুন।\n- Scan error: অস্থায়ী ব্যর্থতা (টাইমআউট, সার্ভিস অনআউট)। ব্লক করে রাখুন।\n\nইউজার মেসেজিং স্পষ্ট ও শান্ত হওয়া উচিত। "Your account is compromised"-জাতীয় আতঙ্কজনক ভাষা এড়ান। একটি ভালো পদ্ধতি: "ফাইলটি পরীক্ষা করা হচ্ছে। আপনি কাজ চালিয়ে যেতে পারেন।" যদি ফাইল ব্লক করা হয়, বলুন ব্যবহারকারী পরবর্তী কী করতে পারে: "বিকল্প ফাইল টাইপ আপলোড করুন" অথবা "পরে আবার চেষ্টা করুন"। Unsupported ফাইলগুলোর জন্য স্পেসিফিক বর্ণনা দিন (উদাহরণ: "এনক্রিপ্টেড আর্কাইভ স্ক্যান করা যায় না")।\n\nInfected ফাইলের জন্য সিদ্ধান্ত নিন আপনি মুছবেন নাকি রাখবেন। মুছে ফেলা সহজ এবং ঝুঁকি কমায়। রাখলে অডিটে সহায়ক হতে পারে, তবে কেবল যদি আপনি সেটি একটি আলাদা, কঠোরভাবে অ্যাক্সেস-কন্ট্রোল করা এলাকায় সংরক্ষণ করেন এবং সংক্ষিপ্ত রিটেনশন রাখেন—এবং লগ করুন কে তা দেখতে পেল (আদর্শভাবে কেউই নয়, শুধুমাত্র সিকিউরিটি অ্যাডমিন)।\n\nরিট্রাইগুলি উপকারী, তবে শুধুমাত্র অস্থায়ী ত্রুটির জন্য। সীমিত রিট্রাই নীতি রাখুন যাতে অনন্ত ব্যাকলগ না তৈরি হয়:\n\n- টাইমআউট ও স্ক্যানার ডাউনটাইমে রিট্রাই করুন।\n- "Infected" বা "Unsupported"-এ রিট্রাই করবেন না।\n- রিট্রাই সীমা নির্ধারণ করুন (উদাহরণ: 3) এবং তার পর failed চিহ্নিত করুন।\n- অনুভূমিক ওভারলোড এড়াতে ব্যাকঅফ ব্যবহার করুন।\n\nপরিশেষে, পুনরাবৃত্ত ব্যর্থতাগুলোকে ইউজারের সমস্যা না ভেবে অপস সমস্যা হিসেবে দেখুন। যদি অনেক ফাইল একই সময়ে "scan error" পায়, টীমকে অ্যালার্ট করুন এবং নতুন রিলিজ সাময়িকভাবে থামান। AppMaster-এ আপনি ডাটাবেসে এই স্টেটগুলো মডেল করে বিল্ট-ইন মেসেজিং মডিউল দিয়ে নোটিফিকেশন রুট করতে পারেন যাতে সঠিক মানুষগুলো দ্রুত এসব সম্পর্কে জানতে পারে।\n\n## উদাহরণ পরিস্থিতি: প্রচুর ডকুমেন্ট থাকাওয়ালা কাস্টমার পোর্টাল\nএকটি কাস্টমার পোর্টাল ক্লায়েন্টদের প্রজেক্টভিত্তিক ইনভয়েস এবং কনট্রাক্ট আপলোড করার সুযোগ দেয়। এখানে ফাইল আপলোডের ভাইরাস স্ক্যানিং গুরুত্বপূর্ণ, কারণ ব্যবহারকারীরা ডেস্কটপ থেকে যা আছে তা ড্র্যাগ করে আনবে, এমনকি অন্য কারো পাঠানো ফাইলও।\n\nযখন একটি গ্রাহক PDF আপলোড করে, পোর্টালটি এটিকে একটি অস্থায়ী, প্রাইভেট লোকেশনে সংরক্ষণ করে এবং ডাটাবেস রেকর্ড তৈরি করে স্ট্যাটাস Pending scan। ফাইলটি এখনও ডাউনলোডযোগ্য দেখানো হয় না। একটি স্ক্যানিং ওয়ার্কার কিউ থেকে ফাইল টেনে নিয়ে স্ক্যান চালায়, তারপর রেকর্ড আপডেট করে Clean বা Blocked।\n\nUI-তে গ্রাহক ডকুমেন্টটি সঙ্গে সঙ্গে দেখতে পায়, কিন্তু সাফভাবে Pending ব্যাজ সহ। ফাইলনাম ও সাইজ দেখা যায় যাতে তারা জানে আপলোড হয়েছে, কিন্তু Download বাটন স্ক্যান ক্লিন না হওয়া পর্যন্ত ডিসেবল থাকে। যদি স্ক্যান প্রত্যাশার তুলনায় বেশি সময় নেয়, পোর্টালটি সহজ বার্তা দেখাতে পারে: "আমরা এই ফাইলটি নিরাপদ কিনা পরীক্ষা করছি। এক মিনিট পরে আবার চেষ্টা করুন।"\n\nযদি স্ক্যানার কোনো ডকুমেন্ট ফ্ল্যাগ করে, গ্রাহক Blocked দেখে একটি সংক্ষিপ্ত, অ-টেকনিক্যাল নোট: "এই ফাইলটি একটি সিকিউরিটি চেকে ব্যর্থ হয়েছে।" সাপোর্ট ও অ্যাডমিনদের আলাদা ভিউ থাকবে যেখানে স্ক্যান কারণ ও পরবর্তী পদক্ষেপ দেখাবে। তারা পারে:\n\n- সেটি ব্লক করে রাখা এবং নতুন আপলোডের অনুরোধ করা\n- মুছে ফেলা এবং কারণ রেকর্ড করা\n- নীতিমতো অনুমোদন থাকলে ফলস পজিটিভ হিসেবে মার্ক করা\n\nবিতর্কের সময় ("আমি গতকাল আপলোড করেছি এবং আপনি সেটা হারিয়েছেন") ভাল লগ গুরুত্বপূর্ণ। আপলোড গ্রহণ, স্ক্যান শুরু, স্ক্যান শেষ, স্ট্যাটাস পরিবর্তন এবং কে কি করেছে—এসবের টাইমস্ট্যাম্প রাখুন। এছাড়া ফাইল হ্যাশ, মূল ফাইলনাম, আপলোডকারী অ্যাকাউন্ট, IP ঠিকানা এবং স্ক্যানার রেজাল্ট কোড সঞ্চয় করুন। AppMaster-এ এটি ডেটা ডিজাইনারে মডেল করে এবং একটি সিম্পল বিজনেস প্রসেস ফ্লো দিয়ে পরিচালনা করা যায় যাতে কোয়ারেন্টাইন ফাইল নিয়মিত ব্যবহারকারীদের জন্য প্রকাশ না হয়।\n\n## সাধারণ ভুলগুলো যা বাস্তব নিরাপত্তা গ্যাপ সৃষ্টি করে\n\nবেশিরভাগ আপলোড নিরাপত্তা ব্যর্থতা চতুর কৌশল নয়—এগুলো ছোট ডিজাইন সিদ্ধান্ত যা দুর্ঘটনাক্রমে একটি অনিরাপদ ফাইলকে নরমাল ডকুমেন্টের মতো ব্যবহার করতে দেয়।\n\nএকটি ক্লাসিক সমস্যা হল রেস কন্ডিশন: অ্যাপ আপলোড গ্রহণ করে, একটি "ডাউনলোড" URL দেয়, এবং ব্যবহারকারী (অথবা অন্য সার্ভিস) স্ক্যান শেষ হওয়ার আগেই ফাইলটি ফেচ করতে পারে। ফাইল আপলোডের ভাইরাস স্ক্যানিং করলে "uploaded" এবং "available"-কে দুইটি আলাদা স্টেট হিসেবে বিবেচনা করুন।\n\nবারবার দেখা যায় এমন ভুলগুলো:\n\n- একই বালতি/ফোল্ডারে clean ও quarantined ফাইল মিশানো এবং তারপর নামকরণ নিয়মে নির্ভর করা। একটি ভুল অনুমতি বা পথ অনুমান করলে কোয়ারেন্টাইন অর্থহীন হয়ে পড়ে।\n- ফাইল এক্সটেনশন, MIME টাইপ বা ক্লায়েন্ট-সাইড চেক বিশ্বাস করা। আক্রমণকারী .pdf করে যে কোনো ফাইল নাম দিতে পারে এবং UI উপেক্ষা করবে।\n- স্ক্যানার ডাউনটাইমের জন্য পরিকল্পনা না করা। যদি স্ক্যানার ধীর বা অফলাইন হয়, ফাইলগুলো অনন্তকাল pending-এ থাকতে পারে এবং টিমগুলো অনিরাপদ ম্যানুয়াল ওভাররাইড যোগ করে ফেলতে পারে।\n\n- ব্যাকগ্রাউন্ড ওয়ার্কারগুলো যদি মূল API-এর মতো অথরাইজেশন রুলগুলো স্কিপ করে, তাহলে সেটি নীরবভাবে অধিকারের উত্থাপন করে। একটি ওয়ার্কার যা "যেকোন ফাইল" পড়তে পারে—সেটি বিপজ্জনক।\n\n- কোয়ারেন্টাইন আইটেমের জন্য সহজে অনুমানযোগ্য (ইনক্রিমেন্টাল) ID প্রকাশ করা, এমনকি আপনি ভাবেন কন্টেন্ট সুরক্ষিত আছে।\n\nটেস্ট করাও আরেকটি গ্যাপ। টিমগুলো কয়েকটি ছোট, পরিচ্ছন্ন ফাইল দিয়ে টেস্ট করে শেষ বলে দেয়। আপনাকে বড় আপলোড, করাপ্টেড ফাইল, এবং পাসওয়ার্ড-পুথকৃত ডকুমেন্টও পরীক্ষা করতে হবে—কারণ ঠিক এসব জায়গায় স্ক্যানার ও পার্সার ব্যর্থ বা টাইমআউট হয়।\n\nএকটি বাস্তব উদাহরণ: একজন ব্যবহারকারী "contract.pdf" নামে একটি ফাইল আপলোড করে যা আসলে একটি আর্কাইভের ভিতরে রিনেম করা executable। যদি আপনার পোর্টাল তা সাথে-সাথে সার্ভ করে বা সাপোর্ট টিম কোয়ারেন্টাইন অ্যাক্সেস করে কোনো সঠিক চেক ছাড়া, আপনি সরাসরি অন্য ব্যবহারকারীদের কাছে ক্ষতিকর ডেলিভারি তৈরি করেছেন।\n\n## শিপ করার আগে দ্রুত চেকলিস্ট\n\nফাইল আপলোডের ভাইরাস স্ক্যানিং চালু করার আগে সেই জায়গাগুলো একটি চূড়ান্তবার চেক করুন যেখানে টিমগুলো প্রায়ই "ঠিক আছে" ধরে নেয় এবং পরে সমস্যা হয়। লক্ষ্য সহজ: কোনো অনিরাপদ ফাইলই কোনওভাবে পড়ার যোগ্য হয়ে ওঠা উচিত না শুধু কেউ URL অনুমান করে, রিকোয়েস্ট রি-ট্রাই করে, বা পুরনো ক্যাশড লিংক ব্যবহার করে।\n\nইউজার ফ্লো দিয়ে শুরু করুন। যে কোনো ডাউনলোড, প্রিভিউ বা "ফাইল খুলুন" অ্যাকশনটি রিকোয়েস্ট টাইমে ফাইলের বর্তমান স্ক্যান স্ট্যাটাস পুনরায় চেক করবে—শুধু আপলোড টাইমে নয়। এটি রেস কন্ডিশন, দেরি স্ক্যান ফলাফল, এবং রি-স্ক্যান হওয়া ফাইলের এজ-কেস থেকে আপনাকে রক্ষা করে।\n\nএই প্রি-শিপ চেকলিস্টটি ন্যূনতম বেসলাইন হিসেবে ব্যবহার করুন:\n\n- কোয়ারেন্টাইন স্টোরেজ ডিফল্টভাবে প্রাইভেট: কোন পাবলিক বালতি অ্যাক্সেস নেই, "কেউ লিংক পেলে" নেই, এবং কাঁচা অবজেক্ট স্টোরেজ থেকে সরাসরি সার্ভ করা নেই।\n- প্রতিটি ফাইল রেকর্ডে একটি মালিক (ইউজার, টিম বা টেন্যান্ট) এবং একটি স্পষ্ট লাইফসাইকেল স্টেট আছে: pending, clean, infected, বা failed।\n- আপনার স্ক্যানিং কিউ ও ওয়ার্কারদের সীমিত রিট্রাই, স্পষ্ট ব্যাকঅফ নিয়ম এবং আইটেম স্টাক হওয়ার ক্ষেত্রে অ্যালার্ট আছে।\n- আপলোড, স্ক্যান রেজাল্ট এবং ডাউনলোড চেষ্টা (ব্লক করা চেষ্টাসহ)-এর অডিট লগ আছে: কে, কখন, কেন।\n- দুর্লভ ক্ষেত্রে ম্যানুয়াল ওভাররাইড আছে, কিন্তু তা কেবল অ্যাডমিন-নুন, রেকর্ড করা এবং সময়সীমা সংবলিত (নো সাইলেন্ট "mark clean" বোতাম)।\n\nশেষে, সিস্টেমটি end-to-end পর্যবেক্ষণ করা যাচ্ছে কি না নিশ্চিত করুন। আপনাকে উত্তর দিতে সক্ষম থাকতে হবে: "এখন কতটি ফাইল pending scan-এ আছে?" এবং "কোন টেন্যান্টগুলো ব্যর্থতা দেখছে?" যদি আপনি AppMaster-এ নির্মাণ করেন, ডেটা ডিজাইনারে ফাইল লাইফসাইকেল মডেল করুন এবং বিজনেস প্রসেস এডিটরে স্টেট চেক বাধ্যতামূলক করুন যাতে নিয়মগুলো ওয়েব ও মোবাইল উভয় জায়গায় কনসিস্টেন্ট থাকে।\n\n## পরবর্তী ধাপ: ডিজাইনকে কার্যকর অ্যাপে বদলানো\n\nপ্রথমে আপনার ফাইলগুলো কোন স্টেটে থাকতে পারে তা লিখে নিন, এবং প্রতিটি স্টেট কী অনুমোদন করে তা নির্ধারণ করুন। সহজ ও স্পষ্ট রাখুন: "uploaded", "queued", "scanning", "clean", "infected", "scan_failed"। এরপর প্রতিটি স্টেটের পাশে অ্যাক্সেস নিয়ম যুক্ত করুন—কে ফাইলটি দেখতে, ডাউনলোড করতে বা মুছতে পারে যখন সেটি এখনও আনট্রাস্টেড।\n\nপরের ধাপে আপনার ভলিউম ও ইউজার এক্সপেরিয়েন্স লক্ষ করুন এবং তাই অনুযায়ী পদ্ধতি নির্বাচন করুন। Inline স্ক্যান ব্যাখ্যা করা সহজ, কিন্তু এটি আপলোড ধীর করে। Async স্ক্যান ডকুমেন্ট-কেন্দ্রিক অ্যাপগুলোর জন্য ভালো স্কেল করে, কিন্তু এটি স্টেট, কিউ এবং "pending" UI যোগ করে।\n\nডিজাইন থেকে বিল্ডে যাওয়ার একটি বাস্তবসম্মত উপায় হলো পুরো ফ্লোটির এন্ড-টু-এন্ড প্রোটোটাইপ বানানো বাস্তব ডকুমেন্ট (PDF, Office ফাইল, ইমেজ, আর্কাইভ) আর বাস্তব ব্যবহারকারীর আচরণ (একাধিক আপলোড, ক্যানসেল, রিট্রাই) ব্যবহার করে। শুধু "স্ক্যানার কাজ করে" বলে থামবেন না—ভ্যালিডেট করুন অ্যাপটি অসদৃশ ফাইল কোনভাবেই সার্ভ করে না, এমনকি দুর্ঘটনাক্রমে।\n\nএক সপ্তাহে বাস্তবায়নযোগ্য একটি সরল বিল্ড প্ল্যানঃ\n\n- এক পাতায় ফাইল স্টেট, ট্রানজিশন এবং অ্যাক্সেস রুল সংজ্ঞায়িত করুন\n- inline, async, বা hybrid পছন্দ করে ট্রেডঅফ ডকুমেন্ট করুন\n- আপলোড -> quarantine storage -> scan job -> result callback ইমপ্লিমেন্ট করুন, অডিট লগসহ\n- ইউজারদের দেখা স্টেটগুলো (pending, blocked, failed, approved) UI-তে বানান\n- প্রথমদিন থেকেই মনিটরিং যোগ করুন: ব্যাকলগ সাইজ, ব্যর্থতার হার, এবং time-to-clean\n\nনো-কোড ছাড়া নির্মাণ করলে AppMaster সাহায্য করতে পারে: ফাইল মেটাডেটা (status, owner, checksum, timestamps) মডেল করা, আপলোড ও রিভিউ স্ক্রিন বানানো, এবং স্ক্যান ওয়ার্কফ্লো অর্কেস্ট্রেট করা—এতে আপনি বাস্তব প্রোডাক্ট ফ্লো শুরুর আগে টেস্ট করতে পারবেন এবং পরে পারমিশন, স্টোরেজ আলাদা করা ও নির্ভরযোগ্য রিট্রাই কাঠামো মজবুত করবেন।\n\nসবশেষে, সংখ্যায় নির্ধারণ করুন "ভাল" কী: লঞ্চের আগে সতর্কতা থ্রেশহোল্ড সেট করুন যাতে স্টাক হওয়া স্ক্যান এবং বাড়তে থাকা ব্যর্থতা ব্যবহারকারীদের আগে আপনাকে সতর্ক করে।বিনামূল্যের পরিকল্পনা সহ অ্যাপমাস্টারের সাথে পরীক্ষা করুন।
আপনি যখন প্রস্তুত হবেন তখন আপনি সঠিক সদস্যতা বেছে নিতে পারেন৷