نکته: راههای اشاره شده برای مقابله با شنود پارامترها برای تمام شرایط قابل استفاده نیستند.
راه حل اول: استفاده از دستور With Recompile
مشکل شنود پارامتر این است که در اولین اجرای پروسیجر، پلن اجرایی را بر اساس پارامترهای ارسالی اولیه ایجاد میکند. راه حل غلبه بر این مشکل، کامپایل مجدد پروسیجر، بعد از هر اجرای آن است. بهمین جهت از دستور WITH RECOMPILE هنگامیکه قصد ایجاد پروسیجر را دارید استفاده نمایید. مانند کد زیر:
CREATE PROC [dbo].[DisplayBillingInfo] @BeginDate DATETIME, @EndDate DATETIME WITH RECOMPILE AS SELECT BillingDate, BillingAmt FROM BillingInfo WHERE BillingDate between @BeginDate AND @EndDate;
DBCC FREEPROCCACHE; EXEC dbo.DisplayBillingInfo @BeginDate = '2005-01-01', @EndDate = '2005-01-03'; EXEC dbo.DisplayBillingInfo @BeginDate = '1999-01-01', @EndDate = '1999-12-31';
راه حل دوم: غیر فعال نمودن شنود پارامتر
روش دیگر برطرف کردن مشکلات مرتبط با شنود پارامتر، غیر فعال کردن آن است. البته منظور از غیر فعال کردن، غیر فعال نمودن گزینهای در بانک اطلاعاتی نیست؛ بلکه با تغییر متن و نحوهی اجرا، میتوان شنود را غیر فعال نمود. در کد زیر با تغییر نحوه اجرای پروسیجر، قابلیت شنود پارامتر غیر فعال شده است:
CREATE PROC [dbo].[DisplayBillingInfo] @BeginDate DATETIME, @EndDate DATETIME WITH RECOMPILE AS DECLARE @StartDate DATETIME; DECLARE @StopDate DATETIME; SET @StartDate = @BeginDate; SET @StopDate = @EndDate; SELECT BillingDate, BillingAmt FROM BillingInfo WHERE BillingDate between @StartDate AND @StopDate;
راه حل سوم: ایجاد چند نوع پروسیجر
راه دیگر، ایجاد پروسیجرهای متفاوت برای پارامترهایی با کاردینالیتی متفاوت است. بهعبارت دیگر، دسته بندی پارامترهای ارسالی و ایجاد پروسیجرهایی خاص همان دسته. در مثالهای این سری از مطالب، دو دسته پارامتر 1) بازه زمانی کوتاه، مثلا چند روز و 2) بازه زمانی بلند، مثلا ماهیانه وجود داشت که میتوانید 2 دسته پروسیجر را یکی برای بازههای روزانه و دیگری برای بازههای زمانی ماهیانه ایجاد نمایید.
CREATE PROC [dbo].[DisplayBillingInfoNarrow] @BeginDate DATETIME, @EndDate DATETIME AS SELECT BillingDate, BillingAmt FROM BillingInfo WHERE BillingDate between @BeginDate AND @EndDate; GO CREATE PROC [dbo].[DisplayBillingInfoWide] @BeginDate DATETIME, @EndDate DATETIME AS SELECT BillingDate, BillingAmt FROM BillingInfo WHERE BillingDate between @BeginDate AND @EndDate; GO DROP PROCEDURE [dbo].[DisplayBillingInfo]; GO CREATE PROC [dbo].[DisplayBillingInfo] @BeginDate DATETIME, @EndDate DATETIME AS IF DATEDIFF(DD,@BeginDate, @EndDate) < 4 EXECUTE DisplayBillingInfoNarrow @BeginDate, @EndDate ELSE EXECUTE DisplayBillingInfoWide @BeginDate, @EndDate GO
مقایسه رکوردهای دو جدول
----SQL SERVER 2005 Method USE AdventureWorks; GO SELECT ProductID FROM Production.Product EXCEPT SELECT ProductID FROM Production.WorkOrder; GO ----SQL SERVER 2000 Method which works IN SQL SERVER 2005 USE AdventureWorks; GO SELECT ProductID FROM Production.Product WHERE ProductID NOT IN ( SELECT ProductID FROM Production.WorkOrder); GO
امروزه یکی از بزرگترین دغدغههای فعالان حوزه آی تی، برقراری امنیت اطلاعات میباشد. با پدید آمدن بانکهای دادهای آماری و مالی، حساسیت مسئله صد چندان میشود. در ادامه چک لیستی را ارائه مینمایم که با کمک آن میتوانید تا حدود بسیار خوبی امنیت نرم افزار تحت وب خود را برقرار نمایید. در برخی از موارد مثالهایی از تکنولوژی مایکروسافت آورده شده است که این بدلیل تخصص نویسنده در تکنولوژیهای مایکروسافت میباشد. در صورتیکه شما از تکنولوژیها و زبانهای سورس باز بهره میبرید، میبایست معادل مورد ذکر شده را در زبان مورد استفاده خود بیابید .
ابتدا اجازه دهید مقداری با حملات آشنا شویم و سپس راه مقابله را در کنار هم بررسی نماییم.
مهمترین و خطرناکترین حملات سطح وب :
حمله XSS
این نوع حملات بدین صورت است که هکر با استفاده از فرمهای عمومی یا خصوصی (پنلهای سایت) اقدام به ثبت کدهای مخرب جاوااسکریپت درون دیتابیس شما مینماید. همانطور که میدانید پایه اصلی سیستمهای احراز هویت، ساخت فایل کوکی بر روی کامپیوتر کاربران میباشد. زمانی که مطلب ثبت شدهی هکر برای کاربران شما نمایش داده میشود، کدهای جاوا اسکریپت هکر روی مرورگر کاربر، اجرا شده و اطلاعات کوکیهای کاربر به راحتی برای سایت هکر ارسال میشود (معمولا هکر یک صفحه روی وب میسازد تا بتواند اطلاعات دریافتی از کدهای جاوا اسکریپت خود را دریافت و در جایی ذخیره کند).
حال هکر به راحتی کوکی را بر روی مرورگر خودش تنظیم میکند و بعد وارد سایت شما میشود. سیستم شما او را با کاربر شما اشتباه میگیرد و به راحتی هکر به اطلاعات پنل کاربری کاربر(ان) شما دست پیدا میکند.
حمله SQL Injection
این حمله معروفترین حمله است که تقریبا با قدرت میتوانم بگویم که درتکنولوژی ASP.Net با امکانات فوق العادهای که بصورت توکار در دات نت در نظر گرفته شده است، بصورت کامل به فراموشی سپرده شده است. فقط 2 تا نکتهی ریز هست که باید در کدهایتان رعایت کنید و تمام.
این حمله بدین صورت است که هکر یک سری دستورات SQL را در کوئری استرینگ، به صفحات تزریق میکند و بدین صورت میتواند در کدهای کوئری TSQL شما اختلال ایجاد کند و اطلاعات جداول شما را بدست بیاورد. در این نوع حمله، هکر از طریق باگ سطح کد نویسی کدهای نرم افزار، به دیتابیس حمله میکند و اطلاعاتی مثل نام کاربری و کلمهی عبور ادمین یا کاربران را میدزد و بعد میرود داخل پنل و خرابکاری میکند.
حمله CSRF
این حمله یکی از جالبترین و جذابترین نوع حملات است که هوش بالای دوستان هکر را نشون میدهد. عبارت CSRF مخفف Cross Site Request Forgery است (احتمالا دوستان ام وی سی کار، این عبارت برایشان آشناست).
در این نوع حمله هکر یک فایل برای کاربر شما از طریق ایمیل یا روشهای دیگر ارسال میکند و کاربر را به این سمت سوق میدهد که فایل را باز کند. کاربر یک فایل به ظاهر معمولی مثل عکس یا ... را میبیند و فایل را باز میکند. وقتی فایل باز میشود دیتای خاصی دیده نمیشود و گاهی هم اروری مبنی بر ناقص بودن فایل یا ... به کاربر نمایش داده میشود و کاربر فکر میکند که فایل، ناقص برای ارسال شده ...
اما در حقیقت با کلیک بر روی فایل و باز کردن آن یک درخواست POST از کامپیوتر کاربر برای سایت شما ارسال میشود و در صورتیکه کاربر در آن زمان در سایت شما لاگین باشد، سایت درخواست را با روی باز میپذیرد و درخواست را اجرا میکند. بدین صورت هکر میتواند درخواستهایی را به سرویسهای سایت شما که مثلا برای حذف یک سری داده است، ارسال کند و اطلاعات کاربر را حذف کند.
حمله Brute Force
در این حمله، هکر از یک سری برنامه برای ارسال درخواستهای مکرر به فرمهای سایت شما استفاده میکند و بدین صورت فرمهای عمومی سایت شما مورد حجوم انبوهی از درخواستها قرار میگیرد که این امر در بهترین حالت موجب ثبت کلی دیتای اسپم در دیتابیس شما و در بدترین حالت موجب داون شدن سایت شما میشود.
حمله DDOS
این نوع حمله مانند حمله Brute Force است؛ با این تفاوت که درخواست به همهی صفحات شما ارسال میشود و معمولا درخواستها از چندین سرور مختلف برای سایت شما ارسال میشوند و حجم درخواستها به قدری زیاد است که عملا سرور شما هنگ میکند و کاملا از دسترس خارج میشود. این نوع حمله در سطح کد راه حل زیادی ندارد و در سطح سرور و فایروال باید حل شود و حل آن هم بدین صورت است که درخواستهای بیش از حد طبیعی از یک آی پی خاص تشخیص داده شده و به سرعت، آی پی بلاک میشود و از آن به بعد درخواستهای آن آی پی در فایروال از بین میرود و دیگه به سرور نمیرسد.
حمله SHELL
شل فایلی است خطرناک که اگر بر روی سرور سایت شما آپلود و اجرا شود، هکر از طریق آن دسترسی کاملی به کل سرور سایت شما خواهد داشت. فایلهای دیگری با نام بکدور [1] نیز وجود دارند که نویسنده تمایل دارد آنها را نیز از نوع حمله SHELL معرفی نماید. این نوع از فایلها به مراتب بسیار خطرناکتر از فایلهای شل میباشند؛ تا جایی که ممکن است سالها هکر به سروی دسترسی داشته باشد و مدیر سرور کاملا از آن بی خبر باشد. اینجاست که باید شدیدا مراقب فایلهایی که روی سایت شما آپلود میشوند باشید. نویسنده به تمامی خوانندگان پیشنهاد مینماید، در صورتیکه نرم افزار حساسی دارند، حتما از سرور اختصاصی استفاده نمایند؛ چرا که در هاستهای اشتراکی که در آنها فضا و امکانات یک سرور بصورت اشتراکی در اختیار چندین سایت قرار میگیرد، وجود باگ امنیتی در سایر سایتهای موجود بر روی سرور اشتراکی میتواند امنیت سایت شما را نیز به مخاطره بیاندازد. نویسنده تهیهی سرور اختصاصی را شدیدا به توسعه دهندگان سایتهای دارای تراکنشهای بانکی بالا (داخلی یا خارجی) پیشنهاد مینماید. زیرا درگاه تراکنشهای بانکی بر روی آی پی هاست شما قفل میشوند و در صورتیکه سرور بصورت اختصاصی تهیه شده باشد، آی پی سرور شما فقط و فقط در اختیار شماست و هکر نمیتواند با تهیه هاستی بر روی سرور اشتراکی شما، به راحتی آی پی قفل شده در درگاه بانکی شما را در اختیار داشته باشد. بدیهی است تنها در اختیار داشتن آی پی سرور شما جهت انجام خرابکاری در درگاه بانکی شما کافی نیست. ولی به نظر نویسنده این مورد در بدترین حالت ممکن 30% کار هکر میباشد. البته بحث حمله شل به سطح مهارت متخصصان سرورها نیز بستگی دارد. نویسنده اظهار میدارد اطلاعات دقیقی از تنظیماتی که بتواند جلوی اجرای انواع شل و یا جلوی دسترسی فایلهای شل را بگیرد، ندارد. بنابراین از متخصصان این حوزه دعویت مینماید اطلاعاتی درباره این موضوع ارائه نمایند.
حمله SNIFF
در این نوع حملات، هکر پکتهای رد و بدل شدهی بین کاربران و سرور شما را شنود مینماید و به راحتی میتواند اطلاعات مهمی مثل نام کاربری و رمز عبور کاربران شما را بدست آورد.
چک لیست امنیتی پروژههای نرم افزاری تحت وب
- بررسی کامل ورودیهای دریافتی از فرمهای سایت؛ هم در سمت کلاینت و هم در سطح سرور .
- در تکنولوژی دات نت به منظور تمیز سازی ورودیها و حذف تگهای خطرناکی همچون تگ script، کتابخانهای با نام Microsoft.Security.Application وجود دارد. کتابخانههای سورس باز دیگری نیز وجود دارند که نمونه آن کتابخانه AntiXss [2] سایت نوگت [3] میباشد.
- بررسی کامل ورودیهای دریافتی از کوئری استرینگهای [4] سایت. اگر از ASP.Net MVC استفاده مینمایید، تا حدی زیادی نیاز به نگرانی نخواهد داشت، زیرا تبدیلات [5] در سیستم Model Binding انجام میپذیرد و این موضوع تا حد زیادی شما را در برابر حملات SQL Injection مقاوم مینماید.
- حتما در فرمهای عمومی سایتتان از تصویر کپچا با امنیت بالا استفاده نمایید. این موضوع جهت شناخت روباتها از انسانها میباشد و شما را در برابر حملات Brute Force مقاوم مینماید.
- حتما سیستم شخصی سازی صفحات ارور را فعال نمایید و از نمایش صفحات ارور حاوی اطلاعات مهمی مانند صفحات ارور ASP.Net جلوگیری نمایید. این موضوع بسیار حساس میباشد و میتواند نقاط ضعف نرم افزار شما را برای هکر نمایان کند. حتی ممکن است اطلاعات حساسی مانند نام بانک اطلاعاتی، نام کاربری اتصال به بانک اطلاعاتی و نام جداول بانک اطلاعاتی شما را در اختیار هکر قرار دهد.
- استفاده از ORM ها یا استفاده از پروسیجرهای پارامتریک. این موضوع کاملا شما را در برابر حملات SQL Injection مقاوم مینماید. کما اینکه ORM ها، سطحی از کش را بصورت توکار دارا میباشند و این موضوع در سرعت دستیابی به دادهها نیز بسیار تاثیر گذار است. از طرف دیگر بانک اطلاعاتی SQL نیز امکانات توکاری جهت کش نمودن پرس و جوهای [6] پارامتریک دارد.
- لاگ کردن ارورهای سطح کد و سطح روتینگ [7] . یکی از مهمترین خصیصههای پروژههای با کیفیت، لاگ شدن خطاهای سطح کد میباشد. این امر شما را با نقاط حساس و ضعفهای نرم افزار آگاه میسازد و به شما اجازه میدهد به سرعت در جهت رفع آنها اقدام نمایید. لاگ نمودن خطاهای سطح روتینگ شما را از فعالیتهای هکرها جهت یافتن صفحات لاگین و صفحات مدیریتی پنل مدیریتی سایت اگاه مینماید، همچنین شما را از حملات SQL Injection نیز آگاه مینماید.
- جلوگیری از ایندکس شدن صفحات لاگین پنل مدیریت سایت در موتورهای جستجو. بخش مهمی از عملیات هکر ها، قرار دادن روباتهای تشخیص رمز بر روی صفحات لاگین میباشد که به نوعی میتوان این نوع حملات را در دسته حملات Brute Force قرار داد. موتورهای جستجو یکی از ابزارهای مهم هکرها میباشد. عملیات هایی مانند یافتن صفحات لاگین پنل مدیریتی یکی از کاربردهای موتورهای جستجو برای هکرها میباشد.
- لاگ کردن ورود و خروج افراد به همراه تاریخ، زمان، آی پی افراد و وضعیت لاگین. با کمک این موضوع شما میتوانید ورود و خروج کاربران نرم افزار خود را کنترل نمایید و موارد غیر طبیعی و مشکوک را در سریعترین زمان مورد بررسی قرار دهید.
- استفاده از روالهای استاندارد جهت بخش "فراموشی کلمه عبور". همیشه از استاندارهای نرم افزارهای بزرگ پیروی نمایید. بدیهی است استاندارهای استفاده شده در این نرم افزارها بارها و بارها تست شده و سپس بعنوان یک روال استاندارد در همهی نرم افزارهای بزرگ بکار گرفته شده است. استاندارد جهانی بخش "فراموشی کلمه عبور" که در اغلب نرم افزارهای معروف جهان بکار گرفته شده است، عبارت است از دریافت آدرس ایمیل کاربر، احراز هویت ایمیل وارد شده، ارسال یک نامهی الکترونیکی [8] حاوی نام کاربری و لینک تنظیم کلمه عبور جدید به ایمیل کاربر. بهتر است لینک ارسال شده به ایمیل کاربر بصورت یکبار مصرف باشد. کاربر پس از کلیک بر روی لینک تنظیم کلمه عبور جدید، وارد یکی از صفحات سایت شده و میتواند کلمهی عبور جدیدی را برای خود ثبت نماید. در پایان، کاربر به صفحهی ورود سایت هدایت شده و پیامی مبنی بر موفقیت آمیز بودن عملیات تغییر کلمهی عبور به او نمایش داده میشود. البته روال ذکر شده حداقل رول استانداردی میباشد و میتوان در کنار آن از روالهای تکمیل کنندهای مانند پرسشهای امنیتی و غیره نیز استفاده نمود.
- قراردادن امکاناتی جهت بلاک نمودن آی پیها و غیر فعال نمودن حساب کاربری اعضای سایت. در نرم افزار باید این امکان وجود داشته باشد که آی پی هایی که بصورت غیر طبیعی در سایت فعالیت مینمایند و یا مکررا اقدام به ورود به پنل مدیریتی و پنل کاربران مینمایند را بلاک نماییم. همچنین در صورت تخلف کاربران باید بتوان حساب کاربری کاربر خاطی را مسدود نمود. این موضوع میتواند بسته به اندازه پروژه و یا سلیقه تیم توسعه بصورت خودکار، دستی و یا هر دو روش در نرم افزار در تعبیه شود.
- امن سازی سرویسهای ای جکس و چک کردن ای جکس بودن درخواست ها. حتما جلوی اجرای سرویسهای درون نرم افزاری از بیرون از نرم افزار را بگیرید. سرویسهای ای جکس یکی از این نوع سرویسها میباشند که در نرم افزارها جهت استفادههای داخلی در نظر گرفته میشوند. در این نوع سرویسها حتما نوع درخواست را بررسی نمایید و از پاسخگویی سرویسها به درخواستهای غیر ای جکسی جلوگیری نمایید. در ASP.Net MVC این امر توسط متد Request.IsAjaxRequest انجام میپذیرد .
- محدود کردن سرویسهای حساس به درخواستهای POST. حتما از دسترسی به سرویس هایی از نوع Insert,Update و Delete از طریق فعل GET جلوگیری نمایید. در ASP.Net MVC این سرویسها را به فعل POST محدود نموده و در ASP.Net Web API این سرویسها را به افعال POST,PUT و DELETE محدود نمایید.
- عدم استفاده از آی دی در پنلهای کاربران بالاخص در آدرس صفحات (کوئری استرینگ) و استفاده از کد غیر قابل پیش بینی مثل GUID به جای آن. حتی الامکان بررسی مالکیت دادهها در همه بخشهای پنلهای کاربری سایت را جهت محکم کاری بیشتر انجام دهید تا خدای نکرده کاربر با تغییر اطلاعات کوئری استرینگ صفحات نتوانند به دادههای یک کاربر دیگه دسترسی داشته باشند.
- حتی الامکان پنل مدیران را از کاربران بصورت فیزیکی جدا نمایید. این مورد جهت جلوگیری از خطاهایی است که ممکن است توسط توسعه دهنده در سطح سیستم مدیریت نقش رخ دهد و موجب دسترسی داشتن کاربران به بخش هایی از پنل مدیریتی شود.
- استفاده از الگوریتمهای کدگذاری ترکیبی و کد کردن اطلاعات حساس قبل از ذخیره سازی در بانک اطلاعاتی. اطلاعات حساسی مانند کلمات عبور را حتما توسط چند الگوریتم کدگذاری، کدگذاری نمایید و سپس درون بانک اطلاعاتی ذخیره نمایید.
- تنظیمات حساس نرم افزار را درون فایل web.config قرار دهید و حتی الامکان آنها را نیز کدگذاری نمایید. بصورتی که اطلاعات قابلیت دیکد شدن را داشته باشند.
- ساخت پروژه بصورت چند لایه. این موضوع جهت جلوگیری از دستیابی هکر به ساختار لایههای پروژههای شما میباشد. به بیان دیگر اگر نهایتا هکر بتواند به اطلاعات FTP هاست شما دست یابد، استفاده از تکنولوژی چند لایه در بدترین حالت هکر را از دستیابی به اطاعات لایههای زیرین نرم افزار باز میدارد. البته این کار برای هکرها غیر ممکن نیست، اما بسیار سخت و زمان بر میباشد.
- اشتراک گذاری اینترفیس در سرویسهای خارج برنامه ای و عدم اشتراک گذاری کلاس اصلی. این موضوع از دستیابی هکر به بدنه سرویسها و پیاده سازیهای آنها جلوگیری مینماید.
- استفاده از تکنیکهای مقابله با CSRF در همه سرویسهای POST. در ASP.NET MVC اتریبیوتی با نام AntiForgery جهت مقاوم سازی سرویسها از حملات CSRF وجود دارد. مکانیزم بدین صورت است که در تمامی فرمهای سایت یک کد منحصر به فرد تولید میگردد که همراه درخواست GET به کامپیوتر کاربر ارسال میشود و در هنگام ارسال درخواست POST به سرور، صحت کد مورد نظر بررسی شده و در صورت صحت، اجازهی اجرای سرویس به درخواست داده میشود. بدین صورت وقتی کاربر سایت شما فایل آلودهای را باز مینماید، در خواست ارسالی هکر که توسط فایل باز شده، به سرور سایت ما ارسال میگردد، فاقد کد منحصر به فرد بوده و از اجرای سرویس جلو گیری میشود.
- استفاده از سیستمهای مدیریت نقش امن مانند IDENTITY در ASP.Net MVC و یا استفاده از امکانات توکار دات نت در سیستمهای مدیریت نقش شخصی سازی شده [9] . بدیهی است امنیت این سیستمها بارها و بارها تست شده است.
- بررسی فرمت و پسوند فایلهای آپلود شده. توجه نمایید که بررسی پسوند فایلها کافی نبوده و فرمت فایلها نیز میبایست بررسی شود. حتی نویسنده پیشنهاد مینماید فایلها را به نوعهای مرتبطشان تبدیل [10] نمایید. در حوزه هک بایند نمودن انواع ویروس، تروجان، شل و بک دور [11] به فایلهای تصویری و متنی یک امر بسیار رایج است. بنابراین حساسیت زیادی روی این موضوع قرار دهید. نویسنده توصیه مینماید کتابخانههای کاملی برای این موضوع تدارک ببینید تا در تمامی پروژهها نیاز به ایجاد مجدد آنها نداشته باشید و سعی نمایید در هر پروژه این کتابخانهها را تکمیلتر و بهتر نمایید.
- تنظیم IIS جهت جلوگیری از اجرای فایلهای اجرایی در مسیر آپلود فایلها. شاید جمله بیان شده به نظر ترسناک و یا سخت برسد، اما این کار با نوشتن چند تگ ساده در فایل Web.Config به راحتی قابل انجام است و نیاز به هیچ نوع کدنویسی ندارد.
- آپلود فایلها در پوشه App_Data و دسترسی به فایلها از طریق سرویسهای خود شما. پوشه App_Data پوشهای امن است و دسترسی مستقیم از طریق آدرس بار مرورگر به فایلهای درون آن توسط IIS داده نمیشود و افراد فقط از طریق سرویسهای خود شما میتوانند به فایلهای داخل این پوشه دسترسی داشته باشند. بدین صورت در سرویسهای خود میتوانید با تبدیل نمودن [12] فایلها به نوع خودشان (تصویر. پی دی اف یا ...) هکر را نا امید نمایید. این موضوع شما را در مقابل حملات SHELL مقاوم مینماید.
- استفاده از تکنیکهای لاگین چند سطحی برای پنل ادمین. در این روش شما حتی با داشتن نام کاربری و کلمهی عبور ادمین، قادر نخواهید بود وارد پنل ادمین شوید. نویسنده ابزار میدارد که این روش، یک روش ابداعی میباشد که از ترکیبی از احرا هویت ساده توسط نام کاربری و کلمهی عبور به همراه تکنیکهای احراز هویت ایمیل و موبایل مدیریت سایت میباشد.
- استفاده از SSL بسیار اهمیت دارد. بالاخص اگر نرم افزار شما Service Oriented باشد و نرم افزار شما سرویس هایی جهت اتصال به اپلیکیشنهای خارجی مثل اپلیکیشن اندروید دارد. این مورد در صفحات لاگین نیز بسیار مهم است و موجب میشود نام کاربری و کلمه عبور کاربران شما بصورت هش شده بین کامپیوتر کاربر و سرور شما رد و بدل شود و عملا شنود پکتها فایده ای برای هکر نخواهد داشت، زیرا دادهها توسط الگوریتمهای امنیتی که بین سرور و مرورگر کاربران توافق میشود کدگذاری شده و سپس رد و بدل میشوند.
[1] Back Door
[2] https://www.nuget.org/packages/AntiXss/
[3] www. Nuget.org
[4] Query String
[5] Casting
[6] Procedure
[7] Routing
[8] Email
[9] Custom Role Provider
[10] Cast
[11] Back Door
[12] Cast
برای استفاده از این مزایا باید سرویس Microsoft SharePoint Foundation User Code Service فعال باشد .
استفاده از Sandbox Solution نیازمند 3 چیز است :
1 - User Code Service یا SPUCHostService.exe : این سرویس وظیفه مدیریت کدهای Sandbox روی سرور و میزبانی درخواستهای Sandbox به سرور را دارد.
2 - Sandbox Worker Process یا SPUCWorkerProcess.exe : این سرویس برای مدیریت پردازش کدهای اجرایی Sandbox استفاده میشود خصوصا در مورارد امنیتی (فرض کنید درون کد حلقه بی نهایتی وجود داشته باشد. اگر بار اجرایی آن بر روی w3wp.exe باشد ، باعث متوقف شدن کارکرد تمام پروسه میشود. بار این مسئولیت بر دوش SPUCWorkerProcess.exe میباشد )
3 - Sandbox Worker Process Proxy یا SPUCWorkerProcessProxy.exe : این سرویس برای اجرای کدهای Client Object Model در sandbox استفاده میشود.
می توانید ارتباط پردازههای فوق را در نمودار زیر مشاهد کنید :
با توجه به این توضیحات به دلیل استفاده از Sandbox میپردازیم :
1 - sandbox Solutionها امن هستند.
2 - sandbox Solutionها میتوانند مانیتور شوند.
3 - sandbox Solutionها حداقل تاثیر را روی هم دارند.
4 - sandbox Solutionها عملیات I/O کمی روی فایلهای سیستمی دارند
5 - sandbox Solutionها امکان debugging دارند
6 - sandbox Solutionها امکان توسعه ، انتشار و به روز رسانی دارند
7 - sandbox Solutionها امکان تعریف Policy برای CAS ایجاد میکند (Code Access Security برای قابل اطمینان ساخت کد ها)
8 - sandbox Solutionها امکان اعتبار سنجی به کمک کلاس SPSolutionValidator را میدهد.
9 - sandbox Solutionها امکان تعریف SLA های مختلف را میدهد.
چه قسمت هایی توسط Sandbox Solution پشتیبانی میشود :
هنگام ایجاد یک پروژه از نوع sandbox در ویژوال استودیو ، یکسری امکانات از برنامه نویس سلب میشود و محدودیتهای برای استفاده از کلاسها برای وی اعمال میشود .موارد زیر ، از جمله مواردی هستند که توسعه دهنده میتواند از آنها در sandbox استفاده کند :
Add-SPSolution c:\code\SharePointProject2\bin\debug\SharePointProject2.wsp
stsadm –o addsolution –name SharePointProject2.wsp
اجرای یک Script حاوی دستورات Go در سی شارپ
خیر، همه جا جواب نمیده! عرض کردم، نیازی به جداسازی Script بر اساس GOهای موجود در اون ندارید. Script زیر رو در نظر بگیرید (بعنوان مثالی نقض) تا متوجه بشید چرا کد شما نیز ایراد داره:
USE [MyDB] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[GO AND EAT]( [Id] [int] IDENTITY(1,1) NOT NULL, [MyVal] [decimal](18, 0) NOT NULL, ) ON [PRIMARY] GO
موفق باشید.
php, oracle adf, asp.net web forms, asp.net mvc, ...
- در ابتدا کاربر میاد به idp و رجیستر میکنه تا بتونه از سامانههای مختلف متصل به idp استفاده کنه
- کاربر جهت لاگین در کلاینت (سامانه)، هدایت میشه به idp (این کار توسط همون کلاینت انجام میشه)
- بعد از احراز هویت در idp، کاربر ریدایرکت میشه به همون برنامه (کلاینت)
- حالا وقتی برمیگرده به کلاینت، اون برنامه، "اطلاعات اصلی" کاربر (که از idp برگشته) رو داره
- کاربر رو در دیتابیس لوکال خودش جستجو میکنه (مثلا بر اساس subject_id)؛ یا پیداش میکنه و یا اگه کاربر در دیتابیس لوکال اون سامانه وجود نداشته باشه، بعنوان کاربر جدید درجش میکنه
- با کاربر مرحله قبل، در سامانه لوکال لاگین میکنه
- دیگه برنامه لوکال (کلاینت) با idp کاری نداره. چون سیاست داخلی خودش رو داره جهت هندل کردن sessionها و دسترسیها بر اساس roleهای لوکال در اون برنامه. تا زمانی که بخواد کاربر logout کنه.
- برای logout، کاربر در کلاینت لاگ اوت و سپس در سمت idp لاگ اوت میشه و مجددا به homepage سامانه لوکال ریدایرکت میشه
وارد کردن کتابخانه ها
این کتابخانه شامل دو فایل css و JS میباشد که بسته به محیطی که در آن کار میکنید متفاوت هستند. در این صفحه شما میتوانید برای 4 محیط Jquery ,JqueryUI , Bootstrap2 و Bootsrap3 بستهی مخصوصش را یا به صورت دانلود فایلها یا از طریق CDN دریافت نمایید. در اینجا هم یک دمو از قابلیتهای آن قابل مشاهده است.
برای شروع، کتابخانهی مورد نظر خود را دریافت و آنها را به صفحهی خود اضافه نمایید. در صورتیکه از Bootstrap استفاده میکنید، ابتدا فایلهای زیر را اضافه کنید:
<link href="//netdna.bootstrapcdn.com/bootstrap/3.0.0/css/bootstrap.min.css" rel="stylesheet"> <script src="http://code.jquery.com/jquery-2.0.3.min.js"></script> <script src="//netdna.bootstrapcdn.com/bootstrap/3.0.0/js/bootstrap.min.js"></script>
اولین حالتیکه میتوانید با این کتابخانه کار کنید، استفاده از خاصیت *-data است. نمونه زیر را در نظر بگیرید:
<a href="#" id="favsite" data-type="text" data-pk="1" data-url="@Url.Action(MVC.Categories.EditCategory())" data-title="Enter your favorite site">dotnettips.info</a>
$(document).ready(function () { $('#favsite').editable(); });
$(document).ready(function () { $.fn.editable.defaults.mode = 'inline'; $('#favsite').editable(); });
حالت بعدی که میتوان استفاده کرد به شکل زیر است:
<a href="#" id="favsite" >dotnettips.info</a>
$.fn.editable.defaults.mode = 'inline'; $(document).ready(function () { $('#favsite').editable({ type: 'text', pk: 1, url: '@Url.Action(MVC.Categories.EditCategory())', title: 'Enter your favorite site' }); });
خوبی این روش این است که میتوان اطلاعات بیشتری چون رویدادها را به آن پاس داد. تا الان با نحوهی انتساب آن به اشیاء آشنا شدیم. اجازه دهید تا با خصوصیات آن آشنا شویم.
AjaxOptions | همانطور
که متوجه شدید به طور خودکار اطلاعات ویرایش شده، به سمت آدرس داده شده،
به شیوه Post ارسال میگردند. در صورتیکه قصد دست بردن
در نوع درخواست را دارید، میتوانید از این ویژگی استفاده کنید: ajaxOptions: { type: 'put', dataType: 'json' } |
Anim | این
ویژگی که تنها در حالت inline پاسخ میدهد، میتواند زمان بسته شدن
x-editable را تغییر دهد که به طور پیش فرض با false مقداردهی شده است. جهت
تغییر زمان بسته شدن، کد زیر را وارد نمایید: anim:'false' //or anim: { duration: 2000 } |
autotext | در انتهای جدول آمده است. |
defaultValue | در
صورتیکه عنصر مورد نظر محتوایی نداشته باشد و این خصوصیت را
مقداردهی کنید، موقع ویرایش، این عبارت تعیین شده نمایش مییابد. در مثال
بالا باید متن تگ a را حذف کرده تا نتیجه را ببینید: (البته فیلد value نباید مقداری داشته باشد) defaultValue: 'default val' //or defaultValue: undefined //or defaultValue: null |
disabled | false کردن این ویژگی باعث غیرفعال شدن x-editable بر روی کنترل جاری میگردد. |
display | خاصیت
display یا مقدار بولین false را دریافت میکند، یا نال، یا یک تابع
callback را میتوان به آن پاس داد. این خصوصت زمانی صدا زده میشود که
اطلاعات به سمت آدرس سرور رفته و با موفقیت بازگشت داده میشوند (در صورتی
که این ویژگی غیرفعال باشد، بلافاصه بعد از تایید کاربر، از اطلاعات وارد شده
صدا زده میشود) و سپس متن جدید عنصر تغییر مییابد. حال اگر این خاصیت نال
که مقدار پیش فرض آن است باشد، متن تغییر مییابد. ولی اگر false باشد، متن سابق
باقی خواهد ماند و در صورتیکه تابعی به آن پاس داده باشید، طبق تابع شما
عمل خواهد کرد. پارامترهایی که تابع شما میتواند داشته باشد به شرح زیر است: value : مقدار جدید response : پاسخ سرور ( در صورتی که ارسال از طریق Ajax صورت گرفته باشد) و در صورتیکه عنصر شما checlklist یا select باشد که حاوی منبعی از مقادیر هست، مقادیرشان در قالب یک آرایه با نام sourceData بازگشت خواهد خورد. برای دسترسی به آیتمهای انتخابی هم از کد زیر استفاده میکنیم: $.fn.editableutils.itemsByValue(value, sourceData) |
emptyclass | معرفی یک کلاس css برای موقعیکه عنصر خالی است. |
emptytext | در صورتی خالی بودن عنصر، این متن را برای عنصر نمایش بده. |
highlight | بعد از به روز رسانی متن عنصر، آن را با این رنگ highlight خواهد کرد و کد رنگی باید در مبنای هگز باشد. مقدار پیش فرض آن false است. |
mode | دو
حالت نمایشی دارد که پیش فرض آن popup است و با باز کردن یک پنجره، مقدار
جدید را دریافت میکند. مورد بعدی inline است که به جای باز کردن پنجره،
متن عنصر را به حالت ویرایش تغییر میدهد. |
name | نام فیلدی که مقدارش تغییر میکند. |
onblur | زمانی که کاربر فوکوس را از ویرایشگر میگیرد، ویرایشگر چه پاسخی باید به آن بدهد، باز بماند؟ ignore ، بسته شود؟ cancel و یا مقدار داده شده را تایید کند؟submit |
params | پارامترهای درخواست ایجکسی که کنترل در حالت پیش فرض ارسال میکند؛ شامل Pk که آن را با id
رکورد پر میکنیم. name نام فیلدی که تغییر یافته است و value که مقدار جدید
است. در صورتیکه دوست دارید اطلاعات اضافیتری نیز ارسال شوند،
میتوانید از این خاصیت استفاده کنید و پارامترها را در قالب Object به آن
پاس کنید. ولی اگر بخواهید در کل همهی پارامترها را رونویسی کنید باید یک
تابع را به آن پاس کنید: params: function(params) { //در این حالت پارامترهای پیش فرض ارسال نشده و تنها پارامترهای معرفی شده در این تابع ارسال میشوند params.a = 1; return params; } |
pk | کلید
اصلی رکورد شما در دیتابیس یا هان id است. در صورتی که از کلیدهای ترکیبی
استفاده میکنید، نگران نباشید فکر آن را هم کرده اند.//کلید عدد pk:1, //کلید رشته ای pk:'dp123' //کلید ترکیبی pk:{id: 1, lang: 'en'} //معرفی یک تابع به آن و بازگشت |
Placement | این ویژگی فقط به درد حالت Popup میخورد که پنجره را کجای عنصر نمایش دهد و شامل چهار مقدار left,right,top,bottom میشود. |
saveonchange | زمانی
که مقدار جدید، برابر مقدار فعلی باشد و این خاصیت false باشد، هیچ تغییری رخ
نخواهد داد. ولی اگر برابر true باشد ،مقدار جدید اسال و جایگزین مقدار فعلی
خواهد شد. مقدار پیش فرض آن false است. |
selector |
با استفاده از این خصوصیت در عنصر انتخابی به دنبال عناصری که در selector
تعیین شده میگردد و حالت ویرایش را روی آنها فعال میکند. در این حالت استفاده از خصوصیات emptytext و autotext در ابتدای امر ممکن نیست و بعد از اولین کلیک قابل استفاده هستند. نکته بعدی اینکه شما باید کلاسهای زیر را دستی اضافه کنید. کلاس editable-click برای همه کنترلها وکلاس editable-empty به کنترلهای بدون مقدار و برای مقداردهی کنترلهای بدون مقدار میتوان از خاصیت ''=data-value استفاده کرد. <div id="user"> <!-- empty --> <a href="#" data-name="username" data-type="text" data-value="" title="Username">Empty</a> <!-- non-empty --> <a href="#" data-name="group" data-type="select" data-source="/groups" data-value="1" title="Group">Operator</a> </div> <script> $('#user').editable({ selector: 'a', url: '/post', pk: 1 }); </script> |
send | سه
مقدار auto,always و never را دریافت میکند. موقعی که شما آن را روی auto
تنظیم کنید؛ در صورتی مقادیر به سمت سرور ارسال میشوند که دو خاصیت url و
pk تعریف شده باشند. در غیر این صورت ویرایش فقط در حالت محلی و روی سیستم
کاربر رخ خواهد داد. |
showbuttons | در
صورتیکه با false مقداردهی شود، تایید فرم به طور خودکار انجام میگیرد و
اگر با یکی از مقادیر left یا Bottom پر شود، دکمهها را در آن قسمت نشان
میدهد. |
success | اطلاعات به سمت سرور
رفته و با موفقیت با کد 200 بازگشت داده شدهاند. در مستندات نوشته است، هر
کد وضعیتی غیر از 200 بازگشت داده شود، به سمت خاصیت error هدایت میشو.د ولی
آن طور که من با httpresponsemessage
تست کردم، چنین چیزی را مشاهده نکردم و مجددا success صدا زده شد. پس بهتر
هست دادهای را که به سمت کنترل برگشت میدهید، خودتان کنترل کنید. به خصوص
اگر انتقال اطلاعات صحیح باشد. ولی اگر در دیتابیس، تغییر با خطا روبرو گردد
بهتر است نتیجهی آن ارسال شده و از تغییر مقدار فعلی ممانعت به عمل آورید. success: function(response, newValue) { if(!response.success) return response.msg; } |
toggle | اگر قصد دارید که باز و بسته کردن ویرایشگر را بر عهدهی مثلا یک دکمهی روی صفحه بگذارید، این خصوصیت به شما کمک میکند:$('#edit-button').click(function(e) { e.stopPropagation(); $('#favsite').editable('toggle'); }); |
type | نوع
ویرایشی را که قرار است انجام گیرد، مشخص میکند. text برای متن، date برای
تاریخ، textarea جهت متون طولانیتر نسبت به text و بسیاری از موارد دیگر |
unsavedclass | این
کلاس موقعی اعمال میگردد که اطلاعاتی را ویرایش کردهاید، ولی اطلاعاتی
به سمت سرور ارسال نشده است. مثلا pk مقداردهی نشده یا send=never قرار
داید و یا اینکه به صورت محلی ذخیره میکنید و میخواهید در آخر همهی اطلاعات را
ارسال کنید. این خاصیت به طور پیش فرض با کلاس editable-unsaved مقداردهی شده که میتوانید با نال کردن، از شرش خلاص شوید. |
url | این
خاصیت با آدرس سمت سرور پر میشود. ولی میتوان به آن یک تابع هم پاس کرد که
این تابع جایگزین درخواست ایجکسی خودش خواهد شد و برای بازگشت دادن نتیجهی این درخواست به سمت تابعهای callback خودش میتوانید یک deferred object را برگشت دهید: url: function(params) { var d = new $.Deferred; if(params.value === 'abc') { //returning error via deferred object return d.reject('error message'); } else { //async saving data in js model someModel.asyncSaveMethod({ ..., success: function(){ d.resolve(); } }); return d.promise(); } } |
validate | مقدار
پیش فرض آن نال است و میتوان به آن یک تابع را جهت اعتبارسنجی سمت کلاینت پاس
داد. به عنوان آرگومان، مقدار جدیدی را ارسال کرده و در آن به اعتبارسنجی
میپردازید. در صورتی که مقدار، نامعتبر باشد، میتوانید یک پیام خطا از نوع
رشتهای را برگردانید. در صورتی که از نسخهی 1.5.1 به بعد استفاده میکنید، دریافت یک object با مقادیر زیر نیز ممکن شده است: newValue: مقدار جدید و جایگزین مقدار غیر معتبر. msg : پیام خطا. به کدهای زیر در سه حالت نگاه کنید: validate: function (value) { if ($.trim(value) == '') { //در تمامی نسخههای یک پیام متنی باز میگردد return 'This field is required'; //1.5.1 //یک مقدار جدید برگشت میدهد که بلافاصله آن را // تایید میکند و متن عنصر به روز میشود return { newValue: 'validated' }; //متن جدید ار ارسال کرده و پیام هشدار را نشان میدهد //ولی تایید نمیکند و منتظر تایید کاربر است return { newValue: 'validated', |
value | مقدار پیش فرضی که در ویرایشگر نشان میدهد و اگر مقداردهی نشود، از متن عنصر استفاده میکند. |
autotext | سه مقدار دارد auto (پیش فرض)،always و never. موقعیکه عنصر شما متنی نداشته باشد و روی auto تنظیم شده باشد، مقدار value را به عنوان متن عنصر نمایش میدهد. always کاری ندارد که عنصر شما متن دارد یا خالی است؛ مقدار value به آن انتساب داده خواهد شد. never هیچگاه. |
در قسمت بعدی که قسمت پایانی است مطالب را ادامه میدهیم.
سازماندهی برنامههای Angular توسط ماژولها
ویژگی جدیدی به Angular 6 به نام tree-shakable providers اضافه شدهاست که نمونهای از کاربرد آن به صورت پیشفرض در حین «ایجاد پروژهی «کتابخانه» توسط Angular CLI 6.0» ارائه میشود. به این معنا که با استفادهی از آن دیگر نیازی نیست تا سرویسهای سراسری برنامه را در قسمت providers مربوط به CoreModule ثبت کرد. همینقدر که یک سرویس سراسری را به صورت ذیل تعریف کنید:
import { Injectable } from '@angular/core'; @Injectable({ providedIn: 'root' }) export class MyCoreService { }
در این حالت تزریق وابستگیهایی که در مطلب «تزریق وابستگیها فراتر از کلاسها در برنامههای Angular» نیز بحث شدند، پشتیبانی میشود:
@Injectable({ providedIn: 'root', useClass: LazyFlightCancellingService, deps: [NgModuleFactoryLoader, Injector] }) export class FlightCancellingService { }
به عنوان مثال کدهای مخزن کد «اعتبارسنجی کاربران در برنامههای Angular» جهت استفادهی از این قابلیت به روز شد.
مخزن هایی با عنوان Awesome xyz را ممکن است در گیت هاب دیده باشید که برای زبانها و فریمورکهای مختلف ایجاد میکنند برای دات نت نیز چنین مخزنی موجود است اما این بار در سایت لینک شدهی خبر امکان جستجو کردن و .. فراهم شده است .
توضیحات بیشتر در اینجا