State Management در ASP. NET 2.0 - بخش 2

مفاهيم و چالش ها
كوكی های سفارشی يكی ديگر از روش های موجود جهت ذخيره اطلاعات به منظور استفاده در ساير صفحات می باشند . كوكی ، فايل های كوچكی می باشند كه بر روی هارد ديسك سرويس گيرنده ( و يا حافظه مرورگر وب در صورتی كه قصد ذخيره موقت آنها وجود داشته باشد ) ايجاد می گردند .
يكی از مزايای كوكی ها عملكرد غيرمحسوس آنها و عدم آگاهی كاربر نسبت به ذخيره اطلاعات است . علاوه بر اين كه می توان از كوكی ها در هر يك از صفحات برنامه  استفاده كرد ، امكان استفاده از اطلاعات ذخيره شده در آنها طی بازديدهای آتی كاربر نيز وجود دارد ( مكانی برای ذخيره اطلاعات با طول عمر بيشتر) .
كوكی ها دارای محدوديت ها و يا چالش های مختص به خود نيز می باشند :

• ذخيره حجم اندكی از اطلاعات : صرفا" امكان ذخيره حجم اندكی از اطلاعات به صورت متن در آنها وجود دارد .
• عدم ايمن بودن : در صورتی كه كاربر كوكی و فايل مربوط به آن را پيدا می كند ، می تواند به سادگی به آن دستيابی پيدا نمايد ( خواندن ، حذف ) .
• امكان حذف آنها توسط كاربران : همواره اين احتمال وجود خواهد داشت كه كاربران اقدام به حذف كوكی های موجود بر روی كامپيوتر خود نمايند .
• وجود محدوديت در برخی مرورگرها با توجه به نوع دستگاه سرويس گيرنده : كوكی ها می توانند در تعداد مخاطبان با توجه به نوع دستگاه آنها محدوديت ايجاد نمايند . به عنوان نمونه ، بكارگيری كوكی به همراه مرورگرهای از قبل تعبيه شده در دستگاه های موبايل مناسب نمی باشد .
• وابسته به تنظيمات كاربر : برخی از كاربران امكان ايجاد كوكی را از طريق مرورگر خود غيرفعال می نمايند . اين كار می تواند مسائل متعددی را برای برنامه های وب به دنبال داشته باشد .

عوامل فوق باعث شده است كه كوكی به عنوان يك گزينه ضعيف برای ذخيره اطلاعات مورد توجه قرار گيرد . در مواردی كه اطلاعات پيچيده ، خصوصی و يا حجم آنها زياد باشد ، استفاده از كوكی بسيار محدود می گردد .
نحوه ذخيره و بازيابی اطلاعات
فرآيند ذخيره و بازيابی اطلاعات در يك كوكی به سادگی انجام می شود . اشياء Requestو Responseيك مجموعه Cookiesرا ارائه می نمايند . كوكی ها از طريق شی Requestبازيابی و مقداردهی آنها از طريق شی Responseانجام می شود . برای مقداردهی يك كوكی ، صرفا" می بايست يك شی جديد HttpCookieرا ايجاد كرد . در ادامه می توان اطلاعات مورد نظر را در آن و از نوع رشته ذخيره و به پاسخ فعلی وب اضافه كرد .

كوكی فوق تا زمانی كه كاربر مرورگر را closeنكند ،  وجود خواهد داشت و با هر درخواست ارسال می گردد . برای ايجاد يك كوكی با طول عمر بيشتر ، می توان برای آن يك تاريخ سررسيد را تعريف كرد ( عمر مفيد ) .

برای بازيابی كوكی ، می توان از طريق نام استفاده شده در مجموعه Request.Cookiesاقدام نمود.

تنها روش موجود برای حذف يك كوكی ، جايگزين كردن آن با يك كوكی است كه تاريخ اعتبار آن به اتمام رسيده باشد . كد زير نحوه انجام اين كار را نشان می دهد .

مثال
در اين مثال هدف آشنائی با نحوه ايجاد ، مقداردهی و بازيابی يك كوكی است .
در اولين مرتبه ای كه صفحه درخواست می گردد به دليل عدم وجود كوكی مورد نظر ، پيام "كاربر ناشناس " نمايش داده شده و با ارائه يك textboxاين امكان در اختيار كاربر گذاشته می شود تا نام مورد نظر خود را جهت ذخيره در كوكی درج نمايد . پس از اين كار و همزمان با درخواست صفحه و با توجه به وجود كوكی مورد نظر ، يك پيام خوش آمدگوئی نمايش داده می شود . كوكی ايجاد شده در اين مثال به مدت يك سال از تاريخ ايجاد ، اعتبار خواهد داشت .
عمليات تشخيص وجود كوكی و نمايش يك پيام خوش آمدگوئی از طريق روتين Page_Loadانجام می شود . روتين cmdStoreCookiee_Clickمسئوليت ايجاد كوكی و تعيين يك تاريخ اعتبار برای آن را برعهده دارد  .

و اما  آخرين نكته اين كه ، برخی از ويژگی های ارائه شده در ASP. NETبا استفاده از كوكی خدمات خود را ارائه می نمايند . session state  كه به پياده كنندگان اجازه می دهد بطور موقت اطلاعات مرتبط با كاربر را در حافظه سرويس

دهنده ذخيره نمايند و  امنيت فرم ها كه اين امكان را در اختيار پياده كنندگان قرار می دهد تا بخش هائی از يك وب سايت را محدود به كاربران تائيد شده نمايند ، دو نمونه متداول در اين رابطه می باشند . 
در اين بخش به بررسی SessionState  خواهيم پرداخت:
مفاهيم و چالش ها
در مدت زمان حيات يك برنامه به مواردی برخورد می كنيم كه لازم است جهت ذخيره سازی اطلاعات از امكانات پيشرفته تری استفاده گردد . به عنوان مثال ، يك برنامه ممكن است به ذخيره اطلاعات پيچيده ای نظير اشياء سفارشی داده و استفاده از آنها در ساير صفحات نياز داشته باشد . ارسال اينگونه اطلاعات از طريق كوكی و يا يك query stringمشكل و يا غيرممكن است . علاوه بر اين ، در برخی موارد ملاحظات امنيتی در رابطه با داده وجود دارد  و نمی توان اطلاعات مربوط به يك سرويس گيرنده را در viewstateو يا كوكی ذخيره كرد .
در چنين مواردی می توان از امكانات از قبل تعبيه شده session stateدر ASP.NETاستفاده كرد .
مديريت sessionstateيكی از ويژگی های برجسته ASP.NETاست كه به كمك آن می توان هر نوع داده ئی را در حافظه سرويس دهنده ذخيره كرد . بدين ترتيب ، يك سطح حفاظتی مطلوب در خصوص داده ايجاد خواهد شد چراكه اطلاعات برای سرويس گيرنده ارسال نخواهند شد و برای هر جلسه كاری منحصربفرد می باشند .
هر سرويس گيرنده ای كه به برنامه دستيابی داشته باشد دارای يك sessionمتفاوت و مجموعه ای از اطلاعات متمايز و مختص به خود است . sessionstateبرای ذخيره اطلاعاتی نظير آيتم های خريداری شده توسط كاربر از يك سايت و استقرار آنها در سبد خريد در زمان حركت از يك صفحه به صفحه ديگر بسيار مفيد و موثر واقع می شود .
با استفاده از session stateمی توان اطلاعات مورد نظر را از طريق يك صفحه ذخيره و در ساير صفحات از آنها استفاده كرد .
با اين كه session stateبسياری از مشكلات در ارتباط با ساير روش های مديريت stateرا برطرف نموده است ولی خود نيز دارای چالش های مختص به خود است . به عنوان مثال ، با بكارگيری روش فوق در برنامه های وب ، سرويس دهنده وب ملزم به ذخيره اطلاعات بيشتری در حافظه سرويس دهنده خواهد شد.  اين موضوع می تواند همزمان با افزايش كاربران يك برنامه بر روی كارآئی آن تاثير بگذارد . چراكه درصد استفاده از يك منبع محدود ( حافظه ) افزايش خواهد يافت .  بنابراين ، لازم است استفاده از sessionstate  با دقت و بررسی تمامی جوانب كار صورت پذيريد .
معماری session
 مديريت sessionبه عنوان بخشی از استاندارد HTTPمحسوب نمی گردد . بنابراين لازم است كه ASP.NETعمليات بيشتری را به منظور پيگيری اطلاعات sessionانجام دهد .
ASP.NETهر sessionرا از طريق يك شناسه 120 بيتی منحصربفرد پيگيری و از يك الگوريتم اختصاصی برای توليد آن استفاده می نمايد .  بنابراين حداقل اين تضمين از لحاظ تئوری ايجاد می گردد كه عدد توليد شده منحصر بفرد بوده و به اندازه كافی تصادفی است  تا امكان و يا احتمال تشخيص و حدس آن توسط مهاجمان به حداقل مقدار خود برسد ( مهاجمان با بكارگيری روش هائی موسوم به مهندسی معكوس در تلاش جهت آگاهی از اين موضوع هستند كه يك سرويس گيرنده خاص از چه شناسه ای برای sessionاستفاده می نمايد ) . 
شناسه ، تنها اطلاعات مبادله شده بين سرويس دهنده وب و سرويس گيرنده است . زمانی كه سرويس گيرنده شناسه sessionخود را  ارائه می نمايد ، ASP.NET  در اولين اقدام جستجو جهت يافتن sessionمتناظر با آن را انجام می دهد . در صورتی كه ماحصل فرآيند فوق مثبت باشد ، داده از state serverبازيابی و به اشياء مورد نظر تبديل می گردد . در ادامه ، اشياء فوق در يك مجموعه خاص استقرار می گردند تا امكان دستيابی به آنها از طريق كد وجود داشته باشد . فرآيند فوق بطور اتوماتيك انجام می شود . 
شايد برای شما اين سوال مطرح شده باشد كه ASP.NET، اطلاعات مربوط به sessionرا در چه مكانی ذخيره و چگونه آنها را serializeو deserializeمی نمايد ؟ در  ASPكلاسيك ، session stateبه عنوان يك شی COMپياده سازی شده است كه در كتابخانه asp.dll  مستقر می گردد . در ASP.NET، اينترفيس برنامه نويسی تقريبا" يكسان است ولی نحوه پياده سازی آن با ASPكلاسيك كاملا" متفاوت است .
زمانی كه ASP.NETيك درخواست HTTPرا بررسی می نمايد ، آن را از طريق مجموعه ای از مدول های مختلف كه قادر به واكنش در خصوص رويدادهای برنامه می باشند ، به حركت در می آورد . SessionStateModule، يكی از مدول های موجود در اين زنجيره است ( موجود در namespaceبا نام  System.Web.SessionState) . مدول فوق شناسه sessionرا توليد ، داده sessionرا از ارائه دهندگان خارجی stateبازيابی و داده را  به درخواست مورد نظر نسبت می دهد . همچنين مدول فوق ، اطلاعات مربوط به sessionرا پس از اتمام پردازش صفحه ، ذخيره می نمايد.
توجه داشته باشيد كه مدول SessionStateModuleعملا" داده sessionرا ذخيره نمی نمايد . در واقع ، داده sessionدر عناصر مجزاء نگهداری می گردد كه به آنها stateproviderمی گويند .

نكته آخر در ارتباط با معماری فوق نحوه پيگيری كوكی از يك درخواست به درخواست ديگر است . برای اين كه session stateبه درستی كار كند ، سرويس گيرنده می بايست شناسه sessionخود را همراه با هر درخواست ارائه نمايد . بدين منظور از دو روش مختلف استفاده می گردد .

•  استفاده از  كوكی : در اين حالت ، شناسه sessionاز طريق يك كوكی خاص  (ASP.NET_SessionId) كه ASP.NETبطور اتوماتيك و در زمان استفاده از مجموعه sessionآن را ايجاد می نمايد ، ارسال می گردد . گزينه فوق به صورت پيش فرض انتخاب می گردد و مشابه رويكردی است كه از آن در نسخه های اوليه ASP  استفاده می گرديد .
•  استفاده از URLsاصلاح شده : در اين حالت ، شناسه sessionاز طريق يك URLاصلاح شده خاص ارسال می گردد . گزينه فوق يك ويژگی جديد در ASP.NETاست و به پياده كنندگان اجازه می دهد در مواردی كه سرويس گيرنده از كوكی حمايت نمی نمايد ، از session stateدر برنامه های وب استفاده نمايند .

استفاده از session state
با استفاده از كلاس  System.Web.SessionState.HttpSessionState  كه در يك صفحه ASP.NETبه عنوان شی sessionاز قبل تعبيه شده پيش بينی شده است ، می توان با session stateارتباط برقرار كرد . نحوه اضافه كردن و بازيابی داده در مجموعه session stateهمانند  view stateاست .
مثلا" می توان يك Datasetرا در sessionقرار داد . كد زير نحوه انجام اين كار را نشان می دهد .

كد زير نحوه بازيابی و تبديل داده ذخيره شده در sessionرا نشان می دهد .

امكان دستيابی به session stateدر تمامی برنامه و برای كاربر جاری امكان پذير است . session stateبه دلايل متعددی ممكن است از بين رود :

• بستن و فعال كردن مجدد مرورگر توسط كاربر
• دستيابی به صفحه مشابه از طريق يك پنجره جداگانه مرورگر توسط كاربر
• اتمام تاريخ اعتبار sessionبه دليل عدم فعاليت كاربر در يك بازه زمانی خاص   ( مقدار پيش فرض 20 دقيقه )
• خاتمه دادن به عمر مفيد يك sessionاز طريق كد و توسط برنامه نويس  ( استفاده از متد Session.Abandon)

در دو مورد اول ، sessionهمچنان در حافظه باقی خواهد ماند چراكه سرويس دهنده وب از بستن مرورگر و يا تغيير پنجره توسط كاربر آگاهی ندارد . در چنين مواردی ، sessionآخرين لحظات عمر خود را در حافظه طی می نمايد و عملا" غيرقابل دسترس باقی می ماند تا زمانی كه عمر آن به اتمام رسد .
علاوه بر موارد فوق ، زمانی كه application domainمجددا" ايجاد گردد ، session stateحذف خواهد شد . فرآيند فوق در زمان بهنگام سازی برنامه و يا تغيير در تنظيمات پيكربندی انجام می شود .
همچنين به منظور حصول اطمينان از صحت عملكرد برنامه ، application domainبطور ادواری بازسازی می شود . در صورتی كه رويكرد فوق باعث بروز مسائلی می گردد ، می توان اطلاعات session stateرا به صورت out of processذخيره كرد ( در بخش بعد در اين رابطه توضيح خواهيم داد ) . در مدل نگهداری stateبه صورت out-of-process، اطلاعات sessionحتی با غيرفعال شدن application domainهمچنان باقی خواهند ماند .
جدول 1  ، متدها و خصلت های مختلف كلاس  HttpSessionStateرا نشان می دهد .

جدول 1  : متدها و خصلت های كلاس  HttpSessionState

در اين بخش و قبل از پرداختن به نحوه پيكربندی sessionدر برنامه های وب ، به بررسی يك نمونه مثال خواهيم پرداخت تا از اين رهگذر بتوانيم در عمل با متدها و خصلت های كلاس  HttpSessionStateبيشتر آشنا شويم . 
مثال
در اين مثال هدف آشنائی با نحوه ذخيره و بازيابی داده در sessionاست . بدين منظور يك شی با نام Articlesو شامل سه فيلد عمومی به شرح زير تعريف شده است  :

• Title: عنوان يك مقاله را در خود ذخيره می نمايد .
• Abstract: شرح مختصری از مقاله را در خود ذخيره می نمايد .

• ViewCount: تعداد  دفعات مشاهده يك مقاله را مشخص می نمايد .

شی فوق از يك  constructor  خاص استفاده می نمايد تا فرآيند ايجاد و مقداردهی آن به سادگی انجام شود .

 اشياء Articlesدر زمان استقرار صفحه در حافظه ايجاد و در session stateذخيره می گردند . در ادامه و پس از انتخاب يك آيتم توسط كاربر از طريق ليست موجود ، شی مرتبط با آيتم انتخاب شده از sessionبازيابی و اطلاعات مرتبط با آن در خروجی نمايش داده می شود .

حتی المقدور می بايست از تعداد sessionاندكی در برنامه استفاده گردد چراكه مديريت آنها مستلزم انجام عمليات اضافه و استفاده از منابع محدود موجود در سمت سرويس دهنده است . پياده كنندگان برنامه های وب برای رفع اين نگرانی می توانند يك دكمه Log outرا در صفحه مورد نظر خود پيش بينی نمايند تا پس از كليك  بر روی آن ، با استفاده از متد  Session.Abandonاقدام به حذف sessionگردد ( آزاد سازی حافظه سرويس دهنده زودتر از موعد مقرر و مشخص شده توسط خصلت Timeout) .

در اين بخش با نحوه پيكربندی sessionدر برنامه های وب آشنا خواهيم شد.
پيكربندی sessionدر برنامه های وب
پياده كنندگان برنامه های وب برای پيكربندی session stateمی توانند از فايل web.config( موجود در دايركتوری مجازی شامل فايل های aspx. ) استفاده نمايند .  با استفاده از فايل فوق می توان گزينه های پيشرفته ای  نظير  timeoutو مد session stateرا پيكربندی كرد . در صورتی كه از ويژوال استوديو برای ايجاد يك برنامه وب استفاده شده باشد ، همزمان با ايجاد پروژه ، بطور اتوماتيك يك فايل web.config  نيز ايجاد می گردد . 
كد زير يك نمونه فايل web.configرا به همراه مهمترين خصلت های تاثيرگذار در پيكربندی session stateرا نشان می دهد .

در ادامه به تشريح هر يك از  خصلت های فوق خواهيم پرداخت .
Cookieless
مقدار خصلت فوق بر اساس شرايط زير تعيين می گردد .

• UseCookies: گزينه پيش فرض است و همواره از كوكی استفاده خواهد شد حتی اگر مرورگر و يا دستگاه سرويس گيرنده از آن حمايت نكند و يا آن را غيرفعال كرده باشد . در صورتی كه دستگاه سرويس گيرنده از كوكی حمايت نكند ، اطلاعات sessionدر بين درخواست های متوالی گم می شود . چراكه هر درخواست يك IDجديد را خواهد گرفت . 
• UseUri: از كوكی صرفنظر از قابليت های مرورگر و يا دستگاه سرويس گيرنده استفاده نخواهد شد . در چنين مواردی ، شناسه sessionدر يك URLذخيره می گردد .
• UseDeviceProfile: معيار انتخاب ASP. NETجهت استفاده از cookielesssession، بررسی نتايج حاصل از بكارگيری شی BrowserCapabilitiesاست . شی فوق صرفا" پتانسيل هائی را  كه دستگاه مورد نظر از آنها حمايت می نمايد مشخص می كند ( خود را درگير مواردی نظير غيرفعال كردن كوكی توسط كاربر نمی كند )  .
• AutoDetect: در اين روش ، در آغاز ASP. NETسعی می كند تشخيص دهد كه آيا مرورگر از كوكی حمايت می نمايد . بدين منظور يك كوكی بر روی كامپيوتر سرويس گيرنده ايجاد و در ادامه آن را بازيابی می نمايد . ماحصل فرآيند فوق می تواند اين موضوع را به اثبات رساند كه مرورگر از كوكی حمايت می نمايد ولی توسط كاربر غير فعال شده است ( در چنين مواردی از مد cookielessاستفاده می گردد )

كد زير بر استفاده از مد cookieless تاكيد می نمايد ( مناسب برای تست ) .

در مد cookieless، شناسه sessionبطور اتوماتيك درون يك URLقرار می گيرد . زمانی كه ASP. NETيك درخواست را دريافت می نمايد ، شناسه آن را حذف ، مجموعه sessionرا بازيابی و درخواست دريافتی را برای دايركتوری مورد نظر ارسال می نمايد .
با توجه به اين كه شناسه sessionدرون URLجاری قرار می گيرد ، لينك های مربوطه نير بطور اتوماتيك قادر به استفاده از شناسه session خواهند بود . به عبارت ديگر ، در صورتی كه كاربر بر روی page1.aspxباشد و بر روی لينك مربوط به page2.aspxكليك نمايد ، لينك مربوطه شامل شناسه sessionجاری به عنوان بخشی از URLمورد نظر خواهد بود .  سناريوی فوق در مواردی كه از متد Response.Redirectبه همراه يك URLنسبی استفاده شده باشد نيز صدق می كند .

مثال  
در اين مثال با نحوه  استفاده از  session  آشنا خواهيم شد . بدين منظور از دو صفحه با مد  cookielessاستفاده شده است ( در فايل web.config  مقدار   cookielessمعادل " UseUri" در نظر گرفته شده است ) . اولين صفحه ( Cookieless1.aspx) شامل يك كنترل  Hyperlinkو دو دكمه است . دومين صفحه ( Cookieless1.aspx) ، صفحه ای است كه كاربر پس از كليك بر روی يكی از گزينه های موجود به آن هدايت شده و پس از بازيابی session، اطلاعات در خروجی نمايش داده  می شود .
شكل 1 ، نحوه عملكرد صفحه Cookieless1.aspxرا نشان می دهد .

شكل 1 ، نحوه عملكرد صفحه Cookieless1.aspx 

• لينك به همراه مسير نسبی : خصلت Hyperlink.NavigateUrlاز طريق كد مقدار  Cookieless1.aspxرا می گيرد. در صورت كليك بر روی لينك فوق ،  شناسه sessionبازيابی و می توان از  اطلاعات sessionدر صفحه جديد ( Cookieless2.aspx) استفاده كرد .
• تغيير مسير ( مسير نسبی ) : تعيير مسير از طريق كد  با مد cookieless  نيز كار می كند ( همانند بكارگيری يك مسير نسبی ) . در مثال فوق از متد Response. Redirectبرای هدايت كاربر به صفحه Cookieless2.aspxاستفاده شده است .  در صورت كليك بر روی دكمه فوق ،  شناسه sessionبازيابی و امكان استفاده از  اطلاعات sessionدر صفحه جديد فراهم می گردد . كد زير نحوه انجام اين  كار را نشان می دهد .

• تغيير مسير ( مسير مطلق ) : تنها محدوديت cookieless، عدم امكان استفاده از لينك های absoluteاست . چراكه ASP. NETنمی تواند شناسه sessionرا درون آنها قرار دهد . مثلا" در صورتی كه بر روی دكمه دوم كليك شود ، امكان استفاده از sessionجاری در صفحه Cookieless2.aspxوجود نخواهد داشت . كد زير نحوه انجام اين كار را نشان می دهد .

كد صفحات   Cookieless1.aspxو  Cookieless2.aspxدر جداول زير نشان داده شده است .

صفحه Cookieless1.aspx

<%@ Page Language="VB" Culture="fa-IR" UICulture="fa-IR" %> <script runat="server">  Protected Sub cmdLink_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles cmdLink.Click   Response.Redirect("Cookieless2.aspx")  End Sub  Protected Sub cmdLinkAbsolute_Click(ByVal sender As Object,  ByVal e As System.EventArgs)     Dim url As String = "http://" & Request.Url.Authority & Request.Url.Segments(0) &_                             Request.Url.Segments(1) & "Cookieless2.aspx"     Response.Redirect(url)  End Sub  Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load   Session("test") = "Test String"  End Sub </script> <html xmlns="http://www.w3.org/1999/xhtml" dir="rtl" >  <head id="Head1" runat="server">      <title>تستsession </title> </head> <body style="font-family: Tahoma">  <form id="form1" runat="server">    <div>       <strong> تستsession     <br /> </strong>      <br />     <asp:HyperLink id="lnkRedirect" runat="server" Width="191px" Height="25px"               NavigateUrl="Cookieless2.aspx">لينك به همراه مسير نسبی</asp:HyperLink><br />      <br />      <asp:Button id="cmdLinkAbsolute" runat="server" Width="183px"            Text="تغيير مسير(مسير مطلق)" Font-Names="Tahoma" Font-Size="Small" ></asp:Button><br /><br />      <asp:Button id="cmdLink" runat="server" Width="187px"            Text="تغيير مسير ( مسيرنسبی) " Font-Names="Tahoma" Font-Size="Small" ></asp:Button>   </div>  </form> </body> </html>

صفحه Cookieless2.aspx

<%@ Page Language="VB" Culture="fa-IR" UICulture="fa-IR" %>  <script runat="server"> Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load  If Session("test") Is Nothing Then     lblInfo.Text = "اطلاعاتsession موجود نمی باشد"  Else     lblInfo.Text = "اطلاعاتsession با موفقيت بازيابی گرديد" & CType(Session("test"), String)  End If End Sub </script> <html xmlns="http://www.w3.org/1999/xhtml" dir="rtl" > <head id="Head1" runat="server">     <title>Untitled Page</title>  </head> <body style="font-family: Tahoma"> <form id="form1" runat="server">   <div>       <asp:Label ID="lblInfo" runat="server" Font-Bold="True"                        Font-Names="Tahoma" Font-Size="Small"                        Height="52px" Style="z-index: 101; left: 488px; position: absolute; top: 25px"                        Width="353px" ForeColor="#C04000"></asp:Label>   </div>  </form>  </body> </html>

به صورت پيش فرض ، ASP. NETامكان استفاده مجدد از يك شناسه sessionرا فراهم می نمايد. مثلا" در صورتی كه درخواستی ايجاد و query stringشامل يك sessionباشد كه مدت زمان اعتبار آن به پايان رسيده باشد ، ASP. NETيك sessionجديد را ايجاد و از شناسه sessionاستفاده می نمايد .
مشاهده ناخودآگاه يك شناسه sessionدر يك مكان عمومی نظير نتايج ارائه شده توسط يك موتور جستجو يكی از چالش های مهم روش فوق محسوب می گردد كه ممكن است زمينه دستيابی چندين كاربر به سرويس دهنده با استفاده از شناسه sessionمشابه را فراهم نمايد .
برای پيشگيری از اين تهديد امنيتی ، می بايست از خصلت regenerateExpiredSessionIdبا مقدارtrueاستفاده شود  ( زمانی كه از session  با مد cookielessاستفاده شده باشد ) . در چنين مواردی ، در صورتی كه يك كاربر با يك شناسه sessionكه تاريخ اعتبار آن به اتمام رسيده است به سرويس دهنده متصل شده باشد ، يك شناسه sessionجديد برای وی ايجاد خواهد شد .  تنها نكته قابل تامل در اين روش ، از دست دادن مقادير موجود در view sateو داده موجود در فرم  است ، چراكه ASP. NETبرای حصول اطمينان از اين موضوع كه مرورگر دارای يك شناسه جديد sessionاست ، عمليات redirectرا انجام خواهد داد . 
Timeout
يكی ديگر از تنظيمات مهم در ارتباط با  session state، مشخص كردن مدت زمان timeoutاست . مقدار در نظر گرفته شده برای خصلت فوق ( تعريف شده در فايل web.config) ، مدت زمان انتظار ASP.NET قبل از حذف sessionرا مشخص می كند ( عدم دريافت هيچگونه درخواست در بازه زمانی مشخص شده ) .
در نمونه كد زير به ASP.NETاعلام شده است كه اگر پس از گذشت 20 دقيقه درخواستی از سرويس گيرنده دريافت نگرديد ، sessionآن را حذف كن .

خصلت فوق يكی از مهمترين پارامترهای مديريت sessionدر برنامه های وب است كه عدم مقداردهی مناسب آن می تواند نتايج نامطلوبی را در ارتباط با كارآئی يك برنامه وب به دنبال داشته باشد . در زمان مقداردهی پارامتر فوق می بايست به اين نكته دقت شود كه اولا" زمان در نظر گرفته شده به اندازه ای كوتاه باشد كه سرويس دهنده بتواند پس از سپری شدن مدت زمان اندكی كه كاربر از برنامه استفاده نمی نمايد ، منبع ارزشمند حافظه را آزاد نمايد  و  ثانيا" كاربر بتواند بدون نگرانی در خصوص از دست دادن sessionخود با خيالی آسوده از برنامه استفاده نمايد .
در صورت نياز ، می توان مقداردهی پارامتر فوق را از طريق كد نيز انجام داد . به عنوان نمونه در مواردی كه يك sessionحاوی يك حجم غيرمتعارف از اطلاعات باشد ، می توان مدت زمان حيات sessionرا محدودتر كرد . كد زير نحوه تغيير مقدار پارامتر فوق را به 10 دقيقه نشان می دهد .

Mode
با استفاده از خصلت modeمی توان نحوه ذخيره سازی اطلاعات session  را مشخص كرد . به اين خصلت می توان  مقاديری نظير InProc، off، StateServer، SQLServerو Customرا نسبت داد . در واقع به كمك خصلت فوق  ، استراتژی ذخيره سازی اطلاعات sessionمشخص می گردد .
 در ادامه با هر يك از موارد فوق بيشتر آشنا خواهيم شد . قبل از آن لازم است به يك نكته مهم اشاره گردد . در صورتی كه برنامه ASP.NETبر روی بيش از يك سرويس دهنده وب هاست شده باشد  ( كه از آن با نام web farmياد می شود ) ، می بايست دامنه پيكربندی را گسترش داد تا اين اطمينان ايجاد شود كه سرويس دهندگان وب همساز می باشند . در غيراينصورت ، ممكن است يك سرويس دهنده اطلاعات موجود در sessionرا با روشی متفاوت نسبت به سرويس دهنده ديگر ، رمز نمايد . بديهی است در چنين مواردی اگر كاربر از يك سرويس دهنده به سرويس دهنده ديگر هدايت شود ، در sessionوی اختلال ايجاد خواهد شد . برای حل اين مشكل می بايست با مراجعه به بخش <machineKey>  فايل machine.config  تنظميات مورد نظر را بگونه ای انجام داد كه شيوه رمزنگاری sessionبر روی يك سرويس دهنده با سرويس دهنده ديگر يكسان و سازگار باشد .
 InProc
مقدار پيش فرض خصلت modeمی باشد و  عملكرد آن همانند ذخيره سازی session stateدر نسخه های قديمی ASPاست . در اين روش اطلاعات در پردازه مشابه ASP.NET worker threads  ذخيره می گردند . اين روش بالاترين كارآئی و كمترين ماندگاری  را دارد . در صورتی كه سرويس دهنده به هر دليلی راه اندازی مجدد گردد ، اطلاعات sessionاز بين خواهند رفت . روش فوق برای اكثر وب سايت های كوچك مناسب است . در مواردی كه برنامه وب در يك web farmهاست شده باشد ، از اين روش نمی توان استفاده كرد . در چنين مواردی و به منظور به اشتراگ گذاشتن اطلاعات sessionبين چندين سرويس دهنده ، می بايست از  گزينه  Out-of-Processو يا سرويس SQL Serverstateاستفاده كرد . 
در برخی موارد ممكن است  برنامه نويسان به اين نتيجه رسيده باشند كه كاربران اطلاعات sessionخود را بدون هيچگونه دليلی از دست می دهند . همين امر باعث می شود كه آنان استفاده از گزينه ای غير از InProcرا در دستور كار قرار دهند .  در ASP.NET، حوزه  برنامه ها به دلايل متعددی ممكن است راه اندازی مجدد گردد ( نظير اعمال تغييرات در پيكربندی ، بهنگام سازی صفحات ) . 
توجه داشته باشيد ، در زمان استفاده از  StateServerو يا SQLServer، اشيائی می توانند در  sessionstate  ذخيره گردند كه قابليت سريال شدن را داشته باشند . در غيراينصورت ، ASP.NETقادر به انتقال و يا ارسال اشياء به state serviceو يا ذخيره آنها در بانك اطلاعاتی نخواهد بود .
 off
با انتخاب مقدار فوق برای خصلت mode، مديريت stateدر تمامی صفحات يك برنامه وب غيرفعال خواهد شد . بديهی است با غيرفعال كردن sessionشاهد بهبود ملموس كارآئی در وب سايت هائی خواهيم بود كه عملكرد و سرويس دهی آنها مشروط به استفاده از session نمی باشد . 
StateServer
با در نظر گرفتن مقدار فوق برای خصلت mode، از يك سرويس ويندوز جداگانه برای مديريت stateاستفاده می گردد . سرويس فوق بر روی سرويس دهنده مشابه اجراء می گردد ولی در خارج از پردازه اصلی ASP.NETقرار می گيرد . رويكرد فوق دارای مزايا و معايب مختص به خود می باشد . مهمترين مزيت استفاده از يك سرويس دهنده ديگر برای ذخيره اطلاعات session، عدم وابستگی آن به پردازه ASP.NETاست . در چنين مواردی با راه اندازی مجدد پردازه ASP.NET( به هر دليل ) ، اختلالی در داده ذخيره شده در sessionايجاد نخواهد شد چراكه آنها در يك سرويس دهنده جداگانه نگهداری شده اند . از مهمترين معايب و يا بهتر بگوئيم محدوديت های رويكرد فوق ، افزايش تاخير زمانی در زمان ارسال اطلاعات sessionبين دو پردازه است . بديهی است در صورتی كه فركانس دستيابی و تغيير اطلاعات ذخيره شده در sessionبالا باشد ، سرعت و كارآئی يك برنامه وب كاهش می يابد.
در زمان استفاده از StateServer، می بايست مقدار  stateConnectionStringرا مشخص كرد . پارامتر فوق ، آدرس  IPكامپيوتری را كه بر روی آن سرويس StateServerاجراء شده است را به همراه شماره پورت مربوطه مشخص می نمايد ( شماره پورت توسط ASP.NETتعيين می گردد و معمولا" لزومی به تغيير آن وجود ندارد ) . بدين ترتيب ، می توان StateServerرا بر روی كامپيوتر ديگر هاست كرد . در صورتی كه قصد تغيير تنظيمات پيش فرض را نداشته باشيم ، از سرويس دهنده محلی استفاده خواهد شد ( با آدرس IP : 127.0.0.1 ) .    
قبل از اين كه برنامه وب بتواند از سرويس فوق استفاده نمايد ، می بايست آن را اجراء كرد . ساده ترين روش برای انجام اين كار انتخاب گزينه Servicesاز طريق  Control Panel  است . با مشاهده ASP.NET State Serviceدر ليست سرويس ها ، می توان نحوه اجراء آن را مشخص نمود ( بطور اتوماتيك ) .
در مواردی كه از StateServerاستفاده می گردد ، می توان برای خصلت اختياری  stateNetworkTimeout  يك مقدار را مشخص نمود .  پارامتر فوق ، حداكثر مدت زمان انتظار برای پاسخ سرويس دهنده بر حسب ثانيه را مشخص می نمايد . مقدار گزينه پيش فرض ، 10 ثانيه است .
SQLServer
با در نظر گرفتن مقدار فوق برای خصلت mode،  از يك بانك اطلاعاتی SQLServerبرای ذخيره اطلاعات session  استفاده می گردد . بانك اطلاعاتی مورد نظر توسط خصلت sqlConnectionStringمشخص می گردد . روش فوق متداولترين مكانيزم برای ذخيره stateدر برنامه های وب می باشد ولی در مقايسه با روش های ديگر از سرعت كمتری برخوردار است .
برای استفاده از روش فوق می بايست از يك سرويس دهنده SQLاستفاده شود . مقدار خصلت sqlConnectionString، همانند الگوی استفاده شده جهت دستيابی به داده توسط ADO. NETاست و شامل مشخص كردن يك منبع داده ( آدرس سرويس دهنده ) ، يك رمزعبور و شناسه كاربر ( مگر اين كه از  integrated securityاستفاده شده باشد ) است . علاوه بر اين ، می بايست stored procedures  و sessionموقت بانك اطلاعاتی نصب گردند . stored proceduresمسئوليت ذخيره و بازيابی اطلاعات sessionرا برعهده دارند .
ASP.NETشامل يك اسكريپت Transact-SQLبرای اين هدف خاص با نام  InstallSqlState.sql  است  كه در
مسير [ C:\[WinDir]\Microsoft.NET\Framework\[Version قرار دارد .  برای اجرای اسكريپت فوق می توان از يك برنامه كاربردی SQLServerنظير SQL Server Management Studioيا sqlcmd.exe( برای سرويس SQL 2005  )  و يا OSQL.exeو Query Analyze( برای نسخه های قبلی ) استفاده كرد . اسكريپت فوق صرفا" يك مرتبه و به منظور ايجاد بانك ، جداول و  stored procedures   مورد نياز اجراء خواهد شد .
نام بانك اطلاعاتی معمولا"  ASPStateمی باشد .در واقع ، connection stringموجود در فايل web.config  با صراحت نام بانك اطلاعاتی را مشخص نخواهد كرد بلكه صرفا" مكان سرويس دهنده و نوع تائيديه مشخص می گردد . كد زير نحوه انجام اين كار را نشان می دهد .

در صورتی كه قصد استفاده از يك بانك اطلاعاتی با نام ديگر  و ساختار مشابه را داشته باشيم ، كافی است مقدار خصلت  CustomSqlDatabase  برابر با true  در نظر گرفته شود .

زمانی كه از يك بانك اطلاعاتی SQL Serverبرای ذخيره اطلاعات sessionاستفاده می گردد ، می توان از گزينه اختياری sqlCommandTimeoutاست كرد .  پارامتر فوق ، حداكثر مدت زمان انتظار برای پاسخ سرويس دهنده بر حسب ثانيه را مشخص می نمايد . مقدار گزينه پيش فرض ، 30 ثانيه است .

Custom
زمانی كه برای خصلت modeمقدار custom  در نظر گرفته  می شود  ، می بايست session state providerرا با استفاده از خصلت customProvider  مشخص كرد . خصلت فوق به نام يك كلاس كه بخشی از برنامه وب موجود در دايركتوری App_Code  است و يا يك اسمبلی كمپايل شده موجود در دايركتوری BINو يا GAC ،  اشاره می نمايد .
ايجاد يك providerسفارشی ، مسائل مختص به خود را دارد و می بايست با دقت

پياده سازی گردد تا بتواند اهدافی نظير امنيت و قابليت توسعه را به خوبی تامين نمايد .  بحث بر روی provider سفارشی خارج از حوصله اين مقاله است .
برخی توليد كنندگان ممكن است نسخه هائی خاص از state providerرا ارائه نمايند كه در صورت نياز و تمايل می توان از آنها استفاده كرد . به عنوان مثال ، اوراكل ممكن است يك providerسفارشی را ارائه نمايد كه امكان ذخيره اطلاعات  sessionرا در يك بانك اطلاعاتی اوراكل فراهم نمايد . 
در اين بخش با application stateآشنا می شويم .
با استفاده از application stateمی توان اشياء سراسری ( global)  را با هدف دستيابی توسط هر يك از سرويس گيرندگان ذخيره كرد . عملكرد application stateبر اساس كلاس  System.Web.HttpApplicationStateمی باشد  كه بطور پيش فرض از طريق شی از قبل تعبيه شده Applicationدر تمامی صفحات قابل استفاده است .
طرز كار application stateمشابه session stateاست و  از اشيائی با نوع های مشابه ، نگهداری اطلاعات در سمت سرويس دهنده و گرامر مبتنی بر ديكشنری استفاده می نمايد . استفاده از يك شمارنده سراسری  به منظور نگهداری تعداد دفعاتی كه يك عمليات خاص توسط تمامی سرويس گيرندگان يك برنامه وب انجام می شود ، يك نمونه متداول استفاده از application state  می باشد  .
مثلا" می توان يك event handlerدر فايل global.asaxرا تعريف كرد تا تعداد session ايجاد شده و يا  تعداد درخواست های دريافتی توسط يك برنامه را ثبت كند . همچنين ، می توان از روشی مشابه در Page. Loadبه منظور تعيين تعداد دفعاتی كه يك صفحه خاص توسط سرويس گيرندگان مختلف درخواست شده است ، استفاده كرد .
كد زير نحوه انجام اين كار را مشخص می كند .

لازم است مجددا" به اين نكته اشاره گردد كه آيتم های application stateبه عنوان شی ذخيره می گردند ، بنابراين می بايست در زمان بازيابی آنها را castكرد . تاريخ اعتبار و يا مصرف آيتم های ذخيره شده در application stateهرگز به اتمام نخواهد رسيد و تا زمانی كه برنامه و يا سرويس دهنده راه اندازی مجدد نگردد و يا حوزه برنامه خود را refreshننمايد ( به علت تنظيمات ادواری اتوماتيك پردازه و يا بهنگام سازی يكی از صفحات و يا عناصر موجود در برنامه ) ، امكان استفاده از آنها وجود خواهد داشت .
امروزه اغلب از application stateبه دليل عدم كارآئی مناسب  استفاده نمی شود . در مثال قبل ، همواره اين احتمال وجود خواهد داشت كه در شمارنده مقدار درستی ذخيره نگردد ( خصوصا" در مواردی كه ترافيك بالا باشد ) . به عنوان مثال ، در صورتی كه دو سرويس گيرنده در يك زمان مشابه صفحه ای را درخواست نمايند ، دارای مجموعه ای از رويدادها به شرح ذيل خواهيم بود :

• كاربر Aمقدار جاری شمارنده را ( فرضا" عدد 432 ) بازيابی می نمايد .
• كاربر Bمقدار جاری شمارنده را ( فرضا" عدد 432 ) بازيابی می نمايد .
• كاربر Aمقدار شمارنده را تغيير و آن را به 433 تغيير می دهد .
• كاربر B  مقدار شمارنده را تغيير و آن را به 433 تغيير می دهد .

به عبارت ديگر ، يكی از درخواست ها باعث افزايش شمارنده نمی گردد ، چراكه دو سرويس گيرنده بطور همزمان به شمارنده دستيابی داشته اند . برای پيشگيری از بروز اين مسئله ، می بايست از متدهای Lockو Unlockاستفاده كرد . با استفاده از متدهای فوق در هر لحظه صرفا" به يك سرويس گيرنده اجازه دستيابی به مجموعه application state  داده می شود . 

ساير سرويس گيرندگانی كه صفحه را درخواست می نمايند می بايست تا زمانی كه مجموعه applicationstateآزاد نشده است ، منتظر بمانند . اين وضعيت می تواند كاهش كارآئی برنامه را به دنبال داشته باشد .
به عنوان يك قانون كلی ، مقاديری كه دائما" و با فركانس بالا تغيير می يابند نمی توانند كانديدی مناسب جهت استفاده از application stateباشند .
applicationstateدر دنيای دات نت بندرت استفاده می شود چراكه دو كاربرد متداول استفاده از آن با روش های موثرتر ديگر جايگزين شده است .

• در گذشته ، از application stateبرای ذخيره ثوابت در سطح برنامه نظير يك connection stringبانك اطلاعاتی استفاده می گرديد . هم اينك در دات نت می توان اين نوع ثوابت را به سادگی در فايل web.configكه به مراتب از انعطاف بيشتری برخوردار است ذخيره نمود .
• در گذشته برای ذخيره اطلاعاتی كه در يك برنامه از آنها بدفعات استفاده می گرديد و برای توليد اين اطلاعات زمان زيادی صرف می گرديد ، استفاده می شد ( نظير يك كاتولوگ كامل از محصولات ) . افزايش حجم كاتالوگ و  معتبر سازی داده موجود در اينچنين كاتالوگ هائی ، همواره از مشكلات برنامه نويسان بوده است . هم اينك و با استفاده از دات نت می توان از فنآوری cacheكه دارای كارآئی بمراتب بالاتری نسبت به روش های پيشين و بكارگرفته شده در application stateاست ، استفاده كرد .

 فايل Global.asax
با استفاده از فايل global.asaxمی توان كد مورد نياز جهت برخورد با رويدادهائی در سطح برنامه را ايجاد كرد . رويدادهای فوق در نقاط مختلفی از چرخه حيات يك برنامه وب محقق می گردند ( مثلا" زمانی كه sessionايجاد می گردد ) . همين موضوع باعث شده است كه فايل global.asax  بتواند در تعامل مناسب با ويژگی های state managementقرار بگيرد . مثلا" می توان از فايل global.asaxبرای مقداردهی اوليه مجموعه ای از اشياء كه قصد داريم آنها را در  applicationstateذخيره نمائيم ، استفاده كرد .
فايل global.asax، همانند يك فايل aspx  . است . با اين تفاوت كه اين نوع فايل ها نمی توانند شامل تگ های HTMLو يا ASP. NETباشند . در مقابل می توان در آنها event handlerمورد نياز را قرار داد . مثلا" فايل global.asaxزير در مقابل رويداد Application.EndRequestاز خود واكنش نشان می دهد ( رويدادی كه قبل از ارسال صفحه برای كاربر محقق می گردد ) .

eventhandler  فوق از متد writeشی از قبل تعبيه شده Responseبرای نوشتن يك footerدر پائين صفحه ( تاريخ و زمان ايجاد صفحه ) استفاده می نمايد .
هر برنامه ASP.NETمی تواند دارای يك فايل global.asaxباشد كه پس از استقرار در دايركتوری مجازی مربوطه ، ASP.NETآن را بطور اتوماتيك تشخيص و از آن استفاده خواهد كرد . مثلا" ، اگر فايل global.asaxفوق را در يك دايركتوری مجازی قرار دهيم ، شاهد نمايش يك footerدر پائين هر يك از صفحات موجود در برنامه خواهيم بود .
اضافه كردن يك footer  اتوماتيك در پائين صفحات ، يك عمليات مفيد برای سايت های حرفه ای نمی باشد . نوشتن يك ركورد در يك بانك اطلاعاتی مختص ثبت وقايع ( log) ، شايد كاربرد مناسب تری از ويژگی فوق را نشان دهد . هم اينك تعداد زيادی از برنامه نويسان برنامه های وب تمايل به  استفاده از فايل global.asaxرا ندارند . فايل فوق از مدل code-behindحمايت می نمايد  .
رويدادهای Application
Application.EndRequest، صرفا" يكی از رويدادهای موجود جهت استفاده در فايل global.asaxاست . برای ايجاد يك event handler  متفاوت ، می توان يك روتين با نام دلخواه را ايجاد كرد .
برخی از متداولترين رويدادهای application  عبارتند از :

• Application_Start: در زمان آغاز به كار برنامه و دريافت اولين درخواست توسط هر يك از كاربران ، محقق می گردد . رويداد فوق در پاسخ به درخواست های بعدی محقق نخواهد شد . از اين رويداد معمولا" برای ايجاد و يا cacheبرخی اطلاعات اوليه  استفاده  می شود.
•  Application_End: رويداد فوق پس از اتمام فعاليت برنامه ، محقق می گردد ( عمدتا" زمانی كه سرويس دهنده وب راه اندازی مجدد می گردد ) . در روتين مربوطه می توان كد مورد نياز برای پاكسازی را درج كرد .
•  Application_BeginRequest: رويداد فوق پس از دريافت هر درخواست توسط برنامه ، محقق می گردد  ( قبل از اجرای كد صفحه )  .
• Application_EndRequest: رويداد فوق پس از دريافت هر درخواست توسط برنامه ، محقق می گردد  ( پس از اجرای كد صفحه )  .
• Session_Start: رويداد فوق زمانی محقق می گردد كه درخواست يك كاربر جديد دريافت و يك sessionفعاليت خود را آغاز نمايد .
• Session_End  : رويداد فوق زمانی محقق می گردد كه  مدت زمان حيات يك sessionبه اتمام رسيده باشد ( از طريق كد و يا بطور اتوماتيك ) . 
• Application_Error: رويداد فوق در پاسخ به يك خطاء غيرقابل پيش بينی،  محقق می گردد .

جمع بندی :
statemanagement، فرآيندی است كه به كمك آن می توان اطلاعاتی را بين درخواست های متعدد ، نگهداری كرد . اطلاعات فوق معمولا" شامل دو دسته می باشند :

• اطلاعات در ارتباط با يك كاربر : نظير ليست كالاهای موجود در يك سبد خريد ، نام كاربر و يا يك سطح دستيابی خاص
• اطلاعات قابل استفاده در تمامی برنامه : نظير  آمارهائی كه فعاليت هائی خاص از يك سايت را ثبت می نمايد .

با توجه به اين كه ASP.NETاز يك معماری disconnectedاستفاده می نمايد ، لازم است كه با هر درخواست اطلاعات stateذخيره و آنها را در زمان مورد نياز بازيابی كرد .
استراتژی انتخاب شده  برای ذخيره سازی stateمی تواند بطرز كاملا" محسوسی بر روی پارامترهائی نظير كارآئی ، قابليت گسترش و  امنيت يك برنامه وب تاثيرگذار باشد .
از اطلاعات مندرج در جدول زير می توان به منظور بررسی روش های مختلف مديريت stateو انتخاب گزينه ای مطلوب كه پاسخگوی نياز يك برنامه است ،  استفاده كرد .

 جدول 1 : مقايسه روش های مختلف state management