بخشی از مقاله

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


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


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


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

كارآئی آن تاثير بگذارد . چراكه درصد استفاده از يك منبع محدود ( حافظه ) افزايش خواهد يافت . بنابراين ، لازم است استفاده از session state با دقت و بررسی تمامی جوانب كار صورت پذيريد .
معماری 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 ، يكی از مدول های موجود در اين زنجيره است ( موجود در n

amespace با نام System.Web.SessionState ) . مدول فوق شناسه session را توليد ، داده session را از ارائه دهندگان خارجی state بازيابی و داده را به درخواست مورد نظر نسبت می دهد . همچنين مدول فوق ، اطلاعات مربوط به session را پس از اتمام پردازش صفحه ، ذخيره می نمايد.
توجه داشته باشيد كه مدول SessionStateModule عملا" داده session را ذخيره نمی نمايد . در واقع ، داده session در عناصر مجزاء نگهداری می گردد كه به آنها state provider می گويند .
شكل 1 معماری session state در ASP.NET را نشان می دهد .

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

استفاده از session state
با استفاده از كلاس System.Web.SessionState.HttpSessionState كه در يك صفحه ASP.NET به عنوان شی session از قبل تعبيه شده پيش بينی شده است ، می توان با session state ارتباط برقرار كرد . نحوه اضافه كردن و بازيابی داده در مجموعه session state همانند view state است .
مثلا" می توان يك Dataset را در session قرار داد . كد زير نحوه انجام اين كار را نشان می دهد .
Session("ds") = ds
كد زير نحوه بازيابی و تبديل داده ذخيره شده در session را نشان می دهد .
ds = Ctype(Session("ds"),DataSet)
امكان دستيابی به 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 را نشان می دهد

در بخش نهم بحث خود را در ارتباط با session state ادامه داده و به بررسی يك نمونه مثال كاربردی خواهيم پرداخت
________________________________________
State Management در ASP. NET 2.0 (بخش اول)
2در بخش هشتم با مفاهيم و معماری session آشنا شديم . در اين بخش و قبل از پرداختن به نحوه پيكربندی session در برنامه های وب ، به بررسی يك نمونه مثال خواهيم پرداخت تا از اين رهگذر بتوانيم در عمل با متدها و خصلت های كلاس HttpSessionState بيشتر آشنا شويم .
مثال
در اين مثال هدف آشنائی با نحوه ذخيره و بازيابی داده در session است . بدين منظور يك شی با نام Articles و شامل سه فيلد عمومی به شرح زير تعريف شده است :
• Title : عنوان يك مقاله را در خود ذخيره می نمايد .
• Abstract : شرح مختصری از مقاله را در خود ذخيره می نمايد .
• ViewCount : تعداد دفعات مشاهده يك مقاله را مشخص می نمايد .
شی فوق از يك constructor خاص استفاده می نمايد تا فرآيند ايجاد و مقداردهی آن به سادگی انجام شود .
Public Class Articles

Public Title As String
Public Abstract As String
Public ViewCount As Integer

Public Sub New(ByVal Title As String, ByVal Abstract As String, ByVal ViewCount As Integer)
Me.Title = Title
Me.Abstract = Abstract


Me.ViewCount = ViewCount
End Sub

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

<%@ Page Language="VB" Culture="fa-IR" UICulture="fa-IR" %>

 

<script runat="server">

