سيستم پيكربندی ASP.NET 2.0
پياده كنندگان برنامه های وب كه از فن آوری ASP كلاسيك به منظور پياده سازی برنامه های وب در گذشته ای نه چندان دور استفاده می كردند ( و شايد هم اينك نيز استفاده می نمايند ) ، به ياد دارند كه اطلاعات پيكربندی برنامه های فوق به صورت باينری و در محلی با نام متابيس IIS ، ذخيره می گردد . پياده كنندگان برنامه های وب برای اعمال تغييرات لازم در متابيس از دو گزينه متداول استفاده می كردند : نوشتن اسكريپت های مورد نياز و يا استفاده از كنسول مديريتی برنامه IIS ( سرويس دهنده وب مايكروسافت ) .
برخلاف ASP كلاسيك ، در ASP.NET 1.x حضور متابيس ها كم رنگ گرديد و در مقابل ، استفاده از يك سيستم پيكربندی مبتنی بر xml مورد توجه قرار گرفت . عليرغم اين كه سيستم فوق دارای انعطاف بمراتب بيشتری نسبت به نسخه قبلی است ولی امكانات مديريتی مناسبی را به منظور ويرايش فايل های پيكربندی در اختيار پياده كنندگان برنامه های وب قرار نمی دهد . تنها گزينه موجود برای ويرايش يك فايل پيكربندی ، برخورد با فايل پيكربندی به عنوان يك فايل xml و بهنگام سازی آن فايل بر اساس ماهيت فايل های xml است . مهمترين مشكل رويكرد فوق ، برخورد با تمامی بخش های فايل پيكربندی به عنوان گره های xml است .
در ASP.NET 2.0 ، امكانات و پتانسيل های متعددی به منظور مديريت پيكربندی برنامه های وب ارائه شده است با اين هدف كه بتوان با سادگی و سرعت بيشتری پيكربندی يك برنامه وب را انجام داد .خواندن و ويرايش فايل های پيكربندی در يك ماشين محلی و يا از راه دور از جمله مهمترين ويژگی های ارائه شده در ASP.NET 2.0 می باشد .
اطلاعات پيكربندی يك برنامه ASP.NET در دو فايل مهم Xml ذخيره می گردد . از Xml برای تشريح خصلت ها و رفتار جنبه های مختلف برنامه های ASP.NET استفاده می‌شود . سيستم پيكربندی ASP.NET از دو فايل پيكربندی استفاده می نمايد :
• machine.config : فايل پيكربندی سرويس دهنده
• Web.Config : فايل پيكربندی برنامه
با توجه به ماهيت فايل های پيكربندی ( فايل هائی از نوع xml ) ، عناصری كه مسئوليت تشريح پيكربندی را برعهده دارند نسبت به حروف بزرگ و كوچك حساس می باشند .
در مثال زير ، يك نمونه فايل web.config به همراه بخش مربوط به معرفی <sessionState> يك برنامه وب نشان داده شده است .
مزايای استفاده از يك فايل xml برای پيكربندی (در مقابل يك متابيس باينری )
• امكان خواندن اطلاعات پيكربندی وجود داشته و می توان به سادگی و با استفاده از يك ويرايشگر متن نظير NotePad آنان را ويرايش نمود ( گرچه توصيه می گردد كه در اين رابطه از ويژوال استوديو 2005 و يا اديتوری كه قادر به تشخيص تگ های xml می باشد ، استفاده گردد). فايل پيكربندی را می توان به سادگی از يك سرويس دهنده به سرويس دهنده ديگر منتقل نمود . ويژگی فوق در يك Web Farm بسيار مفيد و موثر می باشد .
• پس از انجام تغييرات مورد نياز در يك فايل پيكربندی ، ASP.NET به صورت اتوماتيك تغييرات ايجاد شده را تشخيص و آنان را در ارتباط با برنامه اعمال خواهد كرد . ASP.NET بدين منظور يك نمونه جديد از برنامه را ايجاد و كاربران را به برنامه جديد هدايت می نمايد .
• پس از اعمال تغييرات در پيكربندی يك برنامه ASP.NET ، ضرورتی ندارد كه مديريت برنامه سرويس دهنده وب را متوقف و مجددا" فعاليت آن را آغاز نمايد .
• سيستم پيكربندی ASP.NET قابل توسعه است و اطلاعات مرتبط با يك برنامه را می توان به سادگی ذخيره و بازيابی نمود .
• اطلاعات حساس ذخيره شده در سيستم پيكربندی ASP.NET 2.0 را می توان در صورت تمايل به صورت رمزشده ذخيره نمود ( اقدامی در جهت افزايش امنيت و ايمن سازی برنامه های وب خصوصا" اطلاعات حساس مرتبط با آنان ) .
در صورتی كه بر روی سيستم چندين نسخه از فريمورك دات نت نصب شده باشد ، هر نسخه دارای فايل پيكربندی machine.config مختص به خود است . مثلا" در صورتی كه بر روی كامپيوتر نسخه های ASP.NET 1.1 ، ASP.NET 1.0 و ASP.NET 2.0 نصب شده باشد ، هر نسخه فريمورك دارای فايل machine.config مختص به خود است . اين بدان معنی است كه بر روی سرويس دهنده فوق سه فايل پيكربندی machine.config وجود خواهد داشت .
علاوه بر فايل machine.config ، فريمورك دات نت دو فايل ديگر را به اسامی machine.config.default و machine.config.comments نيز نصب می نمايد . از فايل اول به عنوان نسخه backup فايل machine.config استفاده می گردد. در صورتی كه بخواهيم به تنظيمات اوليه برگرديم ، كافی است تنظيمات موجود در فايل machine.config.default را به فايل machine.config كپی نمود . در فايل دوم ( machine.config.Comments ) ، هر بخش از فايل پيكربندی تشريح می گردد .
ASP.NET runtime ، از دو فايل فوق استفاده نمی نمايد و صرفا" بدين جهت نصب شده اند تا در صورت ضرورت از آنان به منظور برگشت به حالت اوليه استفاده نمود ( default factory setting ) .
برای بهنگام سازی سرويس دهندگان در farm ( بر اساس تنظميات جديد ) ، می توان به سادگی فايل web.config را به دايركتوری مربوط به برنامه كپی نمود . در چنين مواردی ضرورتی به دستيابی سرويس دهنده محلی و راه اندازی آن وجود نداشته و برنامه ادامه فعاليت خود را به صورت طبيعی و بر اساس تنظيمات جديد انجام خواهد داد .
پيكربندی هر برنامه وب منحصربفرد است گرچه اين تنظيمات از parent به ارث رسيده باشند . مثلا" در صورتی كه فايل web.config موجود در فهرست ريشه يك وب سايت مقدار session timeout را معادل ده دقيقه تعريف نمايد ، تنظميات پيش فرض در فايل machine.config كه مقدار session timeout را بيست دقيقه تعريف كرده است ، ناديده می گيرد .
زمانی كه يك برنامه ASP.NET فعاليت خود را آغاز می نمايد ، تنظيمات پيكربندی خوانده شده و در ASP.NET Cache ذخيره می شوند .در ادامه يك file dependency در entry مربوط به cache در فايل machine.config و يا web.config قرار می گيرد . پس از تشخيص تغيير در فايل های machine.config و يا web.config ، يك application domain جديد توسط ASP.NET ايجاد تا به درخواست های جديد سرويس دهد . application domain قديم پس از پاسخگوئی به درخواست های جاری از بين خواهد رفت .
در مثال زير ، يك فايل نمونه web.config نشان داده شده است ( مقادير بين علائم [] ، در يك فايل پيكربندی واقعی ، با مقادير واقعی جايگزين می گردند ) .
عنصر ريشه Xml يك فايل پيكربندی همواره <configuration> ناميده می شود . هر section handler به همراه تنظميات مربوطه در يك <SectionGroup> قرار می گيرند . <SectionGroup> يك ساختار سازمانی درون فايل پيكربندی را ارائه می نمايد تا به كمك آن بتوان پيكربندی مورد نياز را در گروه های منحصربفرد انجام داد . به عنوان نمونه بخش <system.web> درون فايل پيكربندی ، مكانی را كه اطلاعات آن در ارتباط با ASP.NET می باشد ، مشخص می نمايد.
ذخيره اطلاعات connection - string در بخش <appSetting> دارای چالش های مختص به خود است :
• زمانی كه اطلاعات connection string در بخش appSetting ذخيره می گردد ، برای يك كنترل مرتبط با داده نظير SqlCacheDependency و يا MembershipProvider امكان دستيابی به اطلاعات وجود ندارد .
• ايمن سازی Connection string با استفاده از الگوريتم های رمزنگاری چالش های خاص خود را دارد .
• ويژگی فوق صرفا" در ارتباط با برنامه های ASP.NET نبوده و تمامی برنامه های دات نت نظير Windows Forms , Web Service و ساير موارد ديگر را نيز شامل می شود .
با توجه به اين كه اطلاعات connection string مستقل از بخش appSetting ذخيره می گردد ، می توان آنان را با استفاده از مجموعه متد ConnectionString بازيابی نمود .
كد زير نحوه ذخيره connection string در فايل Web.config را نشان می دهد .
در برنامه های وب گفتگوی بين يك سرويس گيرنده و يك سرويس دهنده از طريق پروتكل HTTP انجام می شود و جملگی به خوبی می دانيم كه اين پروتكل يك پروتكل stateless است و ارتباط با يك سرويس دهنده از راه دور در زمان مورد نياز ايجاد و در ادامه و پس از سرويس دهی ، غيرفعال می شود . با اين كه HTTP 1.1 از يك روش Keep-alive استفاده می نمايد ولی سرويس دهنده نمی تواند درخواست های ايجاد شده توسط يك سرويس گيرنده را تشخيص دهد .
برای ذخيره و نگهداری state از گزينه های متعددی استفاده می گردد كه session يك نمونه در اين زمينه است .شی Session متداولترين محلی است كه می توان اطلاعات مربوط به وضعيت برنامه و كاربران را در آن ذخيره و نگهداری نمود . برای پياده سازی session از يك Hashtable استفاده می گردد و داده بر اساس تركيب زوج كليد و مقدار ذخيره می شود .
Session در ASP.NET 2.0 يك مفهوم جديد نيست و متاثر از ماهيت پروتكل HTTP است ( Stateless ) و قبل از ASP.NET و حتی ASP كلاسيك وجود داشته است .
• In-Process Session State Store : اطلاعات session در Cache ( حافظه ) ذخيره می گردد .
• Out-of-Process Session State Store : اطلاعات Session در State Server Service ذخيره می گردد ( asp_net_state.exe )
• Sql Session State Store : اطلاعات session در بانك اطلاعاتی SQL ذخيره می گردد . برای پيكربندی از aspnet_regsql.exe استفاده می گردد .
در ASP.NET 2.0 ، يك قابليت جديد با نام custome به مجموعه فوق اضافه شده است . با استفاده از گزينه فوق ، پياده كنندگان می توانند داده session را در يك مكان دائم ذخيره نمايند . مثلا" ASP.NET 2.0 امكان ذخيره داده session را در برخی بانك های اطلاعاتی نظير Oracle,DB2 و يا Sybase ندارد . در صورتی كه بخواهيم داده session را در يكی از بانك های اطلاعاتی فوق و يا يك فايل XML ذخيره نمائيم ، می توان از يك Provider class سفارشی استفاده نمود .
برای پيكربندی اطلاعات session از عنصر <sessiononState > در فايل web.config استفاده می گردد :
در ادامه به بررسی مختصر هر يك از گزينه های فوق خواهيم پرداخت .
In-Process Session State Store : متداولترين و در عين حال سريعترين روش پيكربندی session state در ASP.NET 2.0 می باشد ( مقدار mode برابر inproc در نظر گرفته می شود ) .در اين روش داده Session در cache داخلی HttpRuntime ذخيره شده و به صورت live قابل دستيابی است . با توجه به اين كه داده session در حافطه ذخيره می گردد ، به سرعت می توان به آن دستيابی داشت ( ضرورتی ندارد داده از يك مكان ديگر به درون حافظه انتقال يابد ). داده seesion تا زمان اعتبار session در حافظه موجود می باشد و پس از time out فضای اشغال شده آزاد می گردد .
Out-of-Process Session State Store : داده session در يك process كه به عنوان يك سرويس ويندوز اجراء می گردد ، نگهداری می شود ( aspnet_state.exe ) .
State Service به صورت پيش فرض اجراء نمی گردد و برای فعال كردن آن می توان از دستور net start aspnet_sate استفاده نمود . به صورت پيش فرض ، سرويس فوق از پورت 42424 استفاده می نمايد . در صورت ضرورت می توان با استفاده از كليد ريجستری زير آن را تغيير داد .
برای استفاده از روش فوق كافی است كه مقدار Inproc به StateServer در فايل web.config تغيير داد . همچنين می بايست از خصلت StateConnectionString به منظور مشخص نمودن IP و شماره پورتی كه Session State Service بر روی آن اجراء شده است ، استفاده نمود .
Sql Session State Store : داده session در يك بانك اطلاعاتی SQL ذخيره می گردد .
Custom State Store :معماری Sessin state در ASP.NET 2.0 بگونه ای طراحی شده است كه امكان افزودن Provider به آن وجود دارد ( مشتق شده از كلاس SessionStateStoreProviderBase ) . در صورتی كه بخواهيم Provider اختصاصی خود را ايجاد و يا از يك third-party provider استفاده نمائيم ، می بايست مقدار خصلت mode را Custome در نظر گرفت . در چنين مواردی ، لازم است كه custom provider assembly مشتق شده از كلاس SessionStateStoreProviderBase را مشخص نمود .
مثال : كد زير يك نمونه از پيكربندی sessionState در فايل web.config را نشان می دهد :
• cookieless : مشخص می نمايد كه آيا از HTTP cookieless Session Key management حمايت می گردد .
• timeout : مدت زمان حيات Session را مشخص می نمايد . مقدار timeoute بر اساس زمان درخواست ارزيابی می گردد . مثلا" در صورتی كه مقدار timeout بيست دقيقه باشد و در خواستی در ساعت ده و ده دقيقه دريافت گردد ، timeout در ساعت ده و سی دقيقه به اتمام می رسد .
• stateConnnectionString :از خصلت فوق به منظور مشخص نمودن آدرس TCP/IP و پورت جهت ارتباط يا Windows Service providing state management استفاده می گردد ( در مواردی كه mode=StateServer در نظر گرفته شود ) .
• stateNetworkTimeout : مقدار timeout ( بر حسب ثانيه ) را در زمان ذخيره state در يك out-of-process session ( نظير StateServer ) ، مشخص می نمايد .
• sqlConnectionString : از خصلت فوق جهت ارتباط با بانك اطلاعاتی SQL Server برای ذخيره و بازيابی داده session استفاده می گردد ( در مواردی كه mode=SQLServer در نظر گرفته شود) .
پيكربندی Session State با استفاده از Connection string : كد زير يك نمونه از پيكربندی Session State با استفاده از connection string را نشان می دهد :
هر نوع تغيير در فايل ترجمه شده پويا باعث می گردد كه تمامی منابع متاثر از تغييرات شوند و به صورت پويا invalidated و مجددا" ترجمه گردند . مكانيزم فوق پياده كنندگان را قادر می سازد كه به سرعت برنامه های وب را با حداقل overhead اجراء نمايند. چراكه پس از تشخيص تغييرات و ترجمه پويا ، می توان بلافاصله از امكانات برنامه ها استفاده نمود .
پتانسيل ترجمه پويا در ASP.NET 2.0 نسبت به ASP.NET 1.x افزايش و فايل های ديگری نظير كلاس فايل ها را نيز تحت پوشش قرار می دهد .
برای پيكربندی تنظيمات ترجمه از بخش <compilation> در فايل های web.config و يا machine.config استفاده می گردد . ASP.NET engine ، در زمان مورد نياز صفحه را ترجمه و كد توليد شده را در code cache ذخيره می نمايد .از cache فوق در زمان اجرای صفحات ASP.NET استفاده می گردد .
كد زير گرامر بخش <compilatioin> را نشان می دهد .
• maxBatchSize : حداكثر تعداد صفحات و يا كلاس را كه می توان در يك batch ترجمه نمود، مشخص می نمايد. ( مقدار پيش فرض 1000 )
• maxBatchGeneratedFileSize : حداكثر اندازه خروجی يك batch assembley ترجمه شده را نشان می دهد ( مقدار پيش فرض 3000 )
• batchTimeout : زمان ( بر حسب ثانيه ) ترجمه batch را مشخص می نمايد . در صورتی كه زمان فوق قبل از اتمام ترجمه به پايان رسيده باشد ، يك exception محقق می گردد ( مقدار پيش فرض پانزده ثانيه است) .
• debug : آيا می بايست اسمبلی های توليد شده را ترجمه ويا ديباگ نمود ؟ (مقدار پيش فرض False ).
• defaultLanguage : زبان برنامه نويسی پيش فرض نظير VB و يا #C برای استفاده در فايل های ترجمه پويا را مشخص می نمايد.
• tempDirectory : دايركتوری مورد نظر برای استفاده موقت در حين ترجمه را مشخص می نمايد . به صورت پيش فرض ، ASP.NET فايل موقت را در مسير
[WinNT\Windows]\Microsoft.NET\Framework\[version]\Temporary ASP.NET ايجاد می نمايد .
• compilers : بخش <compilers> ، می تواند شامل چندين زير عنصر <compile> باشد كه از آنان به منظور ايجاد يك تعريف جديد كمپايل استفاده می گردد .
• numRecompilesBeforeAppRestart : تعداد دفعات ترجمه ، قبل از راه اندازی برنامه مشخص می نمايد .
پس از دريافت يك درخواست از يك مرورگر ، browser capabilities component قابليت های مرورگر را از طريق هدر درخواست شناسائی و برای هر نوع مرورگر يك مجموعه از تنطيمات مرتبط با برنامه را ترجمه می نمايد . تنظيمات فوق را می توان به صورت ايستا انجام و يا از هدر درخواست ارسالی استفاده نمود . يك برنامه می تواند در صورت ضرورت تنظيمات فوق را را توسعه و يا تغيير دهد .
در ASP.NET 2.0 تمامی اطلاعات مربوط به قابليت های مرورگر در "فايل های تعريف مرورگر" ارائه می گردند . اين نوع فايل ها ، فايل هائی با انشعاب browser.* و فرمت xml می باشند . يك فايل ممكن است شامل تعريف بيش از يك نوع مرورگر باشد . فايل های فوق در زمان نصب فريمورك در آدرس
[WinNT\Windows]\Microsoft.NET\Framework\xxxxx\CONFIG\Browsers نصب می گردند . ( در ASP.NET 1.x ، اطلاعات مربوط به پتانسيل هر مرورگر در فايل های machine.config و web.config ذخيره می گردد ).
هر مرورگر به عنوان يك موجوديت و با استفاده از عنصر <browser> تعريف و دارای يك id مختص به خود است كه يك كلاس از مرورگر را به همراه كلاس parent مشخص می نمايد . <browsers> ، عنصر ريشه در فايل های تعريف مرورگر است و از خصلت id به منظور تمايز بين تعاريف هر يك از مرورگر ها ( در صورتی كه بيش از يك مورد در يك فايل تعريف شده باشد ) ، استفاده می گردد .
قبل از اجرای يك برنامه ASP.NET ، فريمورك تمامی تعاريف مرورگر را در يك اسمبلی ترجمه و آنان را در GAC ذخيره می نمايد .
در صورت تغيير فايل های تعريف مرورگر در سطح سيستم ، تغييرات به صورت اتوماتيك بر روی هر يك از برنامه های ASP.NET اعمال نخواهد شد . بنابراين ، اين مسئوليت پياده كنندگان و يا ابزارهای نصب است كه اطلاعات فوق را بهنگام نمايند . اطلاعات بهنگام شده مرورگر را می توان با استفاده از برنامه aspnet_regbrowsers.exe برای تمامی برنامه های ASP.NET ارسال نمود . پس از اجرای برنامه فوق ، اطلاعات مرورگر مجددا" ترجمه و اسمبلی جديد در GAC ذخيره می گردد . از اسمبلی فوق تمامی برنامه های ASP.NET استفاده می نمايند .
• نمايش كد منبع و پيام خطاء برای كاربران عادی هيچگونه ارزش اطلاعاتی ندارد، پس چرا می بايست آنان را نمايش داد ؟
• نمايش كد منبع و پيام خطاء بيش از همه مهاجمان فرصت طلب را خوشحال خواهد كرد چراكه شرايط مناسبی برای ارتقاء دانش آنان به منظور برنامه ريزی حملات فراهم می گردد .
ASP.NET با ارائه يك زيرساخت مناسب امكان پيشگيری از نمايش اينگونه خطاها را در اختيار پياده كنندگان برنامه های وب قرار می دهد . بدين منظور از بخش <customeErrors> در فايل web.config برای تعريف پيام های خطاء سفارشی و سياست نمايش جزئيات خطاء استفاده می گردد . نحوه استفاده از عنصر فوق به صورت زير است :
• mode : مقدار نسبت داده شده به اين خصلت وضعيت نمايش خطاء سفارشی را مشخص می نمايد . در صورتی كه مقدار اين خصلت on باشد ، خطاهای سفارشی نمايش داده می شوند . در صورتی كه مقدار mode معادل off باشد ، خطاهای سفارشی نمايش داده نخواهند شد و در صورتی كه مقدار اين خصلت remote در نظر گرفته شود ، خطاهای سفارشی صرفا" برای كاربران از راه دور نمايش داده می شود .
• customeErrors : اين بخش شامل چندين زيرعنصر <error> است كه از آنان به منظور تعريف خطاهای سفارشی استفاده می گردد . هر زير عنصر <error> می تواند شامل يك خصلت statusCode و يك URL باشد .
برخلاف ASP كلاسيك ، در ASP.NET 1.x حضور متابيس ها كم رنگ گرديد و در مقابل ، استفاده از يك سيستم پيكربندی مبتنی بر xml مورد توجه قرار گرفت . عليرغم اين كه سيستم فوق دارای انعطاف بمراتب بيشتری نسبت به نسخه قبلی است ولی امكانات مديريتی مناسبی را به منظور ويرايش فايل های پيكربندی در اختيار پياده كنندگان برنامه های وب قرار نمی دهد . تنها گزينه موجود برای ويرايش يك فايل پيكربندی ، برخورد با فايل پيكربندی به عنوان يك فايل xml و بهنگام سازی آن فايل بر اساس ماهيت فايل های xml است . مهمترين مشكل رويكرد فوق ، برخورد با تمامی بخش های فايل پيكربندی به عنوان گره های xml است .
در ASP.NET 2.0 ، امكانات و پتانسيل های متعددی به منظور مديريت پيكربندی برنامه های وب ارائه شده است با اين هدف كه بتوان با سادگی و سرعت بيشتری پيكربندی يك برنامه وب را انجام داد .خواندن و ويرايش فايل های پيكربندی در يك ماشين محلی و يا از راه دور از جمله مهمترين ويژگی های ارائه شده در ASP.NET 2.0 می باشد .
اطلاعات پيكربندی يك برنامه ASP.NET در دو فايل مهم Xml ذخيره می گردد . از Xml برای تشريح خصلت ها و رفتار جنبه های مختلف برنامه های ASP.NET استفاده می‌شود . سيستم پيكربندی ASP.NET از دو فايل پيكربندی استفاده می نمايد :
• machine.config : فايل پيكربندی سرويس دهنده
• Web.Config : فايل پيكربندی برنامه
با توجه به ماهيت فايل های پيكربندی ( فايل هائی از نوع xml ) ، عناصری كه مسئوليت تشريح پيكربندی را برعهده دارند نسبت به حروف بزرگ و كوچك حساس می باشند .
در مثال زير ، يك نمونه فايل web.config به همراه بخش مربوط به معرفی <sessionState> يك برنامه وب نشان داده شده است .
<?xml version="1.0" encoding="UTF-8" ?> |
مزايای استفاده از يك فايل xml برای پيكربندی (در مقابل يك متابيس باينری )
• امكان خواندن اطلاعات پيكربندی وجود داشته و می توان به سادگی و با استفاده از يك ويرايشگر متن نظير NotePad آنان را ويرايش نمود ( گرچه توصيه می گردد كه در اين رابطه از ويژوال استوديو 2005 و يا اديتوری كه قادر به تشخيص تگ های xml می باشد ، استفاده گردد). فايل پيكربندی را می توان به سادگی از يك سرويس دهنده به سرويس دهنده ديگر منتقل نمود . ويژگی فوق در يك Web Farm بسيار مفيد و موثر می باشد .
• پس از انجام تغييرات مورد نياز در يك فايل پيكربندی ، ASP.NET به صورت اتوماتيك تغييرات ايجاد شده را تشخيص و آنان را در ارتباط با برنامه اعمال خواهد كرد . ASP.NET بدين منظور يك نمونه جديد از برنامه را ايجاد و كاربران را به برنامه جديد هدايت می نمايد .
• پس از اعمال تغييرات در پيكربندی يك برنامه ASP.NET ، ضرورتی ندارد كه مديريت برنامه سرويس دهنده وب را متوقف و مجددا" فعاليت آن را آغاز نمايد .
• سيستم پيكربندی ASP.NET قابل توسعه است و اطلاعات مرتبط با يك برنامه را می توان به سادگی ذخيره و بازيابی نمود .
• اطلاعات حساس ذخيره شده در سيستم پيكربندی ASP.NET 2.0 را می توان در صورت تمايل به صورت رمزشده ذخيره نمود ( اقدامی در جهت افزايش امنيت و ايمن سازی برنامه های وب خصوصا" اطلاعات حساس مرتبط با آنان ) .
فايل پيكربندی سرويس دهنده : machine.config
در صورتی كه بر روی سيستم چندين نسخه از فريمورك دات نت نصب شده باشد ، هر نسخه دارای فايل پيكربندی machine.config مختص به خود است . مثلا" در صورتی كه بر روی كامپيوتر نسخه های ASP.NET 1.1 ، ASP.NET 1.0 و ASP.NET 2.0 نصب شده باشد ، هر نسخه فريمورك دارای فايل machine.config مختص به خود است . اين بدان معنی است كه بر روی سرويس دهنده فوق سه فايل پيكربندی machine.config وجود خواهد داشت .
علاوه بر فايل machine.config ، فريمورك دات نت دو فايل ديگر را به اسامی machine.config.default و machine.config.comments نيز نصب می نمايد . از فايل اول به عنوان نسخه backup فايل machine.config استفاده می گردد. در صورتی كه بخواهيم به تنظيمات اوليه برگرديم ، كافی است تنظيمات موجود در فايل machine.config.default را به فايل machine.config كپی نمود . در فايل دوم ( machine.config.Comments ) ، هر بخش از فايل پيكربندی تشريح می گردد .
ASP.NET runtime ، از دو فايل فوق استفاده نمی نمايد و صرفا" بدين جهت نصب شده اند تا در صورت ضرورت از آنان به منظور برگشت به حالت اوليه استفاده نمود ( default factory setting ) .
فايل پيكربندی برنامه : web.config
برای بهنگام سازی سرويس دهندگان در farm ( بر اساس تنظميات جديد ) ، می توان به سادگی فايل web.config را به دايركتوری مربوط به برنامه كپی نمود . در چنين مواردی ضرورتی به دستيابی سرويس دهنده محلی و راه اندازی آن وجود نداشته و برنامه ادامه فعاليت خود را به صورت طبيعی و بر اساس تنظيمات جديد انجام خواهد داد .
نحوه بكارگيری پيكربندی
پيكربندی هر برنامه وب منحصربفرد است گرچه اين تنظيمات از parent به ارث رسيده باشند . مثلا" در صورتی كه فايل web.config موجود در فهرست ريشه يك وب سايت مقدار session timeout را معادل ده دقيقه تعريف نمايد ، تنظميات پيش فرض در فايل machine.config كه مقدار session timeout را بيست دقيقه تعريف كرده است ، ناديده می گيرد .
تشخيص تغيير در فايل پيكربندی
زمانی كه يك برنامه ASP.NET فعاليت خود را آغاز می نمايد ، تنظيمات پيكربندی خوانده شده و در ASP.NET Cache ذخيره می شوند .در ادامه يك file dependency در entry مربوط به cache در فايل machine.config و يا web.config قرار می گيرد . پس از تشخيص تغيير در فايل های machine.config و يا web.config ، يك application domain جديد توسط ASP.NET ايجاد تا به درخواست های جديد سرويس دهد . application domain قديم پس از پاسخگوئی به درخواست های جاری از بين خواهد رفت .
فرمت فايل پيكربندی
در مثال زير ، يك فايل نمونه web.config نشان داده شده است ( مقادير بين علائم [] ، در يك فايل پيكربندی واقعی ، با مقادير واقعی جايگزين می گردند ) .
<?xml version="1.0" encoding="UTF-8"?> |
عنصر ريشه Xml يك فايل پيكربندی همواره <configuration> ناميده می شود . هر section handler به همراه تنظميات مربوطه در يك <SectionGroup> قرار می گيرند . <SectionGroup> يك ساختار سازمانی درون فايل پيكربندی را ارائه می نمايد تا به كمك آن بتوان پيكربندی مورد نياز را در گروه های منحصربفرد انجام داد . به عنوان نمونه بخش <system.web> درون فايل پيكربندی ، مكانی را كه اطلاعات آن در ارتباط با ASP.NET می باشد ، مشخص می نمايد.
Connection String
ذخيره اطلاعات connection - string در بخش <appSetting> دارای چالش های مختص به خود است :
• زمانی كه اطلاعات connection string در بخش appSetting ذخيره می گردد ، برای يك كنترل مرتبط با داده نظير SqlCacheDependency و يا MembershipProvider امكان دستيابی به اطلاعات وجود ندارد .
• ايمن سازی Connection string با استفاده از الگوريتم های رمزنگاری چالش های خاص خود را دارد .
• ويژگی فوق صرفا" در ارتباط با برنامه های ASP.NET نبوده و تمامی برنامه های دات نت نظير Windows Forms , Web Service و ساير موارد ديگر را نيز شامل می شود .
با توجه به اين كه اطلاعات connection string مستقل از بخش appSetting ذخيره می گردد ، می توان آنان را با استفاده از مجموعه متد ConnectionString بازيابی نمود .
كد زير نحوه ذخيره connection string در فايل Web.config را نشان می دهد .
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> |
نحوه بازيابی اطلاعات يك connection string در برنامه :
Public Sub Page_Load (sender As Object, e As EventArgs) |
پيكربندی Session State
در برنامه های وب گفتگوی بين يك سرويس گيرنده و يك سرويس دهنده از طريق پروتكل HTTP انجام می شود و جملگی به خوبی می دانيم كه اين پروتكل يك پروتكل stateless است و ارتباط با يك سرويس دهنده از راه دور در زمان مورد نياز ايجاد و در ادامه و پس از سرويس دهی ، غيرفعال می شود . با اين كه HTTP 1.1 از يك روش Keep-alive استفاده می نمايد ولی سرويس دهنده نمی تواند درخواست های ايجاد شده توسط يك سرويس گيرنده را تشخيص دهد .
برای ذخيره و نگهداری state از گزينه های متعددی استفاده می گردد كه session يك نمونه در اين زمينه است .شی Session متداولترين محلی است كه می توان اطلاعات مربوط به وضعيت برنامه و كاربران را در آن ذخيره و نگهداری نمود . برای پياده سازی session از يك Hashtable استفاده می گردد و داده بر اساس تركيب زوج كليد و مقدار ذخيره می شود .
Session در ASP.NET 2.0 يك مفهوم جديد نيست و متاثر از ماهيت پروتكل HTTP است ( Stateless ) و قبل از ASP.NET و حتی ASP كلاسيك وجود داشته است .
داده Session در چه مكانی ذخيره می گردد ؟
• In-Process Session State Store : اطلاعات session در Cache ( حافظه ) ذخيره می گردد .
• Out-of-Process Session State Store : اطلاعات Session در State Server Service ذخيره می گردد ( asp_net_state.exe )
• Sql Session State Store : اطلاعات session در بانك اطلاعاتی SQL ذخيره می گردد . برای پيكربندی از aspnet_regsql.exe استفاده می گردد .
در ASP.NET 2.0 ، يك قابليت جديد با نام custome به مجموعه فوق اضافه شده است . با استفاده از گزينه فوق ، پياده كنندگان می توانند داده session را در يك مكان دائم ذخيره نمايند . مثلا" ASP.NET 2.0 امكان ذخيره داده session را در برخی بانك های اطلاعاتی نظير Oracle,DB2 و يا Sybase ندارد . در صورتی كه بخواهيم داده session را در يكی از بانك های اطلاعاتی فوق و يا يك فايل XML ذخيره نمائيم ، می توان از يك Provider class سفارشی استفاده نمود .
برای پيكربندی اطلاعات session از عنصر <sessiononState > در فايل web.config استفاده می گردد :
<configuration> |
در ادامه به بررسی مختصر هر يك از گزينه های فوق خواهيم پرداخت .
In-Process Session State Store : متداولترين و در عين حال سريعترين روش پيكربندی session state در ASP.NET 2.0 می باشد ( مقدار mode برابر inproc در نظر گرفته می شود ) .در اين روش داده Session در cache داخلی HttpRuntime ذخيره شده و به صورت live قابل دستيابی است . با توجه به اين كه داده session در حافطه ذخيره می گردد ، به سرعت می توان به آن دستيابی داشت ( ضرورتی ندارد داده از يك مكان ديگر به درون حافظه انتقال يابد ). داده seesion تا زمان اعتبار session در حافظه موجود می باشد و پس از time out فضای اشغال شده آزاد می گردد .
Out-of-Process Session State Store : داده session در يك process كه به عنوان يك سرويس ويندوز اجراء می گردد ، نگهداری می شود ( aspnet_state.exe ) .
State Service به صورت پيش فرض اجراء نمی گردد و برای فعال كردن آن می توان از دستور net start aspnet_sate استفاده نمود . به صورت پيش فرض ، سرويس فوق از پورت 42424 استفاده می نمايد . در صورت ضرورت می توان با استفاده از كليد ريجستری زير آن را تغيير داد .
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\Port |
برای استفاده از روش فوق كافی است كه مقدار Inproc به StateServer در فايل web.config تغيير داد . همچنين می بايست از خصلت StateConnectionString به منظور مشخص نمودن IP و شماره پورتی كه Session State Service بر روی آن اجراء شده است ، استفاده نمود .
<configuration> |
Sql Session State Store : داده session در يك بانك اطلاعاتی SQL ذخيره می گردد .
<configuration> |
Custom State Store :معماری Sessin state در ASP.NET 2.0 بگونه ای طراحی شده است كه امكان افزودن Provider به آن وجود دارد ( مشتق شده از كلاس SessionStateStoreProviderBase ) . در صورتی كه بخواهيم Provider اختصاصی خود را ايجاد و يا از يك third-party provider استفاده نمائيم ، می بايست مقدار خصلت mode را Custome در نظر گرفت . در چنين مواردی ، لازم است كه custom provider assembly مشتق شده از كلاس SessionStateStoreProviderBase را مشخص نمود .
<configuration> |
مثال : كد زير يك نمونه از پيكربندی sessionState در فايل web.config را نشان می دهد :
<sessionState |
توضيحات :
• cookieless : مشخص می نمايد كه آيا از HTTP cookieless Session Key management حمايت می گردد .
• timeout : مدت زمان حيات Session را مشخص می نمايد . مقدار timeoute بر اساس زمان درخواست ارزيابی می گردد . مثلا" در صورتی كه مقدار timeout بيست دقيقه باشد و در خواستی در ساعت ده و ده دقيقه دريافت گردد ، timeout در ساعت ده و سی دقيقه به اتمام می رسد .
• stateConnnectionString :از خصلت فوق به منظور مشخص نمودن آدرس TCP/IP و پورت جهت ارتباط يا Windows Service providing state management استفاده می گردد ( در مواردی كه mode=StateServer در نظر گرفته شود ) .
• stateNetworkTimeout : مقدار timeout ( بر حسب ثانيه ) را در زمان ذخيره state در يك out-of-process session ( نظير StateServer ) ، مشخص می نمايد .
• sqlConnectionString : از خصلت فوق جهت ارتباط با بانك اطلاعاتی SQL Server برای ذخيره و بازيابی داده session استفاده می گردد ( در مواردی كه mode=SQLServer در نظر گرفته شود) .
پيكربندی Session State با استفاده از Connection string : كد زير يك نمونه از پيكربندی Session State با استفاده از connection string را نشان می دهد :
<configuration> |
پيكربندی ترجمه
هر نوع تغيير در فايل ترجمه شده پويا باعث می گردد كه تمامی منابع متاثر از تغييرات شوند و به صورت پويا invalidated و مجددا" ترجمه گردند . مكانيزم فوق پياده كنندگان را قادر می سازد كه به سرعت برنامه های وب را با حداقل overhead اجراء نمايند. چراكه پس از تشخيص تغييرات و ترجمه پويا ، می توان بلافاصله از امكانات برنامه ها استفاده نمود .
پتانسيل ترجمه پويا در ASP.NET 2.0 نسبت به ASP.NET 1.x افزايش و فايل های ديگری نظير كلاس فايل ها را نيز تحت پوشش قرار می دهد .
برای پيكربندی تنظيمات ترجمه از بخش <compilation> در فايل های web.config و يا machine.config استفاده می گردد . ASP.NET engine ، در زمان مورد نياز صفحه را ترجمه و كد توليد شده را در code cache ذخيره می نمايد .از cache فوق در زمان اجرای صفحات ASP.NET استفاده می گردد .
كد زير گرامر بخش <compilatioin> را نشان می دهد .
<!-- compilation Attributes --> |
توضيحات :
• maxBatchSize : حداكثر تعداد صفحات و يا كلاس را كه می توان در يك batch ترجمه نمود، مشخص می نمايد. ( مقدار پيش فرض 1000 )
• maxBatchGeneratedFileSize : حداكثر اندازه خروجی يك batch assembley ترجمه شده را نشان می دهد ( مقدار پيش فرض 3000 )
• batchTimeout : زمان ( بر حسب ثانيه ) ترجمه batch را مشخص می نمايد . در صورتی كه زمان فوق قبل از اتمام ترجمه به پايان رسيده باشد ، يك exception محقق می گردد ( مقدار پيش فرض پانزده ثانيه است) .
• debug : آيا می بايست اسمبلی های توليد شده را ترجمه ويا ديباگ نمود ؟ (مقدار پيش فرض False ).
• defaultLanguage : زبان برنامه نويسی پيش فرض نظير VB و يا #C برای استفاده در فايل های ترجمه پويا را مشخص می نمايد.
• tempDirectory : دايركتوری مورد نظر برای استفاده موقت در حين ترجمه را مشخص می نمايد . به صورت پيش فرض ، ASP.NET فايل موقت را در مسير
[WinNT\Windows]\Microsoft.NET\Framework\[version]\Temporary ASP.NET ايجاد می نمايد .
• compilers : بخش <compilers> ، می تواند شامل چندين زير عنصر <compile> باشد كه از آنان به منظور ايجاد يك تعريف جديد كمپايل استفاده می گردد .
• numRecompilesBeforeAppRestart : تعداد دفعات ترجمه ، قبل از راه اندازی برنامه مشخص می نمايد .
قابليت های مرورگر
پس از دريافت يك درخواست از يك مرورگر ، browser capabilities component قابليت های مرورگر را از طريق هدر درخواست شناسائی و برای هر نوع مرورگر يك مجموعه از تنطيمات مرتبط با برنامه را ترجمه می نمايد . تنظيمات فوق را می توان به صورت ايستا انجام و يا از هدر درخواست ارسالی استفاده نمود . يك برنامه می تواند در صورت ضرورت تنظيمات فوق را را توسعه و يا تغيير دهد .
در ASP.NET 2.0 تمامی اطلاعات مربوط به قابليت های مرورگر در "فايل های تعريف مرورگر" ارائه می گردند . اين نوع فايل ها ، فايل هائی با انشعاب browser.* و فرمت xml می باشند . يك فايل ممكن است شامل تعريف بيش از يك نوع مرورگر باشد . فايل های فوق در زمان نصب فريمورك در آدرس
[WinNT\Windows]\Microsoft.NET\Framework\xxxxx\CONFIG\Browsers نصب می گردند . ( در ASP.NET 1.x ، اطلاعات مربوط به پتانسيل هر مرورگر در فايل های machine.config و web.config ذخيره می گردد ).
هر مرورگر به عنوان يك موجوديت و با استفاده از عنصر <browser> تعريف و دارای يك id مختص به خود است كه يك كلاس از مرورگر را به همراه كلاس parent مشخص می نمايد . <browsers> ، عنصر ريشه در فايل های تعريف مرورگر است و از خصلت id به منظور تمايز بين تعاريف هر يك از مرورگر ها ( در صورتی كه بيش از يك مورد در يك فايل تعريف شده باشد ) ، استفاده می گردد .
قبل از اجرای يك برنامه ASP.NET ، فريمورك تمامی تعاريف مرورگر را در يك اسمبلی ترجمه و آنان را در GAC ذخيره می نمايد .
در صورت تغيير فايل های تعريف مرورگر در سطح سيستم ، تغييرات به صورت اتوماتيك بر روی هر يك از برنامه های ASP.NET اعمال نخواهد شد . بنابراين ، اين مسئوليت پياده كنندگان و يا ابزارهای نصب است كه اطلاعات فوق را بهنگام نمايند . اطلاعات بهنگام شده مرورگر را می توان با استفاده از برنامه aspnet_regbrowsers.exe برای تمامی برنامه های ASP.NET ارسال نمود . پس از اجرای برنامه فوق ، اطلاعات مرورگر مجددا" ترجمه و اسمبلی جديد در GAC ذخيره می گردد . از اسمبلی فوق تمامی برنامه های ASP.NET استفاده می نمايند .
خطاهای سفارشی
• نمايش كد منبع و پيام خطاء برای كاربران عادی هيچگونه ارزش اطلاعاتی ندارد، پس چرا می بايست آنان را نمايش داد ؟
• نمايش كد منبع و پيام خطاء بيش از همه مهاجمان فرصت طلب را خوشحال خواهد كرد چراكه شرايط مناسبی برای ارتقاء دانش آنان به منظور برنامه ريزی حملات فراهم می گردد .
ASP.NET با ارائه يك زيرساخت مناسب امكان پيشگيری از نمايش اينگونه خطاها را در اختيار پياده كنندگان برنامه های وب قرار می دهد . بدين منظور از بخش <customeErrors> در فايل web.config برای تعريف پيام های خطاء سفارشی و سياست نمايش جزئيات خطاء استفاده می گردد . نحوه استفاده از عنصر فوق به صورت زير است :
<customErrors defaultRedirect="[url]" mode="[on/off/remote]"> |
توضيحات :
• mode : مقدار نسبت داده شده به اين خصلت وضعيت نمايش خطاء سفارشی را مشخص می نمايد . در صورتی كه مقدار اين خصلت on باشد ، خطاهای سفارشی نمايش داده می شوند . در صورتی كه مقدار mode معادل off باشد ، خطاهای سفارشی نمايش داده نخواهند شد و در صورتی كه مقدار اين خصلت remote در نظر گرفته شود ، خطاهای سفارشی صرفا" برای كاربران از راه دور نمايش داده می شود .
• customeErrors : اين بخش شامل چندين زيرعنصر <error> است كه از آنان به منظور تعريف خطاهای سفارشی استفاده می گردد . هر زير عنصر <error> می تواند شامل يك خصلت statusCode و يك URL باشد .
<configuration> |
