التصحيح كمحترف وتأمين تطبيقك

المساء الذي كاد كل شيء ينحرف فيه

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

اطمئن: أمان «المبتدئ المحترف» يقوم على ثلاث جبهات، ولديك أصلًا أسس في كلٍّ منها. الأسرار (مفاتيحك وكلمات مرور بنيتك التحتية)، المدخلات (كل ما يكتبه المستخدمون)، والحدود (ما يحق فعله، وكم مرة). هذا الفصل يطوف الجبهات الثلاث، ثم يسلّحك للتصحيح في الظروف الحقيقية — حيث الخلل عند مستخدم، على جهاز لا تملكه، في ساعة لم تكن حاضرًا فيها.

الجبهة 1 — الأسرار

تعرف أصلًا أن المفاتيح تعيش في ملف .env جهة الخادم. يبقى التحقق من أمرين. أولًا، أن هذا الملف متجاهَل من Git فعلًا: إن جرى commit له، فسينطلق إلى GitHub مع البقية — والمستودع، حتى لو كان خاصًا اليوم، قد يصبح عامًا غدًا. ثانيًا، أن تعرف التصرف عند التسرب: لا «نخفي» أبدًا مفتاحًا مكشوفًا، بل نلغيه (نعطّله في لوحة تحكم الخدمة) ونولّد جديدًا. دائمًا، بلا استثناء، حتى عند الشك.

# .gitignore — في جذر المشروع
.env
.env.local

# التحقق أن .env ليس متتبَّعًا من Git:
git status
# يجب ألا يظهر .env في أي مكان من المخرجات.

# إن تسرب مفتاح: لا نخفيه، بل نُلغيه
# في لوحة تحكم الخدمة، ونولّد مفتاحًا جديدًا.

الجبهة 2 — لا تثق أبدًا بالمدخلات

لنعد إلى مزحة كريم. ماذا فعل؟ كتب كود HTML في حقل «اسم العادة» — شيئًا مثل <h1>COUCOU</h1> — فعرضه التطبيق كما هو، مفسرًا إياه كتنسيق صفحة. مضحك هنا؛ خطير عمومًا: إن عرض تطبيق دون احتياط ما يدخله المستخدمون، يستطيع مستخدم خبيث دسّ كود سيُنفَّذ عند الآخرين. إنها عائلة الهجمات الأكثر شيوعًا على الويب (يسميها العارفون «XSS»)، والدرع يسمى الإفلات (échappement): النص المُدخل يُعرض دائمًا كنص، ولا يُفسَّر أبدًا ككود.

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

تدقيق الأمان: حليفك الذكاء الاصطناعي

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

أجرِ تدقيق أمان كاملًا لتطبيقي لتتبع العادات، مناسبًا لمستواي المبتدئ.
السياق: HTML/JS على Vercel، Supabase بمصادقة الرابط السحري وقواعد RLS، وظائف خادم للبريد والذكاء الاصطناعي، دفع عبر Stripe Payment Links.
تحقق بالأولوية من:
1. مفاتيح أو أسرار حاضرة في كود جهة المتصفح، في مستودع Git أو في تاريخه
2. مدخلات المستخدمين المعروضة دون إفلات: أسماء العادات، محتويات النماذج
3. قواعد RLS: هل يستطيع مستخدم قراءة أو تعديل بيانات آخر؟
4. وظائف الخادم: هل يمكن استدعاؤها دون اتصال؟ دون حد تكرار؟
5. الاعتماديات أو المكتبات ذات الثغرات المعروفة
لكل مشكلة تجدها: اشرح الخطر في جملة بسيطة، أرِ التصحيح الأدنى، وصنّف الكل بحسب الخطورة من حرج إلى ثانوي.
لا تصحح شيئًا دون موافقتي الصريحة، نقطة بنقطة.

مطلبان يصنعان قيمة هذا الموجّه. التصنيف بحسب الخطورة: تعالج الحرج أولًا، وتقرر عن دراية فيما تبقى — فليست كل الثغرات سواء، والمبتدئ الذي يريد تصحيح كل شيء دفعة واحدة لا يصحح شيئًا جيدًا. و«لا تصحح شيئًا دون موافقتي»: التدقيق الذي يعدّل الكود وهو يحلله خارج عن السيطرة. أولًا الفهم، ثم التصحيح، تصحيحًا واحدًا في كل مرة — منهجية الفصل 4 تنطبق على الأمان أيضًا.