Public Class Articles
Public Title As String
Public Abstract As String
Public ViewCount As Integer
Public Sub New(ByVal Title As String, ByVal Abstract As String, ByVal ViewCount As Integer)
Me.Title = Title
Me.Abstract = Abstract
Me.ViewCount = ViewCount
End Sub
End Class
Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles MyBase.Load
If Me.IsPostBack = False Then
مرحله اول : ايجاد اشياء '
Dim ArticleInfo1 As New Articles("State Management در ASP. NET 2.0 (بخش هشتم) ", _
" بررسی Session State ", 43)
Dim ArticleInfo2 As New Articles("State Management در ASP. NET 2.0 (بخش هفتم) ", _
" كوكی های سفارشی و نحوه عملكرد آنها", 94)
Dim ArticleInfo3 As New Articles("State Management در ASP. NET 2.0 (بخش ششم) ", _
" نحوه انتقال اطلاعات بين صفحات با استفاده از Query String", 103)
Dim ArticleInfo4 As New Articles(" State Management در ASP. NET 2.0 (بخش پنجم) ", _
" نحوه دريافت اطلاعات از صفحه مبداء در cross-page posting", 99)
مرحله دوم : اضافه كردن اشياء به session state '
Session("Article1") = ArticleInfo1
Session("Article2") = ArticleInfo2
Session("Article3") = ArticleInfo3
Session("Article4") = ArticleInfo4
مرحله سوم :‌ اضافه كردن سطر به ليست '
lstItems.Items.Clear()
lstItems.Items.Add(ArticleInfo1.Title)
lstItems.Items.Add(ArticleInfo2.Title)


lstItems.Items.Add(ArticleInfo3.Title)
lstItems.Items.Add(ArticleInfo4.Title)

End If
نمايش برخی اطلاعات پايه در رابطه با session '
جهت بررسی اطلاعات پيكربندی '


Dim strCookieLess As String
Dim strNewSession As String

If Session.IsCookieless Then
strCookieLess = "بلی"
Else
strCookieLess = "خير"
End If

If Session.IsNewSession Then
strNewSession = "بلی"
Else
strNewSession = "خير"
End If

lblSession.Text = "شناسه : " & Session.SessionID
lblSession.Text &= "<br>تعداد اشياء : "
lblSession.Text &= Session.Count.ToString()
lblSession.Text &= "<br>مد : " & Session.Mode.ToString()
lblSession.Text &= "<br>آيا session ايجاد شده Cookieless است؟ "
lblSession.Text &= strCookieLess
lblSession.Text &= "<br> آيا session جديد است ؟ "
lblSession.Text &= strNewSession
lblSession.Text &= "<br> اعتبار session (بر حسب دقيقه ) : "
lblSession.Text &= Session.Timeout.ToString()
End Sub
Protected Sub cmdMoreInfo_Click(ByVal sender As Object, ByVal e As EventArgs) Handles cmdMoreInfo.Click
If lstItems.SelectedIndex = -1 Then
lblRecord.Text = "آيتمی انتخاب نشده است"


Else
مرحله اول :ايجاد نام كليد صحيح بر اساس ايندكس '
Dim Key As String
Key = "Article" & (lstItems.SelectedIndex + 1).ToString()
مرحله دوم : بازيابی اشياء از session state '
Dim ArticleInfo As Articles = CType(Session(Key), Articles)
مرحله سوم : نمايش اطلاعات مرتبط با شی بازيابی شده '
lblRecord.Text = "عنوان مقاله :" & ArticleInfo.Title
lblRecord.Text &= "<br>شرح: "


lblRecord.Text &= ArticleInfo.Abstract
lblRecord.Text &= "<br>تعداد دفعات مشاهده : " & ArticleInfo.ViewCount.ToString()

End If

End Sub

</script>

<html xmlns="http://www.w3.org/1999/xhtml" dir="rtl">
<head runat="server">
<title>تست session </title>
</head>
<body>
<form id="form1" runat="server">
<asp:Label id="lblSession" runat="server" Width="472px" Height="61px" Font-Size="Smaller"
Font-Names="Tahoma" Font-Bold="False"></asp:Label><br /><br />
<div >
<asp:ListBox id="lstItems" runat="server" Width="345px" Height="106px"
Font-Names="Tahoma"></asp:ListBox><br /> <br />
<asp:Button id="cmdMoreInfo" runat="server" Text="اطلاعات بيشتر "
Font-Names="Tahoma"></asp:Button><br /><br /><br />
<asp:Label id="lblRecord" runat="server" Font-Size="Small"
Font-Names="Tahoma" ></asp:Label>
</div>
</form>
</body>
</html>

شكل 1 نحوه عملكرد و خروجی برنامه فوق را نشان می دهد .



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

