مقاله در مورد ASP.NET حفاظت فایل ها توسط

توجه : به همراه فایل word این محصول فایل پاورپوینت (PowerPoint) و اسلاید های آن به صورت هدیه ارائه خواهد شد

 مقاله در مورد ASP.NET حفاظت فایل ها توسط دارای ۱۸ صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است

فایل ورد مقاله در مورد ASP.NET حفاظت فایل ها توسط  کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه  و مراکز دولتی می باشد.

توجه : در صورت  مشاهده  بهم ریختگی احتمالی در متون زیر ،دلیل ان کپی کردن این مطالب از داخل فایل ورد می باشد و در فایل اصلی مقاله در مورد ASP.NET حفاظت فایل ها توسط،به هیچ وجه بهم ریختگی وجود ندارد

---

بخشی از متن مقاله در مورد ASP.NET حفاظت فایل ها توسط :

مفاهیم و چالش ها
در مدت زمان حیات یک برنامه به مواردی برخورد می کنیم که لازم است جهت ذخیره سازی اطلاعات از امکانات پیشرفته تری استفاده گردد . به عنوان مثال ، یک برنامه ممکن است به ذخیره اطلاعات پیچیده ای نظیر اشیاء سفارشی داده و استفاده از آنها در سایر صفحات نیاز داشته باشد . ارسال اینگونه اطلاعات از طریق کوکی و یا یک 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 را از طریق یک شناسه ۱۲۰ بیتی منحصربفرد پیگیری و از یک الگوریتم اختصاصی برای تولید آن استفاده می نماید . بنابراین حداقل این تضمین از لحاظ تئوری ایجاد می گردد که عدد تولید شده منحصر بفرد بوده و به اندازه کافی تصادفی است تا امکان و یا احتمال تشخیص و حدس آن توسط مهاجمان به حداقل مقدار خود برسد ( مهاجمان با بکارگیری روش هائی موسوم به مهندسی معکوس در تلاش جهت آگاهی از این موضوع هستند که یک سرویس گیرنده خاص از چه شناسه ای برای 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 می گویند .
شکل ۱ معماری session state در ASP.NET را نشان می دهد .

شکل ۱ : معماری 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 به دلیل عدم فعالیت کاربر در یک بازه زمانی خاص ( مقدار پیش فرض ۲۰ دقیقه )
• خاتمه دادن به عمر مفید یک session از طریق کد و توسط برنامه نویس ( استفاده از متد

Session.Abandon)
در دو مورد اول ، session همچنان در حافظه باقی خواهد ماند چراکه سرویس دهنده وب از بستن مرورگر و یا تغییر پنجره توسط کاربر آگاهی ندارد . در چنین مواردی ، session آخرین لحظات عمر خود را در حافظه طی می نماید و عملا” غیرقابل دسترس باقی می ماند تا زمانی که عمر آن به اتمام رسد .
علاوه بر موارد فوق ، زمانی که application domain مجددا” ایجاد گردد ، session state حذف خواهد شد . فرآیند فوق در زمان بهنگام سازی برنامه و یا تغییر در تنظیمات پیکربندی انجام می

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

در بخش نهم بحث خود را در ارتباط با session state ادامه داده و به بررسی یک نمونه مثال کاربردی خواهیم پرداخت
________________________________________
State Management در ASP. NET 2.0 (بخش اول)
۲در بخش هشتم با مفاهیم و معماری 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 (بخش هفتم) “, _
” کوکی های سفارشی و نحوه عملکرد آنها”, ۹۴)
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>

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

شکل ۱: نحوه عملکرد 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 ، اطلاعات در خروجی نمایش داده می شود .

شکل ۱ ، نحوه عملکرد صفحه Cookieless1.aspx را نشان می دهد .

شکل ۱ ، نحوه عملکرد صفحه 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 اعلام شده است که اگر پس از گذشت ۲۰ دقیقه درخواستی از سرویس گیرنده دریافت نگردید ، session آن را حذف کن .
<sessionState
timeout=”20″ />
خصلت فوق یکی از مهمترین پارامترهای مدیریت session در برنامه های وب است که عدم مقداردهی مناسب آن می تواند نتایج نامطلوبی را در ارتباط با کارآئی یک برنامه وب به دنبال داشته باشد . در زمان مقداردهی پارامتر فوق می بایست به این نکته دقت شود که اولا” زمان در نظر گرفته شده به اندازه ای کوتاه باشد که سرویس دهنده بتواند پس از سپری شدن مدت زمان اندکی که کاربر از برنامه استفاده نمی نماید ، منبع ارزشمند حافظه را آزاد نماید و ثانیا” کاربر بتواند بدون نگرانی در خصوص از دست دادن session خود با خیالی آسوده از برنامه استفاده نماید .
در صورت نیاز ، می توان مقداردهی پارامتر فوق را از طریق کد نیز انجام داد . به عنوان نمونه در مواردی که یک session حاوی یک حجم غیرمتعارف از اطلاعات باشد ، می توان مدت زمان حیات session را محدودتر کرد . کد زیر نحوه تغییر مقدار پارامتر فوق را به ۱۰ دقیقه نشان می دهد .
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 یک مقدار را مشخص نمود . پارامتر فوق ، حداکثر مدت زمان انتظار برای پاسخ سرویس دهنده بر حسب ثانیه را مشخص می نماید . مقدار گزینه پیش فرض ، ۱۰ ثانیه است .
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 است کرد . پارامتر فوق ، حداکثر مدت زمان انتظار برای پاسخ سرویس دهنده بر حسب ثانیه را مشخص می نماید . مقدار گزینه پیش فرض ، ۳۰ ثانیه است .
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 مقدار جاری شمارنده را ( فرضا” عدد ۴۳۲ ) بازیابی می نماید .

• کاربر B مقدار جاری شمارنده را ( فرضا” عدد ۴۳۲ ) بازیابی می نماید .
• کاربر A مقدار شمارنده را تغییر و آن را به ۴۳۳ تغییر می دهد .
• کاربر B مقدار شمارنده را تغییر و آن را به ۴۳۳ تغییر می دهد .
به عبارت دیگر ، یکی از درخواست ها باعث افزایش شمارنده نمی گردد ، چراکه دو سرویس گیرنده بطور همزمان به شمارنده دستیابی داشته اند . برای پیشگیری از بروز این مسئله ، می بایست از متدهای 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 . در فایل فوق ، اطلاعاتی مشابه زیر قرار می گیرد :

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