2.1النماذج والمتغيرات العامة (Superglobales) ($_GET, $_POST)
الأساسي في 30 ثانية
- GET للقراءة وPOST للتعديل : GET يعرض البيانات في الرابط (البحث، المرشحات، الروابط القابلة للمشاركة) ؛ وPOST يرسلها في جسم الطلب (التسجيل، تسجيل الدخول، البيانات الحساسة) — لا تضع كلمة مرور في GET أبدا.
- لا تثق أبدا بالمدخلات : كل بيان مستلم قد يكون خاطئا أو خبيثا — التحقق على الخادم إلزامي، والتحقق بجافاسكربت لا يكفي أبدا.
- تحقق ثم نقِّ حسب السياق : filter_var تتحقق من الصيغة، وhtmlspecialchars تحمي العرض، والاستعلامات المُحضَّرة (Requêtes préparées) تحمي القاعدة — أداة لكل استعمال.
حالة مستمرة — رياد ونموذج التسجيل في قسنطينة
رياد، مطور ويب في قسنطينة، ينشئ نموذج تسجيل لجمعية محلية : الاسم، البريد الإلكتروني، الولاية. نسخته الأولى تعرض مباشرة ما يكتبه المستخدم — فاختبار بسكربت في حقل الاسم كسر الصفحة. أعاد بناء المعالجة في ثلاثة أوقات : الاسترجاع عبر $_POST، والتحقق على الخادم (حقل مطلوب، بريد صالح بـ filter_var)، والتهرب بـ htmlspecialchars قبل أي عرض. هذا المشروع نفسه يعود في 2.2 (إبقاء المستخدم متصلا بالجلسة)، و2.3 (تنظيم النموذج بالتضمينات) و2.4 (التحقق من البريد وتأريخ التسجيل).
الخيط الرابط للمستوى 2 : مشروع رياد نفسه يعود في الدرس والمخطط والنص الجاهز وتحدي 48 ساعة — ويستمر في 2.2 و2.3 و2.4.
1. $_GET و$_POST : طريقتان واستعمالان
تطبيق الويب يَتفاعل مع المستخدم، خصوصا عبر النماذج (Formulaires). عند إرسال النموذج، تغادر البيانات نحو الخادم وPHP يَسترجعها بفضل المتغيرات العامة (Superglobales) — جداول خاصة متاحة في كل الكود. طريقة GET تمرر البيانات في الرابط (« query string » : recherche.php?q=chaise) : فهي مَرئية ومحفوظة وقابلة للمشاركة والإضافة للمفضلة — مثالية للقِراءة (البحث، المرشح، ترقيم الصفحات، الترتيب)، لأن الطلب عديم الأثر (Idempotent) (إعادة تحميله لا تغير شيئا). وPHP يقرؤها في $_GET ($_GET['q']). طريقة POST تمرر البيانات في جِسم الطلب (غير مرئية في الرابط) : مثالية للإنشاء/التعديل (التسجيل، تسجيل الدخول، الطلب) وللبيانات الحساسة أو الكبيرة. وPHP يقرؤها في $_POST. نموذج HTML يعلن الطريقة (method='post') والهدف (action : ملف PHP الذي يعالج). رياد يطبق ذلك : بحثه عن الأعضاء يذهب بـ GET (رابط قابل للمشاركة)، وتسجيله يذهب بـ POST. وتوجد متغيرات عامة أخرى : $_FILES (الرفع، القسم 2.3)، و$_SERVER (معلومات الطلب)، و$_SESSION/$_COOKIE (القسم 2.2). يجب تجنب : $_REQUEST، الذي يخلط GET وPOST ويفتقد الدقة.
2. لا تثق أبدا بالمدخلات
المنعكس الأساسي لمطور الويب : لا تثق أبدا بالبيانات المستلمة. كل ما يأتي من العميل (نموذج، رابط، ترويسة) قد يكون خاطئا أو خبيثا : يمكن للمستخدم تعطيل جافاسكربت، أو تعديل الكود في متصفحه، أو إرسال طلبات مُلفَّقة مباشرة إلى الخادم دون المرور بصفحتك أبدا. التحقق على العميل (جافاسكربت) يخدم التَجرِبة (رد فوري، توجيه) لكنه قابل للالتفاف ؛ والتحقق على الخادم (PHP) يخدم الأَمان وهو إلزامي — فهو الوحيد الذي تتحكم فيه. رياد جرّب ذلك : تحكمه بجافاسكربت « حقل مطلوب » لم يمنع شيئا عندما أرسل مختبِر نموذجا فارغا بأداة مباشرة. القاعدة : نعيد التحقق من كُل شيء على الخادم، دائما.
3. تحقق، ثم نقِّ حسب السياق
المعالجة على الخادم تقوم على خطوتين. التحقق (Validation) : التأكد من أن البيانات بالصيغة المتوقعة (حقل مطلوب مملوء ؟ بريد صالح ؟ عدد موجب ؟) ورفضها/الإبلاغ عنها وإلا — وPHP يساعد بـ filter_var() (البريد، الرابط، العدد الصحيح…). التنقية/التهرب (Assainissement) : معالجة البيانات حسب استعمالها — htmlspecialchars() قبل العَرض (ضد XSS الذي يحقن HTML/جافاسكربت في صفحاتك)، والاستعلامات المُحضَّرة قبل وَضعها في القاعدة (ضد حقن SQL، المستوى 3). أداة لكل سياق، ولا عكس أبدا. فنموذج رياد يتحقق إذن من البريد بـ filter_var($email, FILTER_VALIDATE_EMAIL) ثم يعرض الاسم بـ htmlspecialchars($nom) — بشكل منهجي، دون استثناء.
🔎 مثال ملموس — 🔎 مثال ملموس — تسجيل رياد، متحقق منه على الخادم
خط الدفاع الأول، كما في نموذج رياد :
$nom = trim($_POST['nom'] ?? '');
$email = trim($_POST['email'] ?? '');
if ($nom === '' || !filter_var($email, FILTER_VALIDATE_EMAIL)) {
echo 'Inscription invalide.';
} else {
echo 'Merci ' . htmlspecialchars($nom, ENT_QUOTES, 'UTF-8') . ' !';
}القراءة : استرجاع عبر $_POST، والتحقق من الصيغة، والتهرب قبل العرض.
الدرس : التحقق بجافاسكربت لا يكفي أبدا — الخادم يعيد التحقق من كل شيء.
مفردات القسم
- النموذج / المتغيرات العامة
- النماذج ترسل بيانات إلى الخادم، وPHP يسترجعها عبر متغيرات عامة (Superglobales)، وهي جداول خاصة متاحة في كل مكان : $_GET و$_POST و$_FILES و$_SESSION…
مثال بسيط: رياد يقرأ الاسم المدخل بـ $_POST['nom'].
ما ليس كذلك: متغيرات عادية محدودة بدالة.
رد فعل: بيان جاء من العميل = متغير عام + حذر.
- $_GET مقابل $_POST
- GET : البيانات في الرابط، مرئية وقابلة للمشاركة، للقراءة (البحث، المرشحات). POST : البيانات في الجسم، غير مرئية في الرابط، للتعديل أو للبيانات الحساسة.
مثال بسيط: بحث رياد يذهب بـ GET، وتسجيله بـ POST.
ما ليس كذلك: صيغتان قابلتان للتبادل دون أثر.
رد فعل: القراءة = GET ؛ والتعديل أو الحساس = POST.
- لا تثق أبدا بالمدخلات
- كل بيان من المستخدم قد يكون خاطئا أو خبيثا ؛ تحقق ونقِّ دائما على الخادم قبل استعماله.
مثال بسيط: رياد يعيد التحقق من البريد على الخادم حتى مع تحكم جافاسكربت.
ما ليس كذلك: بيان معروض كما هو لأنه جاء من نموذجه.
رد فعل: مدخل مستلم = مدخل مشبوه حتى التحقق.
- التحقق (Validation)
- التأكد من أن البيانات بالصيغة المتوقعة (المطلوب مملوء، البريد صالح، العدد صحيح) والرفض وإلا ؛ وfilter_var() تساعد للبريد والرابط والعدد الصحيح.
مثال بسيط: filter_var($email, FILTER_VALIDATE_EMAIL) يقبل التسجيل أو يرفضه.
ما ليس كذلك: عرض البيان على أمل أنه صحيح.
رد فعل: كل حقل = قاعدة تحقق صريحة.
- تحقق الخادم إلزامي
- تحقق العميل (جافاسكربت) يحسن التجربة لكنه قابل للالتفاف ؛ وتحقق الخادم (PHP) إلزامي لأنه الوحيد الموثوق.
مثال بسيط: مختبِر رياد التف على جافاسكربت، لكن PHP منع رغم ذلك.
ما ليس كذلك: تحكم جافاسكربت يُعد حماية.
رد فعل: الراحة على العميل، والأمان على الخادم.
في التطبيق — تطبيقيا — استقبال بيانات النماذج ومعالجتها
- أنشئ نموذج HTML (method='post' نحو ملف PHP) واسترجع البيانات على الخادم عبر $_POST['champ'].
- قارن GET وPOST : نموذج بحث بـ GET (البيانات في الرابط) مقابل نموذج تسجيل بـ POST (الجسم، غير مرئي).
- تَحقَّق من البيانات على الخادم : الحقل المطلوب مملوء ؟ البريد صالح (filter_var) ؟ العدد صحيح ؟ — ارفض/أبلغ إن كانت غير صالحة.
- نَقِّ : اهرب بـ htmlspecialchars() قبل عرض بيانات المستخدم — وتذكر أن تحقق العميل (JS) لا يكفي أبدا.
نص جاهز — شرح التحقق المزدوج لزميل (30 ثانية)
« لنموذج التسجيل، أُبقي تحكم جافاسكربت للراحة — رد فوري. لكني أعيد التحقق من كل شيء بـ PHP : الحقل المطلوب، والبريد بـ filter_var، وhtmlspecialchars قبل العرض. جافاسكربت يُلتف عليه بنقرتين، وPHP هو المكان الوحيد الذي أتحكم فيه فعلا. »
يُقال مع عرض طلب مُلفَّق يلتف على جافاسكربت لكن PHP يمنعه.
قالب للنسخ — معالجة نموذج آمنة
' . htmlspecialchars($e, ENT_QUOTES, 'UTF-8') . '';
}
return;
}
echo 'Merci ' . htmlspecialchars($nom, ENT_QUOTES, 'UTF-8')
. ' (' . htmlspecialchars($email, ENT_QUOTES, 'UTF-8') . ') !
';بحث قابل للمشاركة
فهرس رياد يُرشَّح بـ GET : الرابط يحمل المعايير، نشاركه ونضيفه للمفضلة.
تسجيل حساس
الاسم والبريد وكلمة المرور تذهب بـ POST : لا شيء في الرابط ولا في السجل — ثم HTTPS للنقل.
قائمة بيضاء للقيم
الولاية تأتي من قائمة مغلقة : رياد يتحقق من أن القيمة المستلمة من الخيارات المسموحة، وإلا الرفض.
نموذج ضخم
رسالة طويلة وحقول كثيرة : POST يقبل بيانات أكثر من GET المحدود بطول الرابط.
✓ ممارسات جيدة
- GET للقراءة (البحث، المرشح) ؛ وPOST للتعديل أو للبيانات الحساسة.
- التحقق منهجيا على الخادم (filter_var، تحققات صريحة).
- التهرب بـ htmlspecialchars قبل عرض أي بيان من المستخدم.
✗ أخطاء شائعة
- الاعتماد على تحقق جافاسكربت (يُلتف عليه بنقرتين).
- تمرير كلمة مرور بـ GET (مرئية في الرابط والسجل والملفات).
- استعمال $_REQUEST (يخلط GET/POST، أقل دقة وأمانا).
النقاط الأساسية
- النَماذج ترسل بيانات يسترجعها PHP عبر المُتغيرات العامة (Superglobales) : $_GET (الرابط، البحث/المرشحات) و$_POST (الجسم، النماذج المعدِّلة/البيانات الحساسة).
- المنعكس الأساسي : لا تَثق أبدا ببيانات المستخدم (قد تكون خاطئة أو خبيثة) — تَحقَّق ونَقِّ دائما على الخادم قبل الاستعمال.
- تَحقَّق (الصيغة المتوقعة : البريد، العدد، المطلوب — filter_var) ونَقِّ/اهرُب حسب السياق (htmlspecialchars قبل العرض، استعلامات مُحضَّرة قبل القاعدة).
- تحقق العَميل (جافاسكربت) يحسن التجربة لكنه قابِل للالتفاف ؛ وتحقق الخادم (PHP) إلزامي — فهو الذي يحمي فعلا.
تحدي 48 ساعة — طبق غدا
خذ نموذجا حقيقيا (نموذجك أو نموذج رياد : الاسم + البريد) وأضف المعالجة الكاملة على الخادم : الاسترجاع عبر $_POST، والتحقق (المطلوب + filter_var)، والعرض بـ htmlspecialchars منهجي. ثم التف على جافاسكربت وتحقق من أن PHP يمنع.
- أستطيع شرح متى أستعمل GET ومتى POST، مع مثال لكل منهما.
- أعرف التحقق على الخادم (المطلوب، filter_var) والتهرب قبل العرض.
- اختبرت أن طلبا مُلفَّقا لا يتجاوز معالجتي على الخادم.
أسئلة شائعة
GET أم POST : كيف أختار الطريقة الصحيحة للنموذج ؟
حسب طبيعة الفعل وحساسية البيانات. GET : البيانات مضافة للرابط (مرئية، محفوظة، قابلة للمشاركة والإضافة للمفضلة). POST : البيانات في الجسم (ليست في الرابط). القاعدة : استعمل GET للقِراءة/الاسترجاع (البحث، المرشح، ترقيم الصفحات، الترتيب، الرابط) — فالطلب عديم الأثر (قابل لإعادة التحميل دون خطر) والرابط قابل للمشاركة. واستعمل POST للإنشاء/التعديل/الحذف (التسجيل، تسجيل الدخول، الإرسال، الطلب) — فهذه الأفعال يجب ألا تتكرر بالخطأ عند إعادة التحميل (المتصفح يحذر قبل إعادة إرسال بيانات POST)، والبيانات لا تلوث الرابط، وPOST يقبل بيانات أكثر. البيانات الحساسة (كلمة المرور) ← POST ولا تكون بـ GET أبدا — لكن POST وحده لا يشفر شيئا : يلزم HTTPS للسرية الحقيقية (POST يتجنب العرض في الرابط، وHTTPS يحمي النقل). نماذج HTML لا تدعم أصلا إلا GET وPOST ؛ وواجهات API (القسم 4-4) تستعمل أيضا PUT/PATCH/DELETE.
لماذا التحقق على الخادم إلزامي إن كنت أتحقق على العميل (جافاسكربت) ؟
لأن العميل غير موثوق. تحقق العميل (جافاسكربت) يخدم التَجرِبة : رد فوري، توجيه — مفيد لكنه قابِل للالتفاف بسهولة : جافاسكربت معطل (التحقق مُتجاوَز)، أو كود معدل عبر أدوات المتصفح، أو طلب مرسل مباشرة إلى الخادم (أداة أو سكربت) دون المرور بصفحتك أبدا. لا ضمان أن طلبا مستلما جاء من نموذجك. تحقق الخادم (PHP) يخدم الأَمان : فهو المكان الوحيد الموثوق الذي تَتحكم فيه. بدونه : بيانات فاسدة وأخطاء وثَغرات (حقن SQL وXSS). افعل الاثنين : العميل للراحة (مستحسن)، والخادم للأمان (حتمي) — أعد التحقق من كُل شيء (المطلوب، الصيغ، الأطوال، القيم المسموحة) ونقِّ حسب الاستعمال. الصورة : تحقق العميل لافتة مهذبة، وتحقق الخادم هو الرقابة الحقيقية.
هل يكفي التحقق على العميل (جافاسكربت) للأمان ؟