مسح الفيروسات لملفات الرفع: خيارات البنية للتطبيقات

المشكلة ببساطة: ملفات غير آمنة تدخل تطبيقك

إذا كان تطبيقك يسمح للمستخدمين برفع مستندات، فأنت تقبل ملفات لم تقم بإنشائها بنفسك. في المنتجات الثقيلة بالمستندات (بوابات العملاء، نظم الموارد البشرية، تطبيقات المطالبات، استقبال بائعيين)، تكون عمليات الرفع متكررة، وغالبًا ما يشارك المستخدمون ملفات مأخوذة من رسائل البريد أو محركات المشاركة أو أطراف ثالثة. هذا يجعل هذه التطبيقات هدفًا عمليًا: رفع واحد ناجح يمكن أن ينتشر عبر العديد من التنزيلات.

المخاطر ليست مجرد "فيروس". يمكن لملف Word أو Excel أن يحمل ماكروز خبيثة، ويمكن أن يتم تصميم ملف PDF لاستغلال ثغرات قارئ المستندات، و"فاتورة" قد تكون مستند تصيد يخدع شخصًا للاتصال برقم مزيف أو إدخال بيانات. بعض الملفات مسمومة بطرق أخف: إخفاء حمولة داخل ZIP، استخدام امتدادات مزدوجة (report.pdf.exe)، أو تضمين محتوى بعيد يتصل بخادم خارجي عند الفتح.

الاعتماد على مضاد فيروسات بسيط مثبت على خادم واحد ليس كافيًا. قد تمر التحميلات عبر مثيلات تطبيق متعددة، أو تنتقل بين أنظمة التخزين، أو يتم تقديمها من تخزين كائنات أو CDN. إذا انكسر أي مسار برمجي وعرض التحميل الخام بطريق الخطأ، يمكن للمستخدمين تنزيله قبل اكتمال الفحص. التحديثات، وسوء التهيئة، وصلاحيات المدير المؤقتة يمكن أيضًا أن تتجاوز الفحص مع مرور الوقت.

الهدف الواضح لمسح الفيروسات لرفع الملفات بسيط: لا يجوز أن يكون أي ملف غير مفحوص قابلاً للتنزيل أو العرض من قبل أي شخص غير مصرح له بوضوح بمراجعة المحتوى المحجوز.

عرف ما يعنيه "آمن" كقاعدة عمل، لا كإحساس. على سبيل المثال:

• يجب أن يجتاز فحص البرامج الخبيثة مع مجموعة توقيعات حديثة
• يجب أن يطابق أنواع الملفات المسموح بها وحدود الحجم
• يجب أن يُخزن ويُقدَّم فقط من أماكن معتمدة
• يجب أن يحتوي على أثر تدقيقي: من رفعه، ومتى، والحالة النهائية
• يجب أن يُحجب حتى قرار نهائي: إصدار أو رفض

إذا بنيت على منصة مثل AppMaster، اعتبر "حالة الفحص" حقلًا أساسيًا في نموذج البيانات واجعل كل إجراء تنزيل يتحقق منه. هذه البوابة الواحدة تمنع الكثير من الأخطاء المكلفة.

ماذا يعني الحجر الصحي للمستندات المرفوعة فعلًا

يمكن التفكير في "الحجر الصحي" كحالة في نظامك، وليس مجرد مجلد في التخزين. الفكرة الأساسية بسيطة: الملف موجود، لكن لا يمكن لأحد فتحه أو تنزيله حتى يكون هناك نتيجة فحص واضحة ومسجلة. هذا هو جوهر مسح الفيروسات لرفع الملفات.

عادةً يعمل الحجر الصحي كدورة حياة صغيرة بحالات واضحة. إبقاء الحالة صريحة يجعل من الصعب تسريب محتوى غير آمن عن طريق معاينة، أو رابط مباشر، أو مهمة تصدير.

مجموعة عملية من حالات الملفات تبدو هكذا:

• received (اكتمل الرفع، لم يُفحص بعد)
• scanning (اختاره عامل الفحص)
• clean (آمن للإصدار)
• rejected (تم العثور على برامج خبيثة أو انتهاك للسياسة)
• failed (خطأ في الماسح، مهلة، أو ملف تالف)

الحجر الصحي يحتاج أيضًا إلى البيانات الوصفية المناسبة حتى تتمكن من فرض الوصول وتدقيق ما حدث لاحقًا. على الأقل، احفظ: المالك (مستخدم أو منظمة)، الحالة، اسم الملف الأصلي ونوعه، checksum (للتكرار وفحص العبث)، موقع التخزين، والطوابع الزمنية (تم الرفع، بداية الفحص، نهاية الفحص). العديد من الفرق تحفظ أيضًا إصدار الماسح وتفاصيل حكم الفحص.

الاحتفاظ بالملفات قرار سياساتي، ولكن يجب أن يكون مقصودًا. احتفظ بالملفات المحجوزة فقط طالما تحتاجها لمسحها وتصحيح الأخطاء. تقليل فترة الاحتفاظ يخفض المخاطر والتكلفة، لكنك لا تزال تريد وقتًا كافيًا للتحقيق في الحوادث ودعم المستخدمين الذين يسألون "أين اختفى رفعّي؟"

أخيرًا، قرّر ماذا تفعل بالملفات التي لا تنتهي عملية فحصها أبدًا. حدد وقتًا أقصى للفحص وطابعًا زمنيًا "لانتهاء الصلاحية". عندما يمر الموعد النهائي، حرك الملف إلى failed، احظر الوصول، ثم إما أعد المحاولة تلقائيًا بعدد محدود من المرات أو احذفه واطلب من المستخدم إعادة الرفع.

أنماط التخزين المؤقت التي تقلل المخاطر

يحدث معظم مشاكل الرفع في التخزين المؤقت. الملف في نظامك، لكنك لا تعرف بعد إن كان آمنًا، لذا تحتاج إلى مكان يسهل قفله ويصعب كشفه بطريق الخطأ.

يمكن أن يعمل القرص المحلي لحالة خادم واحد، لكنه هش. عند التوسع إلى خوادم تطبيق متعددة، ستحتاج لمشاركة التخزين، ونسخ الملفات، والحفاظ على صلاحيات متسقة. غالبًا ما يكون تخزين الكائنات (مثل دلو بنمط S3 أو حاوية سحابية) أكثر أمانًا لتطبيقات المقالات بالوثائق لأن قواعد الوصول مركزية والسجلات أوضح.

نمط بسيط لمسح الفيروسات لرفع الملفات هو فصل "الحجر الصحي" عن التخزين "النظيف". يمكنك فعل هذا باستخدام دلوتين/حاويتين، مما يجعل الأخطاء أقل احتمالًا، أو باستخدام بنية بادئة صارمة داخل دلو واحد، والتي قد تكون أرخص وأسهل في الإدارة.

إذا استخدمت البادئات، اجعلها مستحيلة الخلط. فضّل تخطيطًا مثل quarantine/\u003ctenant_id\u003e/\u003cupload_id\u003e و clean/\u003ctenant_id\u003e/\u003cdocument_id\u003e، وليس أسماء من تقديم المستخدم. لا تعيد استخدام نفس المسار لحالات مختلفة.

احتفظ بهذه القواعد في ذهنك:

• لا تسمح بالقراءة العامة على الحجر الصحي، حتى "مؤقتًا".
• أنشئ أسماء الكائنات من جهة الخادم، لا من جهة العميل.
• قسّم بحسب المستأجر أو الحساب لتقليل مساحة الانفجار.
• خزن البيانات الوصفية (المالك، الحالة، checksum) في قاعدة بياناتك، لا في اسم الملف.

شفر الملفات في حالة الراحة، وكن صارمًا بشأن من يمكنه فك التشفير. يجب أن يكون لدى واجهة رفع الملفات الحق في الكتابة إلى الحجر الصحي، ويجب أن يكون لدى الماسح الحق في القراءة من الحجر الصحي والكتابة إلى النظيف، ويجب أن يقرأ التطبيق العلني فقط من النظيف. إذا دعمت السحابة سياسات المفاتيح، اربط حقوق فك التشفير بأصغر مجموعة ممكنة من الأدوار.

الملفات الكبيرة تحتاج عناية إضافية. بالنسبة للرفع المتعدد الأجزاء، لا تجعل الكائن "جاهزًا" حتى يتم الالتزام بالجزء النهائي وتسجل الحجم المتوقع وchecksum. نهج آمن شائع هو رفع الأجزاء إلى الحجر الصحي، ثم نسخ أو ترقية الكائن إلى النظيف فقط بعد اجتياز الفحص.

مثال: في بوابة عملاء مبنية بـ AppMaster، يمكنك معاملة كل رفع كـ "قيد الانتظار"، تخزينه في دلو حجر صحي، وإظهار زر التنزيل فقط بعد أن تقلب نتيجة الفحص الحالة إلى "clean".

خيارات البنية: الفحص المتزامن مقابل الفحص في الخلفية

عند إضافة مسح الفيروسات لرفع الملفات، عادةً تختار بين مسارين: الفحص المتزامن (ينتظر المستخدم) أو الفحص في الخلفية (يقبل التطبيق الرفع لكن يحجب الوصول حتى يتم التصريح). الاختيار الصحيح يعتمد أقل على "مستوى الأمان" (كلاهما يمكن أن يكونا آمنين) وأكثر على السرعة والموثوقية وتواتر الرفع.

الخيار 1: الفحص المتزامن (ينتظر المستخدم)

يعني الفحص المتزامن أن طلب الرفع لا ينتهي حتى يُرجع الماسح نتيجة. يبدو بسيطًا لأنه خطوة واحدة: ارفع، افحص، قبول أو رفض.

الفحص المتزامن مقبول عادة عندما تكون الملفات صغيرة، والرفع نادر، ويمكنك الحفاظ على زمن انتظار متوقع. مثلاً، أداة داخل فريق حيث يرفع المستخدمون بضعة ملفات PDF يوميًا قد تتحمل توقفًا من 3 إلى 10 ثوانٍ. الجانب السلبي هو أن فحصًا بطيئًا يجعل التطبيق بطيئًا. المهلات، وإعادة المحاولة، وشبكات المحمول يمكن أن يحولوا ملفًا نظيفًا إلى تجربة سيئة.

الخيار 2: الفحص في الخلفية (غير متزامن)

التخزين غير المتزامن يخزن الملف أولًا، يعلّمه كـ "محجوز"، ويدفع وظيفة إلى طابور الفحص. يحصل المستخدم على استجابة سريعة "تم استلام الرفع"، لكنه لا يمكنه تنزيل الملف أو معاينته حتى يتم تطهيره.

هذا النهج أفضل للحجم الكبير، والملفات الأكبر، وساعات الذروة لأنه يوزع العمل ويحافظ على استجابة التطبيق. كما يتيح لك توسيع عمال الفحص بشكل منفصل عن خوادم الويب أو API الأساسية.

هجينة عملية هي: إجراء فحوصات سريعة داخل الطلب (قائمة سماح أنواع الملفات، حدود الحجم، التحقق الأساسي من الصيغة)، ثم إجراء الفحص الكامل لمكافحة الفيروسات في الخلفية. هذا يلتقط المشكلات الواضحة مبكرًا دون جعل كل مستخدم ينتظر.

إليك طريقة بسيطة للاختيار:

• ملفات صغيرة، حجم منخفض، سير عمل "ضروري معرفة النتيجة الآن": فحص متزامن
• ملفات كبيرة، الكثير من الرفع، أو زمن فحص غير متوقع: فحص في الخلفية
• اتفاقيات مستوى خدمة صارمة لاستجابة الرفع: فحص في الخلفية مع واجهة حالة واضحة
• أحمال مختلطة: هجينة (فحوصات سريعة أولًا، فحص كامل لاحقًا)

إذا بنيت باستخدام AppMaster، غالبًا ما يُطابق هذا الاختيار إما نقطة نهاية API متزامنة (متزامن) أو عملية أعمال تُدخل مهمة فحص في قائمة وتحدث حالة الملف عند وصول النتائج.

خطوة بخطوة: بناء طابور فحص غير متزامن

الفحص غير المتزامن يعني أنك تقبل الرفع، تقفل الملف في الحجر الصحي، وتفحصه في الخلفية. لا يحصل المستخدمون على الوصول حتى يقول الماسح إن الملف آمن. هذا عادةً أكثر العمارة عملية لتطبيقات المحملة بالمستندات.

1) عرّف رسالة الطابور (اجعلها صغيرة)

عامل الطابور كقائمة مهام. كل رفع ينشئ رسالة واحدة تشير إلى الملف، لا الملف نفسه.

رسالة بسيطة عادةً تتضمن:

• معرف الملف (أو مفتاح الكائن) ومعرف المستأجر أو المشروع
• معرف المستخدم الذي رفع
• طابع زمني للرفع وchecksum (اختياري لكن مفيد)
• رقم المحاولة (أو عداد إعادة محاولة منفصل)

تجنّب وضع البايت الخام في الطابور. الحمولة الكبيرة يمكن أن تكسر الحدود، تكلف أكثر، وتزيد التعرض.

2) ابنِ تدفق العامل (جلب، فحص، تسجيل)

يسحب العامل رسالة، يجلب الملف من تخزين الحجر الصحي، يفحصه، ثم يكتب قرارًا.

تدفق واضح هو:

• جلب الملف بالمعرف من تخزين الحجر الصحي (دلو خاص أو وحدة خاصة)
• تشغيل الماسح (محرك AV أو خدمة فحص)
• كتابة النتيجة إلى قاعدة بياناتك: الحالة (clean, infected, error)، اسم/إصدار الماسح، والطوابع الزمنية
• عند النظافة: انقل الملف إلى التخزين الموافق أو قلب علامة الوصول ليصبح قابلاً للتنزيل
• عند الإصابة: احتفظ به محجوزًا (أو احذفه) وأخطر الأشخاص المناسبين

3) اجعله قابلًا للإعادة بأمان (آمن لإعادة المعالجة)

العمال يتعطلون، والرسائل تُسلم مرتين، وستحدث إعادة محاولات. صمم بحيث أن فحص نفس الملف مرتين لا يسبب ضررًا. استخدم مصدر حقيقة واحد مثل files.status ولا تسمح إلا بالتحولات الصحيحة، على سبيل المثال: uploaded -\u003e scanning -\u003e clean/infected/error. إذا رأى عامل حالة clean، يجب أن يتوقف ويعترف بالرسالة.

4) تحكم في التزامن (تجنب عواصف الفحص)

حدد حدودًا لكل عامل ولكل مستأجر. حدد عدد المسحات المتزامنة، وفكر في طوابير منفصلة للملفات الكبيرة. هذا يمنع عميلًا مشغولًا من استهلاك كل سعة الماسح.

5) تعامل مع الأخطاء بإعادة المحاولة وسجل تدقيقي

استخدم إعادة المحاولة للأخطاء المؤقتة (مهلة الماسح، مشكلة شبكة) مع عدد محاولات صغير. بعد ذلك، أرسل الرسالة إلى طابور الرسائل الميتة للمراجعة اليدوية.

احتفظ بسجل تدقيقي: من رفع المستند، متى دخل الحجر الصحي، أي ماسح شغّل، ماذا قرر، ومن اعتمد أو حذف الملف. ذلك السجل مهم بنفس قدر مسح الفيروسات لرفع الملفات، خاصة لبوابات العملاء والامتثال.

التحكم في الوصول: إبقاء الملفات المحجوزة خاصة حقًا

الحجر الصحي ليس مجرد حالة في قاعدة بياناتك. إنه وعد بأن لا أحد يفتح الملف حتى يثبت أنه آمن. القاعدة الأكثر أمانًا بسيطة: لا تقدم الملفات المحجوزة عبر روابط عامة، حتى "مؤقتة".

تدفق التنزيل الجيد صارم وممل. يجب على التطبيق أن يعامل كل تنزيل كإجراء محمي، لا كجلب صورة.

1. طلب تنزيل
2. تحقق من صلاحية المستخدم لذلك الملف المحدد
3. تحقق من حالة الملف (محجوز، نظيف، مرفوض)
4. سلّم الملف فقط إذا كانت الحالة clean

إذا استخدمت روابط موقعة، احتفظ بنفس الفكرة: أنشئها فقط بعد فحص الصلاحية والحالة، واجعلها قصيرة العمر. قصر الصلاحية يقلل الضرر إذا تسرب الرابط عبر سجلات أو لقطات شاشة أو بريد مُعاد توجيهه.

يساعد التحكم في الوصول القائم على الأدوار على تجنب منطق "الحالة الخاصة" الذي يتحول إلى ثغرات. الأدوار النموذجية لتطبيقات المستندات الثقيلة هي:

• الرافِع: يمكنه رؤية رفعاته وحالة الفحص الخاصة بها
• المراجع: يمكنه عرض الملفات النظيفة، وفي بعض الأحيان رؤية الملفات المحجوزة فقط في أداة مراجعة آمنة
• المدير: يمكنه التحقيق، إعادة الفحص، وتجاوز الأذونات عند الحاجة
• المستخدم الخارجي: يمكنه الوصول فقط إلى المستندات التي تمت مشاركتها صراحةً معه

حماية ضد تخمين المعرفات أيضًا. لا تكشف معرفات ملف متزايدة مثل 12345. استخدم معرفات غامضة، وقم دائمًا بالتفويض لكل مستخدم ولكل ملف (ليس فقط "أي مستخدم مسجل"). حتى لو كان دلو التخزين خاصًا، يمكن لنقطة نهاية API مهملة أن تكشف المحتوى المحجوز.

عند بناء مسح الفيروسات لرفع الملفات، طبقة الوصول هي المكان الذي تحدث فيه معظم فشلات العالم الحقيقي. في منصة مثل AppMaster، ستفرض هذه الفحوصات في نقاط نهاية API ومنطق الأعمال قبل إنشاء أي استجابة تنزيل، حتى يظل الحجر الصحي خاصًا افتراضيًا.

الإصدار، الرفض، وإعادة المحاولة: التعامل مع نتائج الفحص

عند انتهاء فحص ملف، الأهم هو نقله إلى حالة واضحة وجعل الخطوة التالية متوقعة. عند بناء مسح الفيروسات لرفع الملفات، اعتبر نتيجة الفحص كبوابة: لا يصبح شيء قابلاً للتنزيل حتى تقول البوابة ذلك.

مجموعة بسيطة من النتائج تغطي معظم الأنظمة الحقيقية:

• Clean: أفرج عن الملف من الحجر الصحي واسمح بالوصول العادي.
• Infected: احظر الوصول نهائيًا وابدأ سير عمل الملف المصاب.
• Unsupported: لا يستطيع الماسح تقييم هذا النوع (أو الملف محمي بكلمة مرور). احتفظ به محجوزًا.
• Scan error: فشل مؤقت (مهلة، الخدمة غير متاحة). احتفظ به محجوزًا.

يجب أن تكون رسائل المستخدم واضحة وهادئة. تجنّب عبارات مخيفة مثل "تم اختراق حسابك". نهج أفضل: "يتم فحص الملف. يمكنك متابعة العمل." إذا تم حظر الملف، قل للمستخدم ما يمكنه فعله بعد ذلك: "ارفع نوع ملف مختلف" أو "حاول لاحقًا." للأرشيفات المشفرة، كن محددًا: "لا تُفحص الأرشيفات المشفرة".

بالنسبة للملفات المصابة، قرر مبكرًا ما إذا ستحذفها أو تحتفظ بها. الحذف أبسط ويقلل المخاطر. الاحتفاظ قد يساعد في التدقيق، لكنه يجب أن يكون في منطقة معزولة بصلاحيات صارمة وفترة احتفاظ قصيرة، وتسجيل من يمكنه رؤيته (يفضل ألا يرى أحد سوى مسؤولي الأمن).

إعادة المحاولات مفيدة، لكن فقط للأخطاء المحتملة المؤقتة. ضع سياسة إعادة محاولات صغيرة حتى لا تخلق تراكمًا لا نهاية له:

• أعد المحاولة عند المهلات وتعطل الماسح.
• لا تعيد المحاولة على "مصاب" أو "غير مدعوم".
• حد من عدد المحاولات (مثلاً 3) ثم علم الملف كفشل.
• أضف تراجعًا بين المحاولات لتجنب التحميل الزائد.

أخيرًا، عامل الفشل المتكرر كمشكلة تشغيلية، لا كمشكلة مستخدم. إذا ضربت العديد من الملفات "scan error" في نافذة زمنية قصيرة، نبه فريقك وعلّق الإصدارات الجديدة. في AppMaster، يمكنك نمذجة هذه الحالات في قاعدة البيانات وتوجيه الإشعارات عبر وحدات المراسلة المدمجة حتى يسمع الأشخاص المناسبون عن الأخطاء بسرعة.

سيناريو توضيحي: بوابة عملاء بها الكثير من المستندات

تسمح بوابة العملاء للعملاء برفع فواتير وعقود لكل مشروع. هذا مكان شائع حيث يهم مسح الفيروسات لرفع الملفات، لأن المستخدمين يسحبون أي شيء من سطح مكتبهم، بما في ذلك ملفات مرسلة من أشخاص آخرين.

عند رفع عميل ملف PDF، تحفظه البوابة في موقع مؤقت وخاص وتنشئ سجلًا في قاعدة البيانات بحالة Pending scan. لا يُعرض الملف كقابل للتحميل بعد. يلتقط عامل الفحص الملف من الطابور، يفحصه، ثم يحدث السجل إلى Clean أو Blocked.

في واجهة المستخدم، يرى العميل المستند يظهر فورًا، لكن مع شارة Pending واضحة. اسم الملف والحجم مرئيان حتى يعلم أن الرفع نجح، لكن زر التنزيل معطل حتى يصبح الفحص نظيفًا. إذا استغرق الفحص أكثر من المتوقع، يمكن للبوابة عرض رسالة بسيطة مثل "نقوم بفحص هذا الملف للأمان. حاول مرة أخرى بعد دقيقة."

إذا أبلغ الماسح عن مستند، يرى العميل Blocked مع ملاحظة قصيرة وغير تقنية: "فشل هذا الملف في فحص أمني." يحصل الدعم والمدراء على عرض منفصل يتضمن سبب الفحص والإجراءات التالية. يمكنهم:

• إبقاؤه محجوزًا وطلب رفع جديد
• حذفه وتسجيل السبب
• وسمه كموجة إيجابية كاذبة فقط إذا كانت السياسة تسمح

أثناء المنازعات ("رفعته أمس وخسرته"), سجلات جيدة مهمة. احتفظ بالطوابع الزمنية للرفع المستلم، بدء الفحص، انتهاء الفحص، تغيير الحالة، ومن فعل ماذا. أيضًا احفظ تجزئة الملف، اسم الملف الأصلي، حساب الرافع، عنوان IP، وكود نتيجة الماسح. إذا بنيت هذا في AppMaster، يمكن لـ Data Designer مع عملية أعمال بسيطة إدارة هذه الحالات وحقول التدقيق دون كشف الملفات المحجوزة للمستخدمين العاديين.

أخطاء شائعة تسبب ثغرات أمنية حقيقية

معظم أخطاء أمان الرفع ليست اختراقات معقدة. هي اختيارات تصميم صغيرة تُفعل ملفًا غير آمن كوثيقة عادية.

مشكلة كلاسيكية هي السباق: يقبل التطبيق رفعًا، يعيد رابط "تحميل"، ويمكن للمستخدم (أو خدمة أخرى) جلب الملف قبل انتهاء الفحص. إذا كنت تقوم بمسح الفيروسات لرفع الملفات، عامل "مرفوع" و"متاح" كحالتين مختلفتين.

إليك أخطاء تتكرر:

• خلط الملفات النظيفة والمحجوزة في نفس الدلو/المجلد ثم الاعتماد على قواعد التسمية. خطأ واحد في صلاحيات أو مسار ويصبح الحجر الصحي عديم الفائدة.
• الثقة بالامتدادات، نوع MIME، أو الفحوصات على جهة العميل. المهاجمون يمكنهم إعادة تسمية أي شيء إلى .pdf وواجهتك ستتجاوز.
• عدم التخطيط لتعطل الماسح. إذا كان الماسح بطيئًا أو غير متصل، قد تبقى الملفات في "قيد الانتظار" إلى الأبد، وتبدأ الفرق بإضافة تجاوزات يدوية غير آمنة.
• ترك العمال الخلفيين يتخطون نفس قواعد التفويض كنقطة نهاية الرئيسية. عامل يمكنه قراءة "أي ملف" هو تصعيد امتياز هادئ.
• نشر معرفات سهلة التخمين (مثل أرقام متزايدة) للعناصر المحجوزة، حتى لو كنت تعتقد أن المحتوى محمي.

الاختبار أيضًا فجوة. الفرق تختبر ببعض الملفات الصغيرة النظيفة وتعتبر المهمة منتهية. تحتاج أيضًا لتجربة الرفع الكبير، والملفات التالفة، والمستندات المحمية بكلمة مرور، لأن هذه هي الحالات التي يفشل فيها الماسحون والمحللات أو تنتهي مهلاتهم.

مثال بسيط: يرفع مستخدم بوابة عميل "contract.pdf" الذي هو في الواقع ملف قابل للتنفيذ داخل أرشيف مُعاد تسميته. إذا كانت بوابتك تقدم الملف مرة أخرى فورًا، أو يمكن لفريق الدعم الوصول إلى الحجر الصحي بدون فحوصات صحيحة، فقد خلقت مسار تسليم مباشر لباقي المستخدمين.

قائمة تحقق سريعة قبل الإطلاق

قبل أن تطلق مسح الفيروسات لرفع الملفات، قم بجولة أخيرة على الأماكن التي تفترض الفرق فيها "أنه بخير" ثم تكتشف لاحقًا أنها لم تكن كذلك. الهدف بسيط: لا ينبغي أن يصبح ملف غير آمن قابلاً للقراءة لمجرد أن أحدهم خمّن رابطًا، أو أعاد محاولة، أو استخدم رابطًا مخزنًا مؤقتًا.

ابدأ بتدفق المستخدم. أي إجراء تنزيل، معاينة، أو "فتح ملف" يجب أن يعيد التحقق من حالة الفحص الحالية في وقت الطلب، وليس فقط عند الرفع. هذا يحميك من حالات السباق (شخص ينقر فورًا)، نتائج الفحص المتأخرة، والحالات الحدية حيث يُعاد فحص الملف.

استخدم هذه القائمة قبل الإطلاق كحد أدنى:

• تخزين الحجر الصحي خاص افتراضيًا: لا وصول عام إلى الدلو، لا "أي شخص لديه الرابط"، ولا تقديم مباشر من تخزين الكائنات الخام.
• لكل سجل ملف مالك (مستخدم، فريق، أو مستأجر) بالإضافة إلى حالة دورة حياة واضحة مثل pending, clean, infected, أو failed.
• طابور الفحص والعمال لديهم إعادة محاولات محدودة، قواعد تراجع واضحة، وتنبيهات عند توقف العناصر أو فشلها بشكل متكرر.
• سجلات تدقيق للرفع، نتائج الفحص، ومحاولات التنزيل (بما في ذلك المحاولات المحجوبة)، مع من، متى، ولماذا.
• تجاوز يدوي موجود للحالات النادرة، لكنه مخصص للمسؤولين فقط، مسجل، ومؤقت (لا يوجد زر "عدة تنظيف" صامت).

أخيرًا، تأكد أنك قادر على مراقبة النظام من الطرف إلى الطرف. يجب أن تستطيع الإجابة: "كم عدد الملفات قيد الفحص الآن؟" و"أي المستأجرين يرون فشلًا؟" إذا كنت تبني على AppMaster، نمذج دورة حياة الملف في Data Designer وافرِض فحوصات الحالة في Business Process Editor حتى تبقى القواعد متسقة عبر الويب والهاتف.

الخطوات التالية: تحويل التصميم إلى تطبيق عامل

ابدأ بكتابة الحالات الدقيقة التي يمكن أن يكون فيها ملفك، وما الذي يسمح به كل حالة. اجعلها بسيطة وصريحة: "uploaded", "queued", "scanning", "clean", "infected", "scan_failed". ثم أضِف قواعد الوصول بجوار كل حالة. من يمكنه رؤية الملف، تنزيله، أو حذفه وهو لا يزال غير موثوق؟

بعد ذلك، اختر النهج الذي يناسب حجمك وأهداف تجربة المستخدم. الفحص المتزامن أبسط لشرحه، لكنه قد يجعل الرفع بطيئًا. الفحص غير المتزامن يتوسع أفضل لتطبيقات المحملة بالمستندات، لكنه يضيف حالات، طوابير، وواجهة "قيد الانتظار".

طريقة عملية للانتقال من التصميم إلى البناء هي عمل نموذج أولي للتدفق الكامل من الطرف إلى الطرف باستخدام مستندات واقعية (PDFs، ملفات Office، صور، أرشيفات) وسلوك مستخدم واقعي (عدة رفع، إلغاء، إعادة محاولات). لا تتوقف عند "الماسح يعمل". تحقق أن التطبيق لا يقدم ملفًا محجوزًا أبدًا، حتى بطريق الخطأ.

إليك خطة بناء بسيطة يمكنك تنفيذها خلال أسبوع:

• عرّف حالات الملفات، التحولات، وقواعد الوصول في صفحة واحدة
• اختر الفحص المتزامن، غير المتزامن، أو الهجين لمسح الفيروسات لرفع الملفات ووثق المقايضات
• نفّذ: رفع -> تخزين حجر صحي -> مهمة فحص -> رد ناتج، مع سجلات تدقيقية
• ابنِ واجهات الحالة التي سيرىها المستخدمون (قيد الانتظار، محجوز، فشل، موافق)
• أضف المراقبة من اليوم الأول: حجم التراكم، معدل الفشل، ووقت الوصول إلى النظافة

إذا كنت تبني بدون كود، يمكن لـ AppMaster مساعدتك في نمذجة بيانات الملف (الحالة، المالك، checksum، الطوابع الزمنية)، بناء شاشات الرفع والمراجعة، وتنظيم سير عمل الفحص بمنطق أعمال ومعالجة شبيهة بالطوابير. هذا يتيح لك اختبار تدفق المنتج الحقيقي مبكرًا، ثم تشديد الأجزاء الهامة: الصلاحيات، فصل التخزين، وإعادة المحاولات الموثوقة.

أخيرًا، قرر ما الذي يعد "جيدًا" بأرقام. عيّن عتبات تنبيه قبل الإطلاق، حتى تلاحظ الفحوصات العالقة والارتفاع في الأخطاء قبل أن يلاحظ المستخدمون.