الجبهة 3 — وضع حدود في كل مكان

الجبهة الثالثة، الأبسط فهمًا: كل ما لا حد صريحًا له سيُدفع يومًا إلى العبث — بخبث، أو بالصدفة، أو بروبوت. في الفصل 8، حددت البريد واستدعاءات الذكاء الاصطناعي؛ عمم الآن الانعكاس على التطبيق كله. كل حقل له طول أقصى، كل قائمة لها حجم أقصى، كل إجراء له تكرار أقصى. وكل رفض يرافقه رسالة مهذبة وواضحة — الحد يحمي، لا يعاقب.

• اسم العادة: 50 حرفًا كحد أقصى، نص خام فقط.
• عدد العادات لكل حساب: 30 كحد أقصى — لا أحد يتتبع 200، لكن سكربتًا يستطيع إنشاء 100,000.
• ملخص البريد: إرسال واحد لكل مستخدم يوميًا.
• رسالة الذكاء الاصطناعي: استدعاء واحد لكل مستخدم يوميًا، وسقف إنفاق شهري لدى المزود.
• إنشاء الحساب: محمي بتحقق البريد في الرابط السحري — قائم أصلًا، شكرًا للفصل 6.

flowchart TD
  E["مدخل أو إجراء مستخدم"] --> V{"المحتوى صالح؟"}
  V -->|"لا"| R["رسالة خطأ واضحة ومهذبة"]
  V -->|"نعم"| L{"ضمن الحدود؟"}
  L -->|"لا"| R2["رفض مشروح: بلغت الحد"]
  L -->|"نعم"| S["معالجة وتخزين بأمان"]

التصحيح في الإنتاج: المنهجية

تبقى رسالة الزميلة: «كان بطيئًا أمس نحو السابعة». خلل إنتاج نموذجي: لم تره، لا تستطيع إعادة إنتاجه متى شئت، والمستخدم لا يعطي تقريبًا أي تفاصيل. المنهجية المحترفة في ثلاث حركات: اجمع (اطرح على المستخدم الأسئلة الصحيحة: أي جهاز، أي متصفح، أي ساعة، أي إجراء بالضبط، لقطة شاشة)، راجِع (السجلات — «logs» — في Vercel وSupabase، التي تسجل ما حدث فعلًا على الخادم في تلك الساعة)، وافترِض (صياغة فرضيات مصنفة، ثم اختبارها واحدة واحدة، من الأبسط إلى الأعقد).

خلل في الإنتاج يجب تشخيصه بمنهجية.
السياق: تلميذ يقول لي إن التطبيق «يمسح إشاراته» على هاتفه Android مع Chrome، أمس نحو السابعة مساءً. على حاسوبي، يستحيل إعادة الإنتاج.
ما أملكه: سجلات Vercel لتلك الأمسية، الوصول إلى لوحة تحكم Supabase، وإمكانية مراسلة التلميذ مجددًا.
أرشدني في ثلاثة أزمنة:
1. القائمة الدقيقة للأسئلة الواجب طرحها على التلميذ لتحديد السياق
2. ماذا أبحث بالضبط في سجلات Vercel وفي بيانات Supabase حول السابعة
3. كيف أحاكي هاتف Android وشبكة بطيئة من متصفحي لمحاولة إعادة الإنتاج
اقترح بعدها فرضياتك الثلاث الأرجح، مصنفة من الأسهل تحققًا إلى الأعقد، مع الاختبار الواجب لكلٍّ منها.

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

النسخ الاحتياطي، تأمينك على الحياة

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

بجبهاته الثلاث المغطاة، ويومية حوادثه المفتتحة، ونسخته الاحتياطية الأولى المختبَرة، ينام توم أفضل. تلقى كريم رسالة مهذبة («اسم عادة غير صالح 😉»)، وتبيّن أن بطء السابعة كان شبكة داخلية مشبعة — فرضية عادية، كما هو متوقع. التطبيق صلب. حان وقت النظر إليه بطريقة أخرى: لا كمشروع، بل كـمنتج. إنه الفصل الأخير.