وه پيكربندی آن در برنامه های وب آشنا خواهيم شد .
________________________________________
State Management در ASP. NET 2.0 (بخش دوم)
آنچه تاكنون گفته شده است :
در اين بخش با نحوه پيكربندی session در برنامه های وب آشنا خواهيم شد.
پيكربندی session در برنامه های وب
پياده كنندگان برنامه های وب برای پيكربندی session state می توانند از فايل web.config ( موجود در دايركتوری مجازی شامل فايل های aspx . ) استفاده نمايند . با استفاده از فايل فوق می توان گزينه های پيشرفته ای نظير timeout و مد session state را پيكربندی كرد . در صورتی كه از ويژوال استوديو برای ايجاد يك برنامه وب استفاده شده باشد ، همزمان با ايجاد پروژه ، بطور اتوماتيك يك فايل web.config نيز ايجاد می گردد .
كد زير يك نمونه فايل web.config را به همراه مهمترين خصلت های تاثيرگذار در پيكربندی session state را نشان می دهد .
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
...
<sessionState
cookieless="UseCookies" cookieName="ASP.NET_SessionId"
regenerateExpiredSessionId="false"
timeout="20"


mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
stateNetworkTimeout="10"
sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI"
sqlCommandTimeout="30"
allowCustomSqlDatabase="false"
customProvider=""
/>
</system.web>
</configuration>


در ادامه به تشريح هر يك از خصلت های فوق خواهيم پرداخت .
Cookieless
مقدار خصلت فوق بر اساس شرايط زير تعيين می گردد .
• UseCookies : گزينه پيش فرض است و همواره از كوكی استفاده خواهد شد حتی اگر مرورگر و يا دستگاه سرويس گيرنده از آن حمايت نكند و يا آن را غيرفعال كرده باشد . در صورتی كه دستگاه سرويس گيرنده از كوكی حمايت نكند ، اطلاعات session در بين درخواست های متوالی گم می شود . چراكه هر درخواست يك ID جديد را خواهد گرفت .
• UseUri : از كوكی صرفنظر از قابليت های مرورگر و يا دستگاه سرويس گيرنده استفاده نخواهد شد . در چنين مواردی ، شناسه session در يك URL ذخيره می گردد .
• UseDeviceProfile : معيار انتخاب ASP. NET جهت استفاده از cookieless session ، بررسی نتايج حاصل از بكارگيری شی BrowserCapabilities است . شی فوق صرفا" پتانسيل هائی را كه دستگاه مورد نظر از آنها حمايت می نمايد مشخص می كند ( خود را درگير مواردی نظير غيرفعال كردن كوكی توسط كاربر نمی كند ) .
• AutoDetect : در اين روش ، در آغاز ASP. NET سعی می كند تشخيص دهد كه آيا مرورگر از كوكی حمايت می نمايد . بدين منظور يك كوكی بر روی كامپيوتر سرويس گيرنده ايجاد و در ادامه آن را بازيابی می نمايد . ماحصل فرآيند فوق می تواند اين موضوع را به اثبات رساند كه مرورگر از كوكی حمايت می نمايد ولی توسط كاربر غير فعال شده است ( در چنين مواردی از مد cookieless استفاده می گردد )
كد زير بر استفاده از مد cookieless تاكيد می نمايد ( مناسب برای تست ) .
<sessionState cookieless="UseUri" ...="" />
در مد cookieless ، شناسه session بطور اتوماتيك درون يك URL قرار می گيرد . زمانی كه ASP. NET يك درخواست را دريافت می نمايد ، شناسه آن را حذف ، مجموعه session را بازيابی و درخواست دريافتی را برای دايركتوری مورد نظر ارسال می نمايد .
با توجه به اين كه شناسه session درون URL جاری قرار می گيرد ، لينك های مربوطه نير بطور اتوماتيك قادر به استفاده از شناسه session خواهند بود . به عبارت ديگر ، در صورتی كه كاربر بر روی page1.aspx باشد و بر روی لينك مربوط به page2.aspx كليك نمايد ، لينك مربوطه شامل شناسه session جاری به عنوان بخشی از URL مورد نظر خواهد بود . سناريوی فوق در مواردی كه از متد Response.Redirect به همراه يك URL نسبی استفاده شده باشد نيز صدق می كند .
Response.Redirect("Page2.aspx")
مثال
در اين مثال با نحوه استفاده از 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 در صفحه جديد فراهم می گردد . كد زير نحوه انجام اين كار را نشان می دهد .
Protected Sub cmdLink_Click(ByVal sender As Object,ByVal As EventArgs) Handles cmdLink.Click
Response.Redirect("Cookieless2.aspx")
End Sub
• تغيير مسير ( مسير مطلق ) : تنها محدوديت cookieless ، عدم امكان استفاده از لينك های absolute است . چراكه ASP. NET نمی تواند شناسه session را درون آنها قرار دهد . مثلا" در صورتی كه بر روی دكمه دوم كليك شود ، امكان استفاده از session جاری در صفحه Cookieless2.aspx وجود نخواهد داشت . كد زير نحوه انجام اين كار را نشان می دهد .
Protected Sub cmdLinkAbsolute_Click(ByVal sender As Object, ByVal e As EventArgs) Handles cmdLinkAbsolute.Click
Dim url As String = "http://" & Request.Url.Authority & _
Request.Url.Segments(0) & Request.Url.Segments(1) & "Cookieless2.aspx"
Response.Redirect(url)
End Sub
كد صفحات 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>



صفحه 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 را انجام خواهد داد .
در بخش يازدهم به بررسی ساير خصلت های تاثير گذار در پيكربندی session خواهيم پرداخت .
State Management در ASP. NET 2.0 (بخش سوم)
آنچه تاكنون گفته شده است :
در اين بخش بحث مربوط به نحوه پيكربندی session در برنامه های وب را ادامه می دهيم .
Timeout
يكی ديگر از تنظيمات مهم در ارتباط با session state ، مشخص كردن مدت زمان timeout است . مقدار در نظر گرفته شده برای خصلت فوق ( تعريف شده در فايل web.config ) ، مدت زمان انتظار ASP.NET قبل از حذف session را مشخص می كند ( عدم دريافت هيچگونه درخواست در بازه زمانی مشخص شده ) .
در نمونه كد زير به ASP.NET اعلام شده است كه اگر پس از گذشت 20 دقيقه درخواستی از سرويس گيرنده دريافت نگرديد ، session آن را حذف كن .
<sessionState
timeout="20" />
خصلت فوق يكی از مهمترين پارامترهای مديريت session در برنامه های وب است كه عدم مقداردهی مناسب آن می تواند نتايج نامطلوبی را در ارتباط با كارآئی يك برنامه وب به دنبال داشته باشد . در زمان مقداردهی پارامتر فوق می بايست به اين نكته دقت شود كه اولا" زمان در نظر گرفته شده به اندازه ای كوتاه باشد كه سرويس دهنده بتواند پس از سپری شدن مدت زمان اندكی كه كاربر از برنامه استفاده نمی نمايد ، منبع ارزشمند حافظه را آزاد نمايد و ثانيا" كاربر بتواند بدون نگرانی در خصوص از دست دادن session خود با خيالی آسوده از برنامه استفاده نمايد .
در صورت نياز ، می توان مقداردهی پارامتر فوق را از طريق كد نيز انجام داد . به عنوان نمونه در مواردی كه يك session حاوی يك حجم غيرمتعارف از اطلاعات باشد ، می توان مدت زمان حيات session را محدودتر كرد . كد زير نحوه تغيير مقدار پارامتر فوق را به 10 دقيقه نشان می دهد .
Session.Timeout = 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 Server state استفاده كرد .
در برخی موارد ممكن است برنامه نويسان به اين نتيجه رسيده باشند كه كاربران اطلاعات session خود را بدون هيچگونه دليلی از دست می دهند . همين امر باعث می شود كه آنان استفاده از گزينه ای غير از InProc را در دستور كار قرار دهند . در ASP.NET ، حوزه برنامه ها به دلايل متعددی ممكن است راه اندازی مجدد گردد ( نظير اعمال تغييرات در پيكربندی ، بهنگام سازی صفحات ) .
توجه داشته باشيد ، در زمان استفاده از StateServer و يا SQLServer ، اشيائی می توانند در session state ذخيره گردند كه قابليت سريال شدن را داشته باشند . در غيراينصورت ، 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 ، از يك بانك اطلاعاتی SQL Server برای ذخيره اطلاعات 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 قرار دارد . برای اجرای اسكريپت فوق می توان از يك برنامه كاربردی SQL Server نظير SQL Server Management Studio يا sqlcmd.exe ( برای سرويس SQL 2005 ) و يا OSQL.exe و Query Analyze ( برای نسخه های قبلی ) استفاده كرد . اسكريپت فوق صرفا" يك مرتبه و به منظور ايجاد بانك ، جداول و stored procedures مورد نياز اجراء خواهد شد .
نام بانك اطلاعاتی معمولا" ASPState می باشد .در واقع ، connection string موجود در فايل web.config با صراحت نام بانك اطلاعاتی را مشخص نخواهد كرد بلكه صرفا" مكان سرويس دهنده و نوع تائيديه مشخص می گردد . كد زير نحوه انجام اين كار را نشان می دهد .
<sessionState
sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI"


...
/>
در صورتی كه قصد استفاده از يك بانك اطلاعاتی با نام ديگر و ساختار مشابه را داشته باشيم ، كافی است مقدار خصلت CustomSqlDatabase برابر با true در نظر گرفته شود .
<sessionState
allowCustomSqlDatabase="true"
sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI;Initial

Catalog=CustDatabase"
...
/>

زمانی كه از يك بانك اطلاعاتی SQL Server برای ذخيره اطلاعات session استفاده می گردد ، می توان از گزينه اختياری sqlCommandTimeout است كرد . پارامتر فوق ، حداكثر مدت زمان انتظار برای پاسخ سرويس دهنده بر حسب ثانيه را مشخص می نمايد . مقدار گزينه پيش فرض ، 30 ثانيه است .
Custom
زمانی كه برای خصلت mode مقدار custom در نظر گرفته می شود ، می بايست session state provider را با استفاده از خصلت customProvider مشخص كرد . خصلت فوق به نام يك كلاس كه بخشی از برنامه وب موجود در دايركتوری App_Code است و يا يك اسمبلی كمپايل شده موجود در دايركتوری BIN و يا GAC ، اشاره می نمايد .
ايجاد يك provider سفارشی ، مسائل مختص به خود را دارد و می بايست با دقت پياده سازی گردد تا بتواند اهدافی نظير امنيت و قابليت توسعه را به خوبی تامين نمايد . بحث بر روی provider سفارشی خارج از حوصله اين مقاله است .
برخی توليد كنندگان ممكن است نسخه هائی خاص از state provider را ارائه نمايند كه در صورت نياز و تمايل می توان از آنها استفاده كرد . به عنوان مثال ، اوراكل ممكن است يك provider سفارشی را ارائه نمايد كه امكان ذخيره اطلاعات session را در يك بانك اطلاعاتی اوراكل فراهم نمايد .
در بخش دوازدهم با application state آشنا خواهيم شد .
________________________________________
State Management در ASP. NET 2.0 (بخش چهارم)
آنچه تاكنون گفته شده است :
در اين بخش با application state آشنا می شويم .
با استفاده از application state می توان اشياء سراسری ( global ) را با هدف دستيابی توسط هر يك از سرويس گيرندگان ذخيره كرد . عملكرد application state بر اساس كلاس

System.Web.HttpApplicationState می باشد كه بطور پيش فرض از طريق شی از قبل تعبيه شده Application در تمامی صفحات قابل استفاده است .
طرز كار application state مشابه session state است و از اشيائی با نوع های مشابه ، نگهداری اطلاعات در سمت سرويس دهنده و گرامر مبتنی بر ديكشنری استفاده می نمايد . استفاده از يك شمارنده سراسری به منظور نگهداری تعداد دفعاتی كه يك عمليات خاص توسط تمامی سرويس گيرندگان يك برنامه وب انجام می شود ، يك نمونه متداول استفاده از application state می باشد .


مثلا" می توان يك event handler در فايل global.asax را تعريف كرد تا تعداد session ايجاد شده و يا تعداد درخواست های دريافتی توسط يك برنامه را ثبت كند . همچنين ، می توان از روشی مشابه در Page. Load به منظور تعيين تعداد دفعاتی كه يك صفحه خاص توسط سرويس گيرندگان مختلف درخواست شده است ، استفاده كرد .
كد زير نحوه انجام اين كار را مشخص می كند .
Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load
Dim Count As Integer = CType(Application("HitCounter"), Integer)
Count += 1
Application("HitCounter") = Count
lblCounter.Text = Count.ToString()
End Sub
لازم است مجددا" به اين نكته اشاره گردد كه آيتم های application state به عنوان شی ذخيره می گردند ، بنابراين می بايست در زمان بازيابی آنها را cast كرد . تاريخ اعتبار و يا مصرف آيتم های ذخيره شده در application state هرگز به اتمام نخواهد رسيد و تا زمانی كه برنامه و يا سرويس دهنده راه اندازی مجدد نگردد و يا حوزه برنامه خود را refresh ننمايد ( به علت تنظيمات ادواری اتوماتيك پردازه و يا بهنگام سازی يكی از صفحات و يا عناصر موجود در برنامه ) ، امكان استفاده از آنها وجود خواهد داشت .
امروزه اغلب از application state به دليل عدم كارآئی مناسب استفاده نمی شود . در مثال قبل ، همواره اين احتمال وجود خواهد داشت كه در شمارنده مقدار درستی ذخيره نگردد ( خصوصا" در مواردی كه ترافيك بالا باشد ) . به عنوان مثال ، در صورتی كه دو سرويس گيرنده در يك زمان مشابه صفحه ای را درخواست نمايند ، دارای مجموعه ای از رويدادها به شرح ذيل خواهيم بود :
• كاربر A مقدار جاری شمارنده را ( فرضا" عدد 432 ) بازيابی می نمايد .


• كاربر B مقدار جاری شمارنده را ( فرضا" عدد 432 ) بازيابی می نمايد .
• كاربر A مقدار شمارنده را تغيير و آن را به 433 تغيير می دهد .
• كاربر B مقدار شمارنده را تغيير و آن را به 433 تغيير می دهد .
به عبارت ديگر ، يكی از درخواست ها باعث افزايش شمارنده نمی گردد ، چراكه دو سرويس گيرنده بطور همزمان به شمارنده دستيابی داشته اند . برای پيشگيری از بروز اين مسئله ، می بايست از متدهای Lock و Unlock استفاده كرد . با استفاده از متدهای فوق در هر لحظه صرفا" به يك سرويس گيرنده اجازه دستيابی به مجموعه application state داده می شود .


Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load
Application.Lock()
Dim Count As Integer = CType(Application("HitCounter"), Integer)
Count += 1
Application("HitCounter") = Count
Application.Unlock()
lblCounter.Text = Count.ToString()
End Sub
ساير سرويس گيرندگانی كه صفحه را درخواست می نمايند می بايست تا زمانی كه مجموعه application state آزاد نشده است ، منتظر بمانند . اين وضعيت می تواند كاهش كارآئی برنامه را به دنبال داشته باشد .
به عنوان يك قانون كلی ، مقاديری كه دائما" و با فركانس بالا تغيير می يابند نمی توانند كانديدی مناسب جهت استفاده از application state باشند .
application state در دنيای دات نت بندرت استفاده می شود چراكه دو كاربرد متداول استفاده از آن با روش های موثرتر ديگر جايگزين شده است .
• در گذشته ، از application state برای ذخيره ثوابت در سطح برنامه نظير يك connection string بانك اطلاعاتی استفاده می گرديد . هم اينك در دات نت می توان اين نوع ثوابت را به سادگی در فايل web.config كه به مراتب از انعطاف بيشتری برخوردار است ذخيره نمود .


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


با استفاده از فايل global.asax می توان كد مورد نياز جهت برخورد با رويدادهائی در سطح برنامه را ايجاد كرد . رويدادهای فوق در نقاط مختلفی از چرخه حيات يك برنامه وب محقق می گردند ( مثلا" زمانی كه session ايجاد می گردد ) . همين موضوع باعث شده است كه فايل global.asax بتواند در تعامل مناسب با ويژگی های state management قرار بگيرد . مثلا" می توان از فايل global.asax برای مقداردهی اوليه مجموعه ای از اشياء كه قصد داريم آنها را در application state ذخيره نمائيم ، استفاده كرد .
فايل global.asax ، همانند يك فايل aspx . است . با اين تفاوت كه اين نوع فايل ها نمی توانند شامل تگ های HTML و يا ASP. NET باشند . در مقابل می توان در آنها event handler مورد نياز را قرار داد . مثلا" فايل global.asax زير در مقابل رويداد Application.EndRequest از خود واكنش نشان می دهد ( رويدادی كه قبل از ارسال صفحه برای كاربر محقق می گردد ) .
<%@ Application Language="VB" %>
<script runat="server">
Sub Application_EndRequest(ByVal sender As Object, ByVal e As EventArgs)
Response.Write("<hr>This page was served at " & DateTime.Now.ToString())
End Sub
</script>
event handler فوق از متد 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 : رويداد فوق در پاسخ به يك خطاء غيرقابل پيش بينی، محقق می گردد .
در بخش پايانی به جمع بندی دوازده مقاله منتشر شده در خصوص session state خواهيم پرداخت .
________________________________________
در ASP. NET 2.0 (بخش پايانی)
آنچه تاكنون گفته شده است :
در اين بخش به جمع بندی دوازده مقاله منتشر شده در خصوص state management خواهيم پرداخت .
state management ، فرآيندی است كه به كمك آن می توان اطلاعاتی را بين درخواست های متعدد ، نگهداری كرد . اطلاعات فوق معمولا" شامل دو دسته می باشند :
• اطلاعات در ارتباط با يك كاربر : نظير ليست كالاهای موجود در يك سبد خريد ، نام كاربر و يا يك سطح دستيابی خاص
• اطلاعات قابل استفاده در تمامی برنامه : نظير آمارهائی كه فعاليت هائی خاص از يك سايت را ثبت می نمايد .
با توجه به اين كه ASP.NET از يك معماری disconnected استفاده می نمايد ، لازم است كه با هر درخواست اطلاعات state ذخيره و آنها را در زمان مورد نياز بازيابی كرد .
استراتژی انتخاب شده برای ذخيره سازی state می تواند بطرز كاملا" محسوسی بر روی پارامترهائی نظير كارآئی ، قابليت گسترش و امنيت يك برنامه وب تاثيرگذار باشد .
از اطلاعات مندرج در جدول زير می توان به منظور بررسی روش های مختلف مديريت state و انتخاب گزينه ای مطلوب كه پاسخگوی نياز يك برنامه است ، استفاده كرد .
اين مطلب از طريق سايت شرکت سخاروش در اختيار شما گذاشته شده است .
حفاظت فايل ها توسط ASP.NET
در زمان ايجاد يک وب سايت مبتنی بر داده که در آن از بانک اطلاعاتی اکسس استفاده می گردد ،می بايست تدابير لازم در خصوص حفاظت از فايل بانک اطلاعاتی ( فايلی با انشعاب mdb . ) اتخاذ گردد. در صورتی که فايل mdb . ، در يک دايرکتوری وب و برروی سرويس دهنده وب ، مستقر شده باشد ، افراديکه قادر به تشخيص نام فايل بانک اطلاعاتی می باشند ، می توانند فايل فوق را از طريق مرورگر download و محتوی آن را مشاهده نمايند. موضوع فوق در مواردی که بانک اطلاعاتی شامل داده هائی حساس نظير رمزهای عبور و اطلاعات شخصی است،بسيار نگران کننده و خطرناک خواهد بود. در اين راستا می توان از روش های متعددی به منظور حفاظت فايل

بانک اطلاعاتی اکسس ( و يا هر فايل دلخواه ديگر ) استفاده نمود. يکی از مناسب ترين روش های موجود ، استقرار فايل در يک دايرکتوری با قابليت عدم دستيابی از طريق وب است . اکثر ميزبانان وب ، دارای فولدری خاص ( مثلا" با نام Databsae ) می باشند که دارای مجوز لازم ( خواندن ، نوشتن ) به منظور دستيابی به يک بانک اطلاعاتی اکسس می باشد .( امکان دستيابی به فولدر فوق از طريق وب وجود نخواهد داشت ) .
در اين مقاله با نحوه استفاده از ASP.NET به منظور حفاظت فايل های بانک اطلاعاتی اکسس و يا فايل هائی با يک انشعاب دلخواه، آشنا می شويم .

نحوه ارتباط IIS و ASP.NET


پس از دريافت يک درخواست توسط سرويس دهنده وب IIS ، نوع انشعاب آن بررسی می گردد . با توجه به نوع انشعاب فايل درخواستی ، ممکن است IIS مستقيما" مسئوليت رسيدگی به درخواست را بر عهده گرفته و يا آن را در اختيار يک ISAPI extension قرار دهد. ISAPI extension ، يک کلاس کمپايل شده است که بر روی سرويس دهنده وب نصب و مسئوليـت آن برگرداندن Markup برای نوع فايل درخواستی ، می باشد. به صورت پيش فرض ، IIS درخواست را بررسی و بسادگی محتوی فايل درخواست شده را به عنوان پاسخ برمی گرداند. اين موضوع در رابطه با فايل های ايستا نظير فايل های HTML و CSS ، صدق می نمايد . مثلا" زمانی که درخواستی برای فايلی با انشعاب html. شده باشد ، IIS محتوی فايل HTML درخواستی را برای متقاضی ، ارسال می نمايد. برای فايل هائی که محتوی آنان بصورت پويا توليد می گردد ، يک ISAPI extension پيکربندی و مسئوليت پاسخگوئی به اينچنين درخواست هائی را برعهده می گيرد . مثلا" يک وب سايت که از صفحات کلاسيک ASP استفاده می نمايد ( فايل هائی با انشعاب asp. ) ، اين مسئوليت به يک ISAPI extension با نام asp.dll واگذار شده است . asp.dll ، صفحه asp درخواست شده را اجراء و HTML توليد شده را برمی گرداند . در صورتی که يک وب سايت از صفحات ASP.NET استفاده می نمايد ، IIS ، مسئوليت رسيگی به فايل هائی با انشعاب aspx . را به aspnet_isapi.dll واگذار نموده است (يک ISAPI extension که فرآيند توليد HTML برای صفحه درخواستی ASP.NET را انجام خواهد داد) . aspnet_isapi.dll در فريمورک دات نت اجراء نمی گردد( Unmanaged code ) .زمانی که IIS ، درخواست صفحات aspx . را در اختيار aspnet_isapi.dll قرار می دهد ، ISAPI extension ، درخواست مربوطه را در اختيار ASP.NET engine قرار داده که کد آن در فريمورک دات نت ، اجراء می گردد.(Managed code ).
ASP.NET engine در بسياری از موارد مشابه IIS عمل نموده و دارای يک دايرکتوری خاص به منظور mapping انشعابات فايل به ISAPI extension مورد نظر می باشد . در چنين مواردی ASP.NET Engine ، انشعابات فايل را به HTTP handler ، مپ می نمايد. کد نوشته شده HTTP handler ، به صورت managed code بوده و مسئوليت توليد markup برای يک نوع فايل خاص را برعهده دارد. مثلا" صفحات وب ASP.NET توسط PageHandlerFactory ، بررسی می گردند. PageHandlerFactory ، دارای آگاهی لازم در خصوص نحوه توليد HTML markup يک صفحه ASP.NET می باشد .
بررسی HttpForbiddenHandler
برنامه های وب ASP.NET دارای اطلاعات پيکربندی مشخص شده بر اساس يک فايل با فرمت XML می باشند : Web.Config . در فايل فوق ، اطلاعاتی مشابه زير قرار می گيرد :


• رشته های اتصال به بانک اطلاعاتی
• اطلاعاتی در رابطه با نحوه تائيد کاربران و ليست نام و رمز عبور آنان ( در صورت ضرورت)
• اطلاعات مربوط به مجوزها و ساير اطلاعات حساس

در متن اصلی مقاله به هم ریختگی وجود ندارد. برای مطالعه بیشتر مقاله آن را خریداری کنید