لا يفكر العديد من المطورين أبدًا في مفهوم الدولة قبل تقديم الطلبات إلى الويب. كما ذكرنا سابقًا ، فإن الويب هي بيئة عديمة الجنسية. لذلك ، يجب أن نناقش ماهية الدولة وفهم الأساليب التي يمكن أن تتجنب المشاكل.
تعريف دقيق للحالة
في برنامج مستخدم واحد ، عند إنشاء تطبيق قابل للتنفيذ ، مثل استخدام VB لإنشاء ملف .exe ، يمكنك إعلان متغير عالمي (أو عام) ثم الوصول إليه في أي مكان في الكود. تكون قيمة اللحظة صالحة دائمًا ويمكن الوصول إليها في جميع الأوقات.
بالنسبة لحل العميل/الخادم التقليدي ، مثل النظام الذي يقوم فيه التطبيق المستند إلى العميل بإدخال محرك قاعدة بيانات قائم على الخادم ، يقوم كل عميل بإنشاء اتصال بتطبيق الخادم وقاعدة البيانات. عادة ما يتم إنشاء هذا الاتصال عن طريق التحقق من المستخدم.
عملية التحقق هي عملية نموذجية لتحديد المستخدم ، والتي تثبت ما إذا كان مستخدمًا شرعيًا من خلال مجموعة من اسم المستخدم وكلمة المرور.
بمجرد المصادقة ، يتم إنشاء اتصال بين العميل والتطبيق المستند إلى الخادم ، والذي يظل صالحًا طوال الوقت الذي استخدمه المستخدم التطبيق. يحدث هذا عندما يسجل المستخدم على خادم Windows 2000 المخمر. عندما يستخدم المسؤول أداة Active Directory Assor و Computers (انقر فوق عنصر إدارة الدليل في خيار الأدوات الإدارية في قائمة START) لمراقبة اتصالات المستخدم النشطة. هذه العملية هي نفسها في العديد من الأنظمة ، مثل Microsoft SQL Server.
يعني هذا الاتصال الدائم أنه عندما يقوم المستخدم بإرسال التعليمات أو الطلبات إلى الخادم ، يقوم الخادم بتحديد كل مستخدم بسهولة. يمكن أيضًا إرجاع استجابة الخادم نفسها أو أي معلومات مستخدم أخرى إلى المستخدم مباشرة. تجدر الإشارة أيضًا إلى أن الخادم يمكنه تخزين القيم والمعلومات المتعلقة بكل عميل بسهولة أكبر وتزويدها بالعميل المقابل عند الحاجة. بالطبع ، يمكن أن يكون لتطبيقات الخادم متغيرات عالمية رئيسية للمستخدمين للوصول عند الحاجة.
هذه القدرة على تحديد الطلبات من كل عميل وحفظ قيم المستخدم ذي الصلة في الذاكرة تشكل الحالة. يمكن اعتبار الحالة تمثل قيمة التطبيق والبيئة والمتغيرات الداخلية للمستخدم وتشغيلها خلال العملية الكاملة للتطبيق واتصال المستخدم.
أهمية الوضع
إذا كنت تنوي إنشاء تطبيق قائم على موقع الويب يتفاعل مع المستخدم ، بدلاً من موقع ويب يعرض صفحات مستقلة فقط ، يجب أن تكون قادرًا على توفير حالة منفصلة لكل مستخدم. قد يتذكر هذا اسمهم فقط ، أو قد يكون أيضًا تخزين مراجع الكائنات أو سجلات سجلات مختلفة لكل مستخدم. إذا لم تتمكن من القيام بذلك ، فلن تتمكن صفحة الويب من ASP من فعل المزيد ، لأنه عندما يتم تنفيذ الصفحة ، يتم تدمير المتغيرات والمعلومات الأخرى ذات الصلة في الصفحة. عندما يطلب المستخدم الصفحة التالية ، ستضيع جميع المعلومات المقدمة في هذه الصفحة.
لذلك ، من الضروري إيجاد طريقة لحفظ حالة كل زائر. من المهم جدًا أن تكون قادرًا على تخزين القيم العالمية لجميع المستخدمين. على سبيل المثال ، وصول وصول على غرار ويب ، نقرة إلى لا يوفر لكل مستخدم عداده الخاص ، وعادة ما يرغب المستخدمون في رؤية العدد الإجمالي للزوار ، وليس فقط عدد الزيارات التي يزورونها أنفسهم. يجب تخزين عدد الزوار مع حالة مستوى التطبيق ، وليس مع حالة مستوى المستخدم.
هذه ليست مشكلة ظهرت للتو. لذلك هناك العديد من الحلول التقليدية لتخزين الحالة على الويب. يريد مسؤولو موقع الويب معرفة ما إذا كان الزوار قد زاروا موقع الويب الخاص بهم من قبل ، وإذا كان الأمر كذلك ، فكم من المرات التي زاروها؟ أيضا زيارة مواقع الويب الأخرى بانتظام. هذا سيجعل من الأفضل وضع أهدافها الإعلانية. كل هذا يتطلب طريقة لتخزين المعلومات حول طلبات صفحة الويب التي تم إنشاؤها من قبل المستخدم أثناء الوصول أو بين كل زيارة.
إنشاء حالة على الويب
هناك طريقة شائعة لتوفير الحالة بين طلبات الصفحة والوصول إلى الموقع من خلال ملفات تعريف الارتباط. لقد رأينا في الفصول السابقة كيفية تخزين القيم المقابلة في كمبيوتر العميل ، والتي يتم إرسالها مع كل طلب صفحة إلى المجال الصالح لهذا ملف تعريف الارتباط. من خلال فحص ملفات تعريف الارتباط وتحديثها باستخدام ASP ، من الممكن الحفاظ على حالة إلى حد ما. يمكن استخدام المعلومات المضمنة لتحديد المستخدم ثم توصيل المستخدم بمجموعة من القيم المقابلة المخزنة.
على سبيل المثال ، يمكن اكتشاف ما إذا كان طلب المستخدم يحتوي على ملف تعريف ارتباط محدد الموقع. إذا لم يتم تضمينه ، يتم تعيين المستخدم نوعًا معينًا من الهوية ، وتحديد رقم ، وتخزينه في ملف تعريف الارتباط مع فترة صلاحية طويلة. في كل مرة يزور المستخدم هذا الموقع في المستقبل ، سيكون قادرًا على اكتشاف ملفات تعريف الارتباط وتحديث المعلومات الموجودة فيه. يمكن أيضًا جمع بيانات حول عدد ومدة الزيارات وتخزينها على الخادم للاستخدام في المستقبل.
ولكن ماذا يحدث إذا نقل المستخدم إلى كمبيوتر آخر ، أو يحذف ملف تعريف ارتباط ، أو يرفض متصفحه استلام ملف تعريف الارتباط المرسلة إليهم؟ في هذه الحالة ، لا يمكن الحفاظ على الدولة لأنه لن يتم الاعتراف بها في المرة القادمة. إذا فتحت هذا التحذير قبل قبول خيار ملفات تعريف الارتباط في متصفحك ثم تجول حول عدد قليل من المواقع الكبيرة ، فسوف تفهم المعنى.
1. الزوار المجهولون والزوار المعتمدين
إذا كنت تعتقد أن ملفات تعريف الارتباط هي حل قذرة بعض الشيء ، فيمكنك استخدام نهج أكثر وضوحًا. تتمثل إحدى الأساليب التي تستخدمها العديد من المواقع في الظهور في مربع حوار تسجيل الدخول عندما ينقر الزائر على موقع ، أو عندما تكون صفحة تتطلب التحقق من الهوية. يجب على الزائرين أولاً التسجيل والحصول على نوع معين من مجموعة اسم المستخدم/كلمة المرور من أجل السماح بالوصول إلى الموقع أو الصفحة المقابلة.
لإثبات أن الزائر هو مستخدم معروف وشرعي ، فإن ملف تعريف الارتباط الموضح على كمبيوتر الزائر إما يحفظ بيانات التسجيل التفصيلية أو مفتاح يشير إلى أن الهوية قد تم التحقق منها. في الوقت نفسه ، يتم حفظ البيانات التفصيلية للزائر بشكل دائم على الخادم وعلى استعداد لاستخدامها عند الوصول مرة أخرى. إذا كان لدى الزائر ملف تعريف الارتباط في متصفحه ، فيمكنه الوصول بحرية إلى موقع الويب لأنه تم التحقق منه.
إذا لم يكن لدى ملف تعريف الارتباط فترة صلاحية (انتهاء صلاحية) ، فسوف تختفي قيمة ملف تعريف الارتباط تلقائيًا عند إغلاق المتصفح ويجب إعادة تسجيله والتحقق منه مرة أخرى في الزيارة التالية. بالطبع ، إذا رفضت استلام ملفات تعريف الارتباط أو حذف ملفات تعريف الارتباط ، فيمكنك فقط الحصول على مربع حوار التسجيل مرة أخرى. وبهذه الطريقة ، إذا لم يتم التعرف عليها ، فلا يمكن الوصول إلى الموقع.
من خلال إجبار المستخدمين على التسجيل مع خادم ويب تمامًا مثل التسجيل في شبكتهم الخاصة ، يوفر أداء الأمن العام لنظام التشغيل Windows 2000 إمكانيات التحقق الأقوى والأمان. ومع ذلك ، يمكن أن يعمل هذا فقط مع المتصفحات مع Internet Explorer 3.0 وما فوق. يمكن أن تستخدم IIS أيضًا التحقق الأساسي للسماح للمتصفحات غير الميكروسوف بتسجيل خادم الويب.
2. لا مزيد من الزوار المجهولين
عند استخدام ASP على خادم الويب IIS ، يمكن تتبع المستخدمين في الجلسة الحالية ما لم يترك المستخدم الموقع إلى موقع ويب آخر أو يغلق المتصفح. في وقت لاحق من هذا الفصل ، سترى كيف يتم استخدام هذه الميزة لتحديد زائر ، وتخزين المعلومات المحلية للمستخدم ، وتوفير الحالة. فيما يلي مناقشة حول كيفية عملها مقارنة بالحلول التي تمت مناقشتها بالفعل.
اقترح ASP و IIS مشترك مفهوم جلسات المستخدم ، والتفاعل من خلال كائنات جلسة ASP. عندما يقوم كل زائر بالوصول إلى صفحة ويب ASP على الخادم ، قم بإنشاء كائن جلسة جديد ومستقل له ، وقم بتعيين رقم تعريف الجلسة إلى الجلسة ، وإضافة نسخة مشفرة خاصة من معرف الجلسة.
يتم تعيين مسار ملف تعريف الارتباط (انظر الفصل السابق لوصف سمات ملفات تعريف الارتباط) على مسار الجذر لتطبيق ASP الذي يعمل على الخادم. من المحتمل أن يكون هذا في دليل الجذر الخاص بموقع الويب الافتراضي (أي /) ، ولكنه قد يكون أيضًا قيمة أخرى (انظر لاحقًا). لا يتم توفير قيمة انتهاء الصلاحية في ملف تعريف الارتباط ، لذلك عندما يتم إغلاق المتصفح ، تختفي قيمة ملفات تعريف الارتباط.
عندما يزور هذا المستخدم صفحة ويب ASP هذه ، سيبحث ASP عن ملف تعريف الارتباط هذا. اسمه aspsessionidxxxxxxxx ، حيث كل x هو حرف أبجدي. من مجموعة ServerVariables الموضحة في الشكل 2-7 في الفصل 2 ، يمكنك رؤيتها في رأس HTTP.
ومع ذلك ، لا يظهر ملف تعريف الارتباط هذا في مجموعة request.cookies أو Response.cookies ، والتي يختبئ ASP ، ولكن لا يزال يتم حفظها على المتصفح. لكل طلب صفحة ويب ASP ، يجب على ASP عرض القيمة. تشير القيمة الواردة في ملف تعريف الارتباط هذا إلى جلسة المستخدم. لذلك ، يمكن تسليم محتوى كائن الجلسة المقابل (الذي تمت معالجته في الذاكرة ويحتوي دائمًا على جميع القيم التي يتم تشغيلها أثناء عملية طلب الصفحة السابقة) إلى البرنامج النصي في صفحة الويب ASP.
بالطبع ، كما ذكرنا سابقًا ، إذا لم يتلقى متصفح العميل أو يدعم ملفات تعريف الارتباط هذه ، فإن هذه المعالجة ستفشل. في هذه الحالة ، لا يمكن إنشاء جلسة ASP ولا يتم الحفاظ على حالة هذا الزائر تلقائيًا.