2.2الجلسات (Sessions) والكوكيز (Cookies) والمصادقة البسيطة
الأساسي في 30 ثانية
- HTTP ينسى كل شيء : كل طلب مستقل — الكوكيز والجلسات تضيفان « الذاكرة » بين الصفحات (من المتصل، السلة، التفضيلات).
- الجلسات للحساس والكوكيز للتفضيلات : بيانات الثقة على الخادم ($_SESSION، غير قابلة للتعديل) — لا بيان حساس في كوكي قابل للتعديل أبدا.
- كلمات المرور مُجزَّأة ولا تكون واضحة أبدا : password_hash عند التسجيل، وpassword_verify عند الدخول، ومعرف الجلسة مُجدَّد — دون استثناء.
حالة مستمرة — رياد يُبقي أعضاءه متصلين
رياد يواصل بعد نموذجه (2.1) : يجب أن يبقى أعضاء الجمعية متصلين من صفحة لأخرى لرؤية فضائهم الشخصي. وبما أن HTTP عديم الحالة، يضيف ذاكرة : كوكي لتفضيل اللغة (غير حساس)، وجلسة للهوية (حساسة، على الخادم). عند تسجيل الدخول يتحقق من كلمة المرور بـ password_verify على مجزأة (Hash)، ويجدد معرف الجلسة، ويخزن المعرف في $_SESSION ؛ وكل صفحة محمية تتحقق من الجلسة. وفي 2.3، سيُضمِّن التحقق في ملف مُضمَّن في كل مكان ؛ وفي 2.4، سيؤرخ آخر اتصال.
تتمة الخيط الرابط 2.1 : نموذج رياد يصبح فضاء أعضاء بذاكرة — ويستمر في 2.3 و2.4.
1. إعطاء ذاكرة لـ HTTP : الكوكيز والجلسات
بروتوكول HTTP عديم الحالة (Stateless) : كل طلب مستقل، والخادم لا « يتذكر » شيئا بين صفحتين. ولحفظ حالة (من المتصل، سلة، تفضيلات)، آليتان. الكوكيز (Cookies) : بيانات صغيرة مخزنة في المتصفح، تُعاد إلى الخادم مع كل طلب — تُنشأ بـ setcookie()، وتُقرأ في $_COOKIE. على العميل إذن، فهي مَرئية وقابِلة للتعديل من المستخدم : مخصصة للبيانات غير الحساسة (اللغة، المظهر)، مع خيارات أمان (HttpOnly ضد السرقة بـ XSS، وSecure لـ HTTPS وحده، وSameSite ضد CSRF). الجلسات (Sessions) : الحالة مخزنة على الخادم (لا يستطيع المستخدم تعديلها)، والمتصفح لا يحفظ إلا معرف الجلسة. وفي PHP : session_start() في بداية السكربت تماما (قبل أي إخراج)، ثم التخزين والقراءة عبر $_SESSION ($_SESSION['user_id'] = 42;). البيانات الحساسة تعيش في الجلسة — ولا تكون واضحة في كوكي أبدا. رياد يطبق ذلك : اللغة في كوكي، والهوية في جلسة.
2. مصادقة بسيطة لكن آمنة
الجلسات تخدم خصوصا المصادقة (Authentification). الدورة : عند تَسجيل الدخول، نتحقق من المعرف وكلمة المرور، ثم نخزن الهوية في الجلسة ($_SESSION['user_id']) ؛ وفي كل صفحة مَحمِية، نتحقق من الجلسة (وإلا التوجيه نحو الدخول) ؛ وعند تَسجيل الخروج، ندمر الجلسة (session_destroy()). ثلاث حمايات غير قابلة للتفاوض. أولا، كلمات المرور تُخزَّن مُجزَّأة (Hachage) بـ password_hash() وتُتحقق بـ password_verify() — ولا تكون واضحة أبدا ولا بتجزئة ضعيفة : فتسرب القاعدة سيكشف كل الحسابات وإلا. ثم نجدد المعرف عند الدخول (session_regenerate_id()) ضد تثبيت الجلسة، مع كوكيز جلسة آمنة وHTTPS. وأخيرا، نتحكم في الوصول : نتحقق لا من أن المستخدم متصل فحسب (المصادقة)، بل من أن له الحَق في الوصول للمورد (الترخيص) — وإلا قرأ عضو بيانات عضو آخر بتغيير معرف في الرابط.
3. الفخاخ التي تُعرِّض الحسابات للخطر
المصادقة مجال عالي الرهان : خطأ واحد يُعرِّض حسابات حقيقية للخطر. الفخاخ المحظورة : تخزين كلمة مرور واضحة ؛ ونسيان تجديد معرف الجلسة ؛ وترك كوكيز الجلسة دون HttpOnly/Secure/SameSite ؛ والعمل دون HTTPS ؛ والتحقق من الاتصال دون الترخيص ؛ وكشف برسائل خطأ دقيقة عناوين البريد الموجودة ؛ وعدم تحديد المحاولات (القوة الغاشمة) ؛ وبناء الاستعلامات بالدمج بدل الاستعلامات المُحضَّرة (حقن SQL، المستوى 3). رياد علَّم على كل نقطة قبل فتح فضاء الأعضاء. وفي المَشروع الحقيقي، نفضل أنظمة المصادقة المُجرَّبة في أطر العمل، التي تدير هذه الدقائق بشكل صحيح : فهم الآليات (كما هنا) أساسي، وتنفيذها بصرامة أهم.
🔎 مثال ملموس — 🔎 مثال ملموس — دخول أعضاء رياد
جلسة + كلمة مرور مُجزَّأة، كما عند رياد :
session_start();
if (password_verify($_POST['mdp'] ?? '', $user['hash'])) {
session_regenerate_id(true);
$_SESSION['user_id'] = (int) $user['id'];
}
// صفحة محمية :
// if (!isset($_SESSION['user_id'])) { header('Location: connexion.php'); exit; }القراءة : التحقق على المجزأة، والمعرف مُجدَّد ضد التثبيت، والهوية على الخادم.
الدرس : تحقق أيضا من الترخيص (الحَق في الوصول)، لا من الاتصال فحسب.
مفردات القسم
- HTTP عديم الحالة (Stateless)
- كل طلب HTTP مستقل، والخادم لا يتذكر السابقة ؛ والكوكيز والجلسات تضيفان ذاكرة بين الصفحات.
مثال بسيط: يجب على رياد إضافة ذاكرة لإبقاء أعضائه متصلين.
ما ليس كذلك: خادم يتعرف تلقائيا على زواره.
رد فعل: الحالة بين الصفحات = كوكي أو جلسة تُتوقَّع.
- الكوكيز ($_COOKIE)
- بيانات صغيرة مخزنة في المتصفح، تُعاد مع كل طلب (setcookie / $_COOKIE) ؛ على العميل إذن فقابلة للتعديل — مع خيارات HttpOnly وSecure وSameSite.
مثال بسيط: رياد يحفظ اللغة المختارة في كوكي.
ما ليس كذلك: تخزين آمن للهوية أو دور.
رد فعل: الكوكي = تفضيلات غير حساسة فقط.
- الجلسات ($_SESSION)
- حالة مخزنة على الخادم، لا يستطيع المستخدم تعديلها، والمتصفح لا يحفظ إلا معرفا ؛ session_start() ثم $_SESSION — الآلية الآمنة.
مثال بسيط: هوية أعضاء رياد تعيش في $_SESSION['user_id'].
ما ليس كذلك: بيان يستطيع المستخدم تحريره في متصفحه.
رد فعل: بيان الثقة = جلسة.
- المصادقة بالجلسة
- تسجيل الدخول : التحقق من المعرف + كلمة المرور ثم تخزين الهوية في الجلسة ؛ الصفحات المحمية : التحقق من الجلسة ؛ تسجيل الخروج : تدمير الجلسة.
مثال بسيط: رياد يحمي فضاء الأعضاء بـ isset($_SESSION['user_id']).
ما ليس كذلك: صفحة تثق بكوكي قابل للتعديل.
رد فعل: كل صفحة حساسة = تحقق من الجلسة.
- أمان الجلسة
- كلمات مرور مُجزَّأة (password_hash/verify ولا تكون واضحة أبدا)، ومعرف مُجدَّد عند الدخول، وكوكيز مؤمَّنة، وHTTPS، ومراقبة الوصول.
مثال بسيط: رياد يجزئ عند التسجيل ويتحقق بـ password_verify.
ما ليس كذلك: كلمة مرور مخزنة واضحة أو بـ md5.
رد فعل: مصادقة جديدة = قائمة أمان كاملة.
في التطبيق — تطبيقيا — إدارة الحالة ومصادقة بسيطة
- ابدأ جلسة (session_start() في بداية السكربت، قبل أي إخراج) وخزن البيانات واقرأها عبر $_SESSION.
- أنشئ كوكي بـ setcookie() (خيارات HttpOnly/Secure) واقرأه عبر $_COOKIE ؛ وافهم أنه مخزن على العميل (قابل للتعديل).
- ابنِ مصادقة : عند الدخول، تحقق من كلمة المرور (password_verify على مجزأة)، وخزن $_SESSION['user_id']، وجدد معرف الجلسة.
- احمِ الصفحات (تحقق من الجلسة، ووجِّه وإلا) وأدر تسجيل الخروج (session_destroy) ؛ وتذكر : كلمات مرور مُجزَّأة، وجلسة محمية، وHTTPS.
نص جاهز — تبرير الجلسة للمسؤول الجمعوي (30 ثانية)
« لفضاء الأعضاء، الهوية تعيش في جلسة على الخادم : فالعضو لا يستطيع تعديلها. والكوكي لا يحمل إلا اللغة. وكلمات المرور مُجزَّأة ولا تكون واضحة أبدا، وأجدد المعرف مع كل دخول. وإن زيف أحد كوكيه فلن يكسب أي وصول. »
يُقال مع عرض كوكي معدل لا يعطي أي وصول ؛ فالبرهان يقنع.
قالب للنسخ — تسجيل دخول وصفحة محمية
' . htmlspecialchars('Identifiants invalides.', ENT_QUOTES, 'UTF-8') . '';
// --- صفحة محمية (espace.php) ---
// session_start();
// if (!isset($_SESSION['user_id'])) { header('Location: connexion.php'); exit; }
// --- تسجيل الخروج ---
// $_SESSION = []; session_destroy();تفضيل اللغة
رياد يحفظ الفرنسية أو العربية في كوكي طويل المدة : غير حساس، ومثالي للعميل.
سلة حساسة
محتوى سلة متجر الجمعية يعيش في جلسة : فالعضو لا يستطيع تعديل الأسعار.
خروج نظيف
نقرة تفرغ $_SESSION وتدمر الجلسة : فعلى حاسوب مشترك، لا يستعيد أي لاحق الحساب.
نحو إطار العمل
في مشروع حقيقي، سيعهد رياد بالمصادقة لنظام إطار العمل المُجرَّب — المبادئ نفسها والدقائق مُدارة.
✓ ممارسات جيدة
- استعمال الجَلسات للحالة الحساسة (الهوية، السلة).
- تجزئة كلمات المرور بـ password_hash / password_verify ولا تكون واضحة أبدا.
- تجديد معرف الجلسة عند الدخول + كوكيز مؤمَّنة + HTTPS.
✗ أخطاء شائعة
- تخزين بيانات الثقة في كوكي (قابل للتعديل من المستخدم).
- تخزين كلمة مرور واضحة أو بـ md5/sha1.
- التحقق من الاتصال فحسب ونسيان الترخيص (الوصول لبيانات الغير).
النقاط الأساسية
- HTTP عديم الحالة (كل طلب مستقل) ؛ والكوكيز (على المتصفح، $_COOKIE) والجَلسات (على الخادم، $_SESSION) تضيفان « ذاكرة » بين الصفحات.
- الجَلسات = الآلية الآمِنة : البيانات على الخادم (غير قابلة للتعديل)، والمتصفح لا يحفظ إلا معرِّفا. والكوكيز = على العميل (قابلة للتعديل، للبيانات غير الحساسة).
- المُصادقة : تسجيل الدخول (التحقق من كلمة المرور وتخزين الهوية في الجلسة) ← صفحات محمية (التحقق من الجلسة) ← تسجيل الخروج (التدمير).
- الأمان (عالي الرهان) : كلمات مرور مُجزَّأة (password_hash/verify ولا تكون واضحة أبدا)، وتجديد المعرف عند الدخول، وكوكيز مؤمَّنة (HttpOnly/Secure/SameSite)، وHTTPS، ومراقبة الوصول (الترخيص).
تحدي 48 ساعة — طبق غدا
ابنِ دخولا أدنى : مجزأة منشأة بـ password_hash، والتحقق بـ password_verify، وsession_regenerate_id، وتخزين الهوية في الجلسة، وصفحة محمية توجِّه وإلا، وتسجيل خروج. ثم زيف كوكيك ولاحظ أن الوصول يبقى مرفوضا.
- أستطيع شرح الفرق بين الكوكي والجلسة وقول أين يعيش كل بيان.
- أعرف بناء دخول بمجزأة وجلسة مُجدَّدة وصفحة محمية.
- تحققت من أن كوكيا مُزيَّفا لا يعطي أي وصول.
أسئلة شائعة
الكوكيز أم الجلسات : ما الفرق، وأيهما أستعمل ولماذا ؟
كلاهما يعطي « ذاكرة » لـ HTTP، لكن بشكل مختلف. الكوكيز : البيانات في المتصفح (على العميل)، تُعاد مع كل طلب — مَرئية وقابِلة للتعديل من المستخدم، وحجم صغير، وبقاء طويل ممكن ؛ ولا بيانات حساسة واضحة فيها أبدا (خيارات HttpOnly وSecure وSameSite). الجَلسات : البيانات على الخادم، والمتصفح لا يحفظ إلا معرِّفا ؛ ولا يستطيع المستخدم تعديل البيانات ؛ وسعة أكبر ؛ وتدوم عادة مدة الزيارة. الجلسات تستعمل كوكيا (للمعرف) لكن البيانات تبقى على الخادم — وهذا هو الفرق المفتاح. استعمل الجَلسات للحالة الحساسة (المصادقة، السلة) — الخيار الافتراضي ؛ والكوكيز للتفضيلات غير الحساسة والبقاء الطويل (اللغة، المظهر). أمِّن الاثنين (خيارات الكوكي، وتجديد المعرف، وHTTPS).
كيف أبني مصادقة صحيحة، وأي فخاخ أتجنب ؟
الخطوات : (1) التسجيل — تحقق، وجَزِّئ بـ password_hash()، وخزن المُجزَّأة (ولا تخزن الواضح أبدا). (2) الدخول — استرجع المستخدم بالبريد (استعلام مُحضَّر)، وتحقق بـ password_verify()، ثم session_regenerate_id() وخزن الهوية في الجلسة. (3) الصفحات المحمية — تحقق من الجلسة (isset($_SESSION['user_id']))، وإلا وجِّه. (4) الترخيص — تحقق من الحَق في هذا المورد، لا من الاتصال فحسب. (5) الخروج — أفرغ الجلسة ثم دمرها. فخاخ خطيرة : كلمات المرور الواضحة أو المُجزَّأة سيئا (الأسوأ)، والمعرف غير المُجدَّد (التثبيت)، والكوكيز غير المؤمَّنة، وغياب HTTPS، والترخيص المنسي، ورسائل الخطأ الكاشفة للعناوين، والمحاولات غير المحدودة (القوة الغاشمة)، والاستعلامات المدمجة (حقن SQL). وفي المَشروع الحقيقي، فضِّل أنظمة المصادقة المُجرَّبة في أطر العمل.
أين تُخزَّن بيانات الجَلسة ؟