بازخوردهای دوره
مثال - نمایش درصد پیشرفت عملیات توسط SignalR
جهت اطلاع؛ همیشه آخرین نسخه 1.x مخصوص دات نت 4 را در صفحه ذیل بررسی کنید:
http://www.nuget.org/packages/Microsoft.AspNet.SignalR
برای مثال در این تاریخ Microsoft ASP.NET SignalR 1.1.4 نسخه آخر 1.x است و از لحاظ امنیتی نیاز است این به روز رسانی صورت گیرد.  
نظرات مطالب
EF Code First #4
- بله. این شماره نگارش کتابخانه است، نه خود دات نت. برای اینکه بتوانند به روز رسانی‌ها را سریعتر کنند، آن‌را از پروسه به روز رسانی‌های کل دات نت خارج کرده‌اند.
- هاست‌ها فعلا از دات نت 4.5 پشتیبانی نمی‌کنند. چون نگارش بعدی دات نت دراین تاریخ در مرحله بتا است.
نظرات مطالب
بررسی تغییرات ASP.NET MVC 5 beta1
با سلام
با توجه به تغییرات سیستم امنیتی mvc  در نگارش 4 که از وب ماتریکس استفاده می‌کرد و در دات نت که بحث owin و غیره مطرح هست، یه مشکلی که وجود داره ، ساخت یه سری کلاس زیربنایی هست که اصطلاحا به فریم ورک تعبیر میشه. اگر بخوایم مثلا برای قسمت زیربنایی نام کاربری رو داشته باشیم، چه روشی رو پیشنهاد می‌کنید؟
مثلا در mvc 4 من از وب ماتریکس WebMatrix.WebData.WebSecurity.CurrentUserName  استفاده میکردم، ولی الان با mvc 5 نال میشه و مقدار نداره.
نظرات مطالب
شروع به کار با بوت استرپ 4
یک نکته‌ی تکمیلی: بررسی نگارش‌های ثالث راست به چپ بوت استرپ 4


1) MahdiMajidzadeh/bootstrap-v4-rtl
متاسفانه اصلا برای یک کار رسمی مناسب نیست و منوهای آن به هم ریخته‌است. list-group آن در حالت flush، کل عرض یک card را پر نمی‌کند و جداول آن نیز به همین صورت است. کامپوننت bread-crumb آن محل قرارگیری /‌های نامناسبی دارد. همچنین با آخرین نگارش بوت استرپ 4.1.3 سازگار نیست و از آن کمی عقب است و برای کار با آن، باید دقیقا همین بسته‌ی ثالث را دریافت و اضافه کنید و مستقل از خود بوت استرپ اصلی نیست. اما به همراه یک بسته‌ی npm مخصوص به خود است که یک مزیت به شمار می‌رود. مجوز آن، در مخزن کد Github آن ذکر نشده، اما در صفحه‌ی npm آن MIT ذکر شده‌است.
یک نمونه خروجی آن:


2) DediData/Bootstrap-RTL
به نظر یک پروژه‌ی خاتمه یافته‌است. با نگارش بوت استرپ 4.1.3 سازگار نیست و برای نگارش بتای آن تهیه شده‌است.


3) GhalamborM/bootstrap4-rtl
این پروژه، روش بهتری را نسبت به بسته‌های راست به چپ موجود، انتخاب کرده‌است. در اینجا شما بوت استرپ اصلی را با آخرین نگارش آن به صورت مستقل دریافت، نصب و تنظیم می‌کنید. سپس ذیل آن کلاس‌های راست به چپ این بسته‌ی ثالث را اضافه می‌کنید.
مجوز GPL، برای اینکار انتخاب شده‌است. متاسفانه یک چنین مجوزی در تضاد با مجوز MIT بوت استرپ اصلی است. مجوز GPL یعنی کار مشتق شده‌ی از آن نیز باید سورس باز شود و قابل استفاده‌ی در پروژه‌های تجاری غیر سورس باز نیست.
همچنین متاسفانه به صورت یک بسته‌ی npm نیز ارائه نشده‌است و باید آخرین نگارش آن‌را از GitHub به صورت مستقیم دریافت کنید.

با تمام این اوصاف، مشکلات ذکر شده‌ی مورد اولی که بررسی شد، در این نگارش وجود ندارند و بهترین خروجی را دریافت خواهید کرد:

 



4) PerseusTheGreat/bootstrap-4-rtl
روش راست به چپ سازی این نگارش نیز مانند حالت اولی است که بررسی شد و باید بسته‌ی مستقل آن‌را دریافت و استفاده کنید و به عنوان یک مکمل مطرح نیست. همچنین به همراه بسته‌ی npm نیز ارائه نشده‌است و تا این تاریخ، باید آخرین به روز رسانی‌های آن‌را از همان آدرس GitHub آن مستقیما دریافت کنید. البته مزیت آن، به روز رسانی هفتگی آن است. همچنین مجوز MIT این بسته را نیز تغییر نداده‌است.
خروجی آن با خروجی بسته‌ی سومی که معرفی شد، تقریبا یکی و مناسب است:



در کل اگر از مجوز GPL مورد سوم صرف نظر کنیم، به علت استقلال فایل CSS راست به چپ کننده‌ی آن از بسته‌ی اصلی بوت استرپ، انتخاب مناسب‌تری به نظر می‌رسد و خروجی قابل قبولی را نیز به همراه دارد. فقط ایکاش بسته‌ی npm ای نیز به پروژه‌ی آن اضافه شود.
به روز رسانی: تغییر مجوز به MIT و همچنین افزوده شدن بسته‌ی npm به مورد سوم صورت گرفته‌است:
npm install @ghalamborm/bootstrap4-rtl


پ.ن.
این روزها ارائه‌ی یک کتابخانه‌ی جاوا اسکریپتی و یا CSS ای بدون بسته‌ی npm متناظر با آن، ناقص به شمار می‌رود.
نظرات مطالب
نحوه ارتقاء برنامه‌های موجود MVC3 به MVC4
مشکلی مشاهده نشد. با دات نت‌های 4.5 و 4.5.1 در یک برنامه MVC 5.x تست شد و کار می‌کند.
اگر v خالی است، ممکن است اسکریپت‌های مورد استفاده مشکل دارند. آدرس نهایی تولید شده را مستقلا در مرورگر باز کرده و خروجی آن‌را بررسی کنید. اگر مشکلی باشد، در ابتدای خروجی، خطاها را ذکر می‌کند.
اشتراک‌ها
دریافت به روز رسانی‌های امنیتی Windows XP تا سال 2019
تعدادی از شرکت‌ها و دولت‌ها، بابت دریافت به روز رسانی‌های امنیتی XP به مایکروسافت پول می‌دهند. با فعال سازی کلیدی در رجیستری، این به روز رسانی‌ها را می‌توانید دریافت کنید.
دریافت به روز رسانی‌های امنیتی Windows XP تا سال 2019
نظرات مطالب
افزودن هدرهای Content Security Policy به برنامه‌های ASP.NET
یک نکته‌ی تکمیلی: روش ساده‌تر تنظیم هدرهای امنیتی در فایل web.config که سازگار با تمام نگارش‌های ASP.NET است
<system.webServer>
  <httpProtocol>
    <customHeaders>
      <!-- SECURITY HEADERS - https://securityheaders.io/? -->
      <!-- Protects against Clickjacking attacks. ref.: http://stackoverflow.com/a/22105445/1233379 -->
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <!-- Protects against Clickjacking attacks. ref.: https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet -->
      <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains"/>
      <!-- Protects against XSS injections. ref.: https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/ -->
      <add name="X-XSS-Protection" value="1; mode=block" />
      <!-- Protects against MIME-type confusion attack. ref.: https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/ -->
      <add name="X-Content-Type-Options" value="nosniff" />
      <!-- CSP modern XSS directive-based defence, used since 2014. ref.: http://content-security-policy.com/ -->
      <add name="Content-Security-Policy" value="default-src 'self'; font-src *;img-src * data:; script-src *; style-src *;" />
      <!-- Prevents from leaking referrer data over insecure connections. ref.: https://scotthelme.co.uk/a-new-security-header-referrer-policy/ -->
      <add name="Referrer-Policy" value="strict-origin" />
    </customHeaders>
  </httpProtocol>
</system.webServer>
نظرات مطالب
کار با کوکی‌ها در ASP.NET Core
یک نکته‌ی تکمیلی: ارتقاء به نگارش 3.1 و تغییر تنظیمات کوکی‌ها


مرورگر کروم، از نگارش 80 آن به بعد به همراه یک تغییر غیرسازگار با نگارش‌های قبلی آن است: از این پس تمام کوکی‌های آن در صورتیکه تنظیمات SameSite را نداشته باشند، به صورت SameSite=Lax تفسیر می‌شوند؛ که تغییر امنیتی فوق العاده‌ای است و سبب خواهد شد تا بسیاری از حملات مانند CSRF به طور کامل غیرعملی شوند. اما ... این مورد سبب از کار افتادن برنامه‌هایی خواهد شد که از سرویس‌هایی مانند IdentityServer استفاده می‌کنند. در یک چنین حالتی نیاز خواهید داشت برای رفع این مشکل، SameSite=None را تنظیم کنید.

اما SameSite چیست؟ تنظیم و خاصیت SameSite از سال 2016 به کوکی‌ها اضافه شد تا بتوان توسط آن در برابر حملات CSRF مقاومت کرد؛ مقادیر اولیه‌ی آن نیز Lax و Strict بودند. Lax به این معنا است که کوکی‌ها در حین مرور یک سایت، باید به صورت خودکار به سمت سرور همان سایت ارسال شوند؛ اما در حالت مرور سایت و هدایت از طریق سایت‌های دیگر به سایت ما، فقط درخواست‌های GET رسیده می‌توانند کوکی‌ها را نیز ارسال کنند. حالت Strict آن فقط کوکی‌های تنظیم شده‌ی درون یک سایت را معتبر شمرده و ارسال می‌کند. عدم تنظیم SameSite نیز مشکل خاصی را ایجاد نمی‌کرد. برای مثال اعمال اعتبارسنجی مبتنی بر OpenIdConnect مانند login/logout، نیاز دارند در طی یک درخواست POST، اطلاعاتی را به سایت خارجی درخواست کننده ارسال کنند. برای اینکه این عملیات به درستی صورت گیرد، می‌بایستی تنظیمات SameSite انجام نمی‌شد تا جابجایی کوکی‌ها بین دو دومین مختلف در حالت POST، بدون مشکل صورت می‌گرفت.
با تغییر جدید گوگل، حالت پیش‌فرض SameSite که اجباری نبود، به صورت اجباری به Lax تنظیم شده‌است؛ اما برای حالاتی مانند OpenIdConnect، مقدار None را نیز اضافه کرده‌است. به همین جهت این نوع برنامه‌ها اگر از تنظیم SameSite=None استفاده نکنند، دیگر نمی‌توانند کوکی‌های درخواست‌های POST را بین دومین‌های مختلف جابجا کنند.

مشکل مهم! مقدار None را فقط مرورگر کروم متوجه می‌شود و جزو استاندارد SameSite نیست! در این استاندارد اگر مقدار SameSite تنظیم شود و مرورگر نتواند آن‌را تشخیص دهد (مانند iOS 12)، مقدار Strict را به عنوان مقدار دریافتی تنظیم می‌کند! به همین جهت برنامه‌ی شما باید بر اساس نوع مرورگر تصمیم‌گیری کند که آیا باید SameSite را به خروجی اضافه کند یا خیر.

وضعیت دات نت در این مورد: با به روز رسانی‌های جدید دات نت 4.7.2 و همچنین NET Core 2.1.، مقدار جدید None توسط برنامه (در CookieOptions) قابل تنظیم خواهد بود که سبب تولید SameSite=None می‌شود. به علاوه در NET Core 3.1.،  مقدار SameSite.Unspecified را نیز می‌توان تنظیم کرد که سبب خواهد شد تا خاصیت SameSite اصلا تنظیم نشود (اصلا به درخواست اضافه نشود؛ تا مرورگرهایی که نمی‌توانند مقدار None را تفسیر کنند، به اشتباه آن‌را به Strict تنظیم نکنند).

به صورت خلاصه: اگر برنامه‌ی شما از OpenIdConnect و یا IdentityServer استفاده نمی‌کند، هیچ تنظیمی را تغییر ندهید! تنظیم پیش‌فرض SameSite=Lax گوگل سبب می‌شود تا عملا حملات CSRF دیگر بر روی سایت شما قابل اجرا نباشد. اما اگر از IdentityServer استفاده می‌کنید، این تنظیم پیش‌فرض، سبب از کار افتادن امکان ارسال کوکی‌های حالت POST، به سایت‌های خارجی می‌شود و برنامه و سیستم شما از کار خواهد افتاد.