اشتراک‌ها
معرفی Dotnet-Monitor

When running a dotnet application differences in diverse local and production environments can make collecting diagnostics artifacts (e.g., logs, traces, process dumps) challenging. dotnet-monitor aims to simplify the process by exposing a consistent REST API regardless of where your application is run. 

معرفی Dotnet-Monitor
اشتراک‌ها
استفاده از بانک اطلاعاتی in-memory جهت نوشتن آزمون واحد
ASP.NET Core applications can be tested with different testing frameworks and Entity Framework Core makes testing specially easy by removing different technical problems from our way by using in-memory data provider. This blog posts shows how to unit test controllers that use data from Entity Framework Core. 
استفاده از بانک اطلاعاتی in-memory جهت نوشتن آزمون واحد
مطالب
ایجاد ServiceLocator با استفاده از Ninject
در پست قبلی روش استفاده از ServiceLocator رو با استفاده از Microsoft Unity بررسی کردیم. در این پست قصد دارم همون مثال رو با استفاده از Ninject پیاده سازی کنم. Ninject ابزاری برای پیاده سازی Dependency Injection در پروژه‌های دات نت است که کار کردن با اون واقعا راحته. برای شروع کلاس‌های Book و BookRepository  و BookService و اینترفیس IBookRepository از این پست دریافت کنید.
حالا با استفاده از NuGet باید ServiceLocator رو برای Ninject دریافت کنید. برای این کار در Package Manager Console دستور زیر رو وارد کنید.
PM> Install-Package CommonServiceLocator.NinjectAdapter
بعد از دانلود و نصب Referenceهای زیر به پروژه اضافه می‌شوند.
  • Ninject
  • NinjectAdapter
  • Microsoft.Practices.ServiceLocation 

اگر دقت کنید برای ایجاد ServiceLocator دارم از ServiceLocator؛Enterprise Library استفاده می‌کنم. ولی برای این کار به جای استفاده UnityServiceLocator باید از NinjectServiceLocator استفاده کنم. 

ابتدا

برای پیاده سازی مثال قبل در کلاس Program  کد‌های زیر رو وارد کنید.

using System;
using Ninject;
using NinjectAdapter;
using Microsoft.Practices.ServiceLocation;

namespace ServiceLocatorPattern
{
    class Program
    {
        static void Main( string[] args )
        {
            IKernel kernel = new StandardKernel();

            kernel.Bind<IBookRepository>().To<BookRepository>();

            ServiceLocator.SetLocatorProvider( () => new NinjectServiceLocator( kernel ) );

            BookService service = new BookService();

            service.PrintAllBooks();

            Console.ReadLine();
        }
    }
}
همان طور که می‌بینید روال انجام کار دقیقا مثل قبل هست فقط Syntax کمی متفاوت شده. برای مثال به جای استفاده از IUnityContainer از IKernel استفاده کردم و به جای دستور RegisterType از دستور Bind استفاده شده. دز نهایت هم ServiceLocator به یک NinjectServiceLocator ای که IKernel  رو دریافت کرده ست شد.
به تصویر زیر دقت کنید.

همان طور که می‌بینید در هر جای پروژه که نیاز به یک Instance از یک کلاس داشته باشید می‌تونید با استفاده از ServiceLocator این کار خیلی راحت انجام بدید.

بعد از اجرای پروژه  خروجی دقیقا مانند مثال قبل خواهد بود.

 
اشتراک‌ها
کتابخانه canvasjs
An easy to use HTML5 JavaScript Charting library built on Canvas element. Charts can render across devices including iPhone, iPad, Android, Windows Phone, Desktops, etc. This allows you to create rich dashboards that can work across devices without compromising on maintainability or functionality of your web application. Graphs include several good looking themes and are 10x faster than conventional Flash / SVG based Libraries – resulting in lightweight, beautiful and responsive dashboards.
کتابخانه canvasjs
اشتراک‌ها
چک لیست امنیتی برنامه های مبتنی بر Blazor
  • Validate arguments from events.
  • Validate inputs and results from JS interop calls.
  • Avoid using (or validate beforehand) user input for .NET to JS interop calls.
  • Prevent the client from allocating an unbound amount of memory.
    • Data within the component.
    • DotNetObject references returned to the client.
  • Guard against multiple dispatches.
  • Cancel long-running operations when the component is disposed.
  • Avoid events that produce large amounts of data.
  • Avoid using user input as part of calls to NavigationManager.NavigateTo and validate user input for URLs against a set of allowed origins first if unavoidable.
  • Don't make authorization decisions based on the state of the UI but only from component state.
  • Consider using Content Security Policy (CSP) to protect against XSS attacks.
  • Consider using CSP and X-Frame-Options to protect against click-jacking.
  • Ensure CORS settings are appropriate when enabling CORS or explicitly disable CORS for Blazor apps.
  • Test to ensure that the server-side limits for the Blazor app provide an acceptable user experience without unacceptable levels of risk. 
چک لیست امنیتی برنامه های مبتنی بر Blazor
اشتراک‌ها
معرفی افزونه Web Extension Pack



In this episode, Robert is joined by Mads Kristensen, who shows us the Web Extension Pack. This extension installs a number of extensions that help you become a more productive Web developer. The extensions contained in the Web Extension Pack have been proven to be stable over time and useful for all Web developers. 

معرفی افزونه Web Extension Pack
اشتراک‌ها
آینده‌ی Windows Phone

The latest round of layoffs in Microsoft’s Windows Phone business— 1,850 jobs will be cut, according to an announcement earlier this week—seems to signal the final death gasp of a segment of the company’s business that has long struggled. Windows phones currently make up less than one percent of smartphones sold worldwide. 

آینده‌ی Windows Phone
نظرات مطالب
افزودن و اعتبارسنجی خودکار Anti-Forgery Tokens در برنامه‌های Angular مبتنی بر ASP.NET Core
پاسخ دادن به این سؤال بدون مطالعه‌ی سورس https://github.com/aspnet/Antiforgery غیرممکن است. علت اینکه روش توضیح داده شده‌ی در این مطلب، برای حالت برنامه‌های دارای اعتبارسنجی کار نمی‌کند و خطای «The provided antiforgery token was meant for a different claims-based user than the current user» را دریافت می‌کنید، این صورت است:
 میان‌افزار طراحی شده‌ی در این مطلب، پیش از لاگین و با اولین درخواست تک صفحه‌ی برنامه، کوکی‌های antiforgery را دریافت می‌کند. اما ... سیستم antiforgery طوری طراحی شده‌است که پیش از تولید کوکی، مشخصات دقیق this.HttpContext.User را دریافت و هش می‌کند (لیست Claims آن‌را به صورت رشته در می‌آورد و هش SHA256 آن را محاسبه می‌کند). از این هش هم جهت تولید محتوای کوکی نهایی خود استفاده می‌کند. بنابراین در بار اولی که صفحه درخواست شده‌است، یک کوکی antiforgery مخصوص کاربر null و اعتبارسنجی نشده، تولید خواهد شد. بعد از آن پس از لاگین، اگر میان‌افزار یاد شده مجددا نیز فراخوانی شود، هیچ اتفاق خاصی رخ نخواهد داد. از این جهت که در طراحی متد GetAndStoreTokens آن، به ازای یک صفحه، فقط یکبار این کوکی تولید می‌شود و اگر هزار بار دیگر هم این متد را جهت برنامه‌ی تک صفحه‌ای خود فراخوانی کنیم، به این معنا نخواهد بود که مشخصات this.HttpContext.User را به کوکی جدیدی اضافه می‌کند؛ چون اصلا کوکی جدیدی را تولید نمی‌کند!

بنابراین راه حل نهایی به این صورت است:
الف) میان افزار AngularAntiforgeryTokenMiddleware فوق را حذف کنید. این میان‌افزار عملا کاربردی برای برنامه‌های SPA دارای اعتبارسنجی ندارد.
ب) امضای متد Login را به این صورت تغییر دهید که شامل IgnoreAntiforgeryToken باشد:
[AllowAnonymous]
[IgnoreAntiforgeryToken]
[HttpPost("[action]")]
public async Task<IActionResult> Login([FromBody] User loginUser)
از این جهت که نمی‌توانیم پیش از لاگین، درخواست تولید کوکی antiforgery را برای کاربر null صادر کنیم؛ چون این کوکی تا پایان عمر مرورگر تغییری نخواهد کرد.
ج) در متد لاگین، پس از تولید توکن‌ها، اکنون کار تولید کوکی را به صورت زیر انجام می‌دهیم:
private void regenerateAntiForgeryCookie(IEnumerable<Claim> claims)
{
    this.HttpContext.User = new ClaimsPrincipal(new ClaimsIdentity(claims, JwtBearerDefaults.AuthenticationScheme));
    var tokens = _antiforgery.GetAndStoreTokens(this.HttpContext);
    this.HttpContext.Response.Cookies.Append(
                  key: "XSRF-TOKEN",
                  value: tokens.RequestToken,
                  options: new CookieOptions
                  {
                      HttpOnly = false // Now JavaScript is able to read the cookie
                  });
}
در این‌جا لیست claims ایی را که در حین تولید توکن‌ها ایجاد کردیم، تبدیل به یک ClaimsPrincipal می‌کنیم تا بتوانیم this.HttpContext.User را مقدار دهی کنیم (دقیقا با مشخصات اصلی کاربر لاگین شده) و سپس متد GetAndStoreTokens را فراخوانی می‌کنیم تا این User غیرنال را خوانده و کوکی صحیحی را تولید کند. به این صورت است که دیگر پیام خطای «این antiforgery توکن، متعلق به کاربر دیگری است» را دریافت نخواهیم کرد. این «کاربر دیگر» منظورش همان کاربر null ابتدای کار است که پیش از لاگین تنظیم می‌شد و با کاربر جدیدی که دارای claims است یکی نبود.

نکته‌ی مهم! جائیکه Claim‌های برنامه را تولید می‌کنید، باید حتما Issuer را هم ذکر کنید:
 new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString(),
                  ClaimValueTypes.String, _configuration.Value.Issuer),
از این جهت که هش SHA256 ایی که توضیح داده شده، بر اساس این Issuer، مقدار و نوع Claim محاسبه می‌شود. اگر Issuer را ذکر نکنید، به local authority تنظیم می‌شود که با Issuer نهایی توکن تولید شده یکی نیست. به همین جهت حتی اگر this.HttpContext.User را هم مقدار دهی کنید، کار نمی‌کند؛ چون هش claim‌های تولیدی، یکی نخواهند بود و باز هم پیام «این antiforgery توکن متعلق به کاربر دیگری است» را دریافت خواهید کرد.


خلاصه این تغییرات به پروژه‌ی ASPNETCore2JwtAuthentication اعمال شده‌اند.