نظرات مطالب
امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x - قسمت چهاردهم- آماده شدن برای انتشار برنامه
میخوام یه پروژه MVC رو به تمپلیت Skoruba به عنوان یک کلاینت جدید اضافه کنم. تو تنظیمات Sturtup پروژه Mvc اینگونه عمل کردم:
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllersWithViews();
            IdentityModelEventSource.ShowPII = true;
            services.AddAuthentication(options =>
                {
                    options.DefaultScheme = "Cookies";
                    options.DefaultChallengeScheme = "oidc";
       options.DefaultSignOutScheme = "oidc";
                })
                .AddCookie("Cookies", options =>
                {
                    options.AccessDeniedPath = "/Authorization/AccessDenied";
                    // set session lifetime
                    options.ExpireTimeSpan = TimeSpan.FromHours(8);
                    // sliding or absolute
                    options.SlidingExpiration = false;
                    // host prefixed cookie name
                    options.Cookie.Name = "MVC";
                    // strict SameSite handling
                    options.Cookie.SameSite = SameSiteMode.Strict;
                })
                .AddOpenIdConnect("oidc", options =>
                {
                    options.SignInScheme = "Cookies";
                    options.Authority = Configuration["IDPBaseAddress"]; 
                    options.ClientId = Configuration["ClientId"];
                    options.ClientSecret = Configuration["ClientSecret"];                      
                    options.ResponseType = "code id_token";
                    options.ResponseMode = "query";

                    options.RequireHttpsMetadata = false;
                    options.CallbackPath = new PathString("/Home/");
                    options.SignedOutCallbackPath = new PathString("/Home/");

                    options.MapInboundClaims = true;

                    options.Scope.Clear();
                    options.Scope.Add("openid");
                    options.Scope.Add("profile");
                    options.Scope.Add("roles");
                    options.Scope.Add("PS.WebApi.Read");
                    options.Scope.Add("offline_access");
                    
                    options.SaveTokens = true;
                    options.GetClaimsFromUserInfoEndpoint = true;
                    //options.UsePkce = true;
                    //options.ClaimActions.MapJsonKey(claimType: "role", jsonKey: "role"); // for having 2 or more roles
                    
                    options.TokenValidationParameters = new TokenValidationParameters
                    {
                        NameClaimType = JwtClaimTypes.GivenName,
                        RoleClaimType = JwtClaimTypes.Role
                    };
                });
            //ServicePointManager.Expect100Continue = true;
            //ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
            //                                       | SecurityProtocolType.Tls11
            //                                       | SecurityProtocolType.Tls12
            //                                       | SecurityProtocolType.Ssl3;
        }

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
                app.UseHsts();
            }
            app.UseHttpsRedirection();
            app.UseStaticFiles();

            app.UseRouting();

            app.UseAuthentication();
            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllerRoute(
                    name: "areas",
                    pattern: "{area:exists}/{controller=Home}/{action=Index}/{id?}"
                );
                //.RequireAuthorization();

                endpoints.MapControllerRoute(
                    name: "default",
                    pattern: "{controller=Home}/{action=Index}/{id?}"
                );
                //.RequireAuthorization();
            });

            //[HttpPost]
            //public IActionResult Logout()
            //{
            //    return SignOut("Cookies", "oidc");
            //}
        }

پروژه‌های بنده به ترتیب Endpoint هاشون اینگونه هست:
Skoruba.IdentityServer4.Admin  = https://localhost:44303
Skoruba.IdentityServer4.STS.Identity   = https://localhost:44310
Skoruba.IdentityServer4.Admin.Api    = https://localhost:44356 
Mvc_Client_Project = https://localhost:44332
تنظیمات کانفیک پروژه MVC: (appsettings.json)
  "WebApiBaseAddress": "https://localhost:44356",
  "IDPBaseAddress": "https://localhost:44310",
  "ClientId": "Mvc_ClientId",
  "ClientSecret": "WebMvc"
محتویات فایل Identityserverdata.json:

{
    "IdentityServerData": {
        "IdentityResources": [
            {
                "Name": "roles",
                "Enabled": true,
                "DisplayName": "Roles",
                "UserClaims": [
                    "role"
                ]
            },
            {
                "Name": "openid",
                "Enabled": true,
                "Required": true,
                "DisplayName": "Your user identifier",
                "UserClaims": [
                    "sub"
                ]
            },
            {
                "Name": "profile",
                "Enabled": true,
                "DisplayName": "User profile",
                "Description": "Your user profile information (first name, last name, etc.)",
                "Emphasize": true,
                "UserClaims": [
                    "name",
                    "family_name",
                    "given_name",
                    "middle_name",
                    "nickname",
                    "preferred_username",
                    "profile",
                    "picture",
                    "website",
                    "gender",
                    "birthdate",
                    "zoneinfo",
                    "locale",
                    "updated_at"
                ]
            },
            {
                "Name": "email",
                "Enabled": true,
                "DisplayName": "Your email address",
                "Emphasize": true,
                "UserClaims": [
                    "email",
                    "email_verified"
                ]
            },
            {
                "Name": "address",
                "Enabled": true,
                "DisplayName": "Your address",
                "Emphasize": true,
                "UserClaims": [
                    "address"
                ]
            }
        ],
        "ApiScopes": [
          {
            "Name": "Idp_Admin_ClientId_api",
            "DisplayName": "Idp_Admin_ClientId_api",
            "Required": true,
            "UserClaims": [
              "role",
              "name"
            ]
          },
          {
            "Name": "WebApi.Read",
            "DisplayName": "WebApi Read",
            "Required": true,
            "UserClaims": [
              "role",
              "WebApi.Read"
            ]
          },
          {
            "Name": "WebApi.Write",
            "DisplayName": "WebApi Write",
            "Required": true,
            "UserClaims": [
              "role",
              "WebApi.Write"
            ]
          }
        ],
        "ApiResources": [
          {
            "Name": "Idp_Admin_ClientId_api",
            "Scopes": [
              "Idp_Admin_ClientId_api"
            ]
          },
          {
            "Name": "WebApi",
            "Scopes": [
              "WebApi.Read",
              "WebApi.Write"
            ]
          }
        ],
      "Clients": [
        {
          "ClientId": "Idp_Admin_ClientId",
          "ClientName": "Idp_Admin_ClientId",
          "ClientUri": "https://localhost:44303",
          "AllowedGrantTypes": [
            "authorization_code"
          ],
          "RequirePkce": true,
          "ClientSecrets": [
            {
              "Value": "Idp_Admin_ClientSecret"
            }
          ],
          "RedirectUris": [
            "https://localhost:44303/signin-oidc"
          ],
          "FrontChannelLogoutUri": "https://localhost:44303/signout-oidc",
          "PostLogoutRedirectUris": [
            "https://localhost:44303/signout-callback-oidc"
          ],
          "AllowedCorsOrigins": [
            "https://localhost:44303"
          ],
          "AllowedScopes": [
            "openid",
            "email",
            "profile",
            "roles"
          ]
        },
        {
          "ClientId": "Idp_Admin_ClientId_api_swaggerui",
          "ClientName": "Idp_Admin_ClientId_api_swaggerui",
          "AllowedGrantTypes": [
            "authorization_code"
          ],
          "RequireClientSecret": false,
          "RequirePkce": true,
          "RedirectUris": [
            "https://localhost:44302/swagger/oauth2-redirect.html"
          ],
          "AllowedScopes": [
            "Idp_Admin_ClientId_api"
          ],
          "AllowedCorsOrigins": [
            "https://localhost:44302"
          ]
        },
        //WebApi
        {
          "ClientId": "WebApi_ClientId",
          "ClientName": "WebApi_ClientId",
          "ClientUri": "https://localhost:44365",
          "AllowedGrantTypes": [
            "authorization_code"
          ],
          "RequirePkce": true,
          "ClientSecrets": [
            {
              "Value": "WebApi"
            }
          ],
          "RedirectUris": [
            "https://localhost:44303/signin-oidc"
          ],
          "FrontChannelLogoutUri": "https://localhost:44303/signout-oidc",
          "PostLogoutRedirectUris": [
            "https://localhost:44303/signout-callback-oidc"
          ],
          "AllowedCorsOrigins": [
            "https://localhost:44303",
            "https://localhost:44310"
          ],
          "AllowedScopes": [
            "openid",
            "email",
            "profile",
            "roles"
          ]
        },
        //Mvc
        {
          "ClientId": "Mvc_ClientId",
          "ClientName": "Mvc_ClientId",
          "ClientUri": "https://localhost:44332",
          "AllowedGrantTypes": [
            "hybrid"
          ],
          //"RequirePkce": true,
          "AllowPlainTextPkce": false,
          "ClientSecrets": [
            {
              "Value": "WebMvc"
            }
          ],

          "RedirectUris": [
            "https://localhost:44332/signin-oidc"
          ],
          "FrontChannelLogoutUri": "https://localhost:44332/signout-oidc",
          "PostLogoutRedirectUris": [
            "https://localhost:44332/signout-callback-oidc"
          ],
          "AllowedCorsOrigins": [
            "https://localhost:44332",
            "https://localhost:44310"
          ],
          "AllowedScopes": [
            "openid",
            "email",
            "profile",
            "roles",
            "address",
            "PS.webApi"
          ],
          "AllowAccessTokensViaBrowser": true,
          "RequireConsent": false,
          "AllowOfflineAccess": true
          //"UpdateAccessTokenClaimsOnRefresh": true
        }
      ]
    }
}

کنترلر Home در پروژه MVC:
    public class HomeController : Controller
    {
        private readonly ILogger<HomeController> _logger;

        public HomeController(ILogger<HomeController> logger)
        {
            _logger = logger;
        }

        public IActionResult Default()
        {
            return View();
        }
        public IActionResult Index()
        {
            return View();
        }

        [Authorize]
        public IActionResult Privacy()
        {
            return View();
        }

        [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
        public IActionResult Error()
        {
            return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
        }
    }

اما در نهایت بعد از اجرا و مراجعه به آدرس https://localhost:44332/home/privacy که مزین به اتریبیوت
[Authorize]  
می‌باشد با خطای زیر مواجه می‌شوم:

لازم به توضیح هست که پروپرتی RequireHttpsMetadata = false می‌باشد.

مطالب
بررسی الگوی Chain of Responsibility در جاوا اسکریپت
الگوی Chain of Responsibility، یک زنجیر، از اشیاء متصل شده‌ی به هم را فراهم می‌کند که یکی از آنها می‌تواند درخواست رسیده را راضی کند؛ به عبارتی دیگر به محض دریافت درخواست، آن را پردازش می‌کند. این الگو اساسا یک جستجوی خطی ( linear search )، برای یک شیء می‌باشد که می‌تواند یک درخواست ویژه را handle کند. 

الگوی chain-of-responsibility، ارتباط با الگوی Chaining دارد که به دفعات در جاوا اسکریپت استفاده شده‌است (jQuery  استفاده‌ی گسترده‌ای از این الگو کرده‌است).
این الگو اجازه میدهد که یک درخواست ارسال شده‌ی توسط کلاینت، توسط یک یا بیش از یک object، دریافت شود. یک مثال عمومی از این الگو،  event bubbling در DOM  می‌باشد. یک رویداد از طریق element‌‌‌های تودرتوی متفاوت انتشار پیدا می‌کند؛ تا زمانیکه یکی از آن‌ها، آن را handle کند.


مثال زیر را در نظر بگیرید:
class HandlerChain 
{ 
   setNextObj(nextObjInChain){}
   processMultiple(req){
     console.log("No multiple for: " + req.getMultiple());
   }
} 
  
class Multiple
{
  constructor(multiple){
    this.multiple = multiple;
  }
  
  getMultiple(){ 
    return this.multiple; 
  } 
  
} 
  

class MultipleofTwoHandler extends HandlerChain
{
  constructor(){
    super()
    this.nextObjInChain = new HandlerChain()
  } 
  
  setNextObj(nextObj){ 
    this.nextObjInChain = nextObj; 
  } 
  
  processMultiple(req) { 
    if ((req.getMultiple() % 2) == 0) { 
      console.log("Multiple of 2: " + req.getMultiple()); 
    }else{ 
      this.nextObjInChain.processMultiple(req); 
    } 
  } 
} 
  
class MultipleofThreeHandler extends HandlerChain 
{ 
  constructor(){
    super()
    this.nextObjInChain = new HandlerChain()
  } 
  
   setNextObj(nextObj){ 
    this.nextObjInChain = nextObj; 
  } 
  
  processMultiple(req) 
  { 
    if ((req.getMultiple() % 3) == 0) { 
      console.log("Multiple of 3: " + req.getMultiple()); 
    }else{ 
          this.nextObjInChain.processMultiple(req); 
        } 
    } 
} 


class MultipleofFiveHandler extends HandlerChain
{ 
  constructor(){
    super()
    this.nextObjInChain = new HandlerChain()
  }
  
  setNextObj(nextObj){ 
    this.nextObjInChain = nextObj; 
  } 
  
  processMultiple(req) { 
    if ((req.getMultiple() % 5) == 0) { 
      console.log("Multiple of 5: " + req.getMultiple()); 
    }else{ 
      this.nextObjInChain.processMultiple(req); 
      } 
    } 
} 

//configuring the chain of handler objects
var c1 = new MultipleofTwoHandler(); 
var c2 = new MultipleofThreeHandler(); 
var c3 = new MultipleofFiveHandler(); 
c1.setNextObj(c2); 
c2.setNextObj(c3); 
  
//the chain handling different cases
c1.processMultiple(new Multiple(95));  // Multiple of 5: 95  
c1.processMultiple(new Multiple(50));  // Multiple of 2: 50 
c1.processMultiple(new Multiple(9));   // Multiple of 3: 9 
c1.processMultiple(new Multiple(4));   // Multiple of 2: 4 
c1.processMultiple(new Multiple(21));  // Multiple of 3: 21 
c1.processMultiple(new Multiple(23));  // No multiple for: 23  
مثال بالا، الگوی chain of responsibility را پیاده سازی می‌کند و بررسی می‌کند که آیا عدد وارد شده، مضربی از 2، 3 یا 5 است و یا نه.
چگونه می‌توانیم این قابلیت را پیاده سازی کنیم؟ ما می‌خواهیم که یک عدد داشته باشیم و سپس به handler‌ها در زنجیره اجازه بدهیم که تصمیم گیری کنند که آیا آنها می‌خواهند عدد وارد شده را پردازش کنند، یا به handler بعدی پاس بدهند.

ما 3 نوع handler در این زنجیره داریم:

  • MultipleofTwoHandler: بررسی می‌کند که آیا عدد وارد شده، مضربی از 2 است یا نه. 
  • MultipleofThreeHandler: بررسی می‌کند که آیا عدد وارد شده، مضربی از 3 است یا نه 
  • MultipleofFiveHandler: بررسی می‌کند که آیا عدد وارد شده، مضربی از 5 است یا نه. 

اولین قدم، ایجاد یک زنجیره از handler‌های بالا می‌باشد. در اینجا یک کلاس را به نام HandlerChain، برای همین منظور داریم و این کلاس شامل دو تابع، به نام‌های setNextObj و processMultiple می‌باشد.
class HandlerChain 
{ 
   setNextObj(nextObjInChain){}
   processMultiple(req){
     console.log("No multiple for: " + req.getMultiple());
   }
}

پیاده سازی پیش فرض processMultiple، زمانی اجرا می‌شود که هیچ مضربی برای یک عدد، وجود نداشته باشد. به عبارت دیگر، عدد مورد نظر، مضربی از 2،3 و 5 نباشد ( از بین مضرب‌های تعین شده). 
تمام handler‌ها در این زنجیره، از این کلاس ارث بری می‌کنند. هر handler می‌تواند دو عملیات را انجام دهد:

  1. تنظیم کردن handler بعدی در زنجیره 
  2. پردازش عدد وارد شده به این منظور که آیا در مضرب مورد نظر قرار دارد یا نه. 

class MultipleofTwoHandler extends HandlerChain
{ 
  constructor(){/*code*/}
  setNextObj(nextObj){/*code*/}  
  processMultiple(req){/*code*/}
}
  
class MultipleofThreeHandler extends HandlerChain
{
  constructor(){/*code*/}
  setNextObj(nextObj){/*code*/}  
  processMultiple(req){/*code*/}
}


class MultipleofFiveHandler extends HandlerChain
{
  constructor(){/*code*/}
  setNextObj(nextObj){/*code*/}  
  processMultiple(req){/*code*/}
}

constructor برای هر handler، همانند زیر تعریف شده‌است:
constructor(){
    super()
    this.nextObjInChain = new HandlerChain()
}

در ابتدا توسط  super ،  مقدار دهی اولیه‌ای برای متد‌های setNextObj و processMultiple از کلاس پدر انجام میشود. همچنین در constructor، متغیر nextObjInChain
مقدار دهی اولیه می‌شود که تعیین کننده‌ی شیء بعدی در زنجیره می‌باشد. 
 
 چگونه شیء جاری، شیء بعد را در زنجیره تعیین می‌کند؟ اجازه بدهید برای این منظور نگاهی به تابع setNextObj داشته باشیم. setNextObj در هر handler، همانند زیر تعیین شده‌است: 
setNextObj(nextObj){ 
    this.nextObjInChain = nextObj; 
}

اکنون می‌توانیم زنجیره‌ای از handler‌ها را همانند زیر ایجاد کنیم: 
var c1 = new MultipleofTwoHandler(); 
var c2 = new MultipleofThreeHandler(); 
var c3 = new MultipleofFiveHandler(); 
c1.setNextObj(c2); 
c2.setNextObj(c3);

در اینجا ما handler‌‌‌های c2, c1  و c3 را به منظور پردازش کردن مضرب‌های 2، 3 و 5 ایجاد کرده‌ایم. آن‌ها به یکدیگر به حالت زیر متصل شده‌اند:
 c2 به عنوان handler بعدی برای c1 و c3 به عنوان handler بعدی برای c2. 


اکنون که زنجیره ایجاد شده‌است، زمان آن است که عدد وارد شده را پردازش کنیم. اجازه بدهید که کار را با ایجاد کردن شیء “multiple”  با استفاده از کلاس Multiple، شروع کنیم.

class Multiple
{
  constructor(multiple){
    this.multiple = multiple
  }
  
  getMultiple(){ 
    return this.multiple; 
  }  
}

یک شیء Multiple، شامل یک خصوصیت به نام multiple و یک متد است به نام getMultiple که به منظور برگشت دادن multiple می‌باشد.
 
MultipleofTwoHandler به صورت زیر تعریف شده‌است:
processMultiple(req) { 
    if ((req.getMultiple() % 2) == 0) { 
      console.log("Multiple of 2: " + req.getMultiple()); 
    }else{ 
      this.nextObjInChain.processMultiple(req); 
    } 
}

در اینجا، یک multiple دریافت شده و چک می‌شود که آیا مضربی از 2 می‌باشد یا نه؛ اگر چنین است، سپس عدد دریافت شده را به عنوان مضربی از 2 نمایش می‌دهد. در صورتیکه مضربی از 2 نباشد، handler آن را به شیء بعدی در زنجیره، پاس میدهد و سپس همین روال دوباره تکرار می‌شود و تا زمانیکه یکی از handler ‌ها، جواب را برگشت دهد، این روال ادامه پیدا می‌کند. 
 
تعریف تابع processMultiple  برای هر 3 handler یکسان میباشد؛ با این تفاوت که MultipleofThreeHandler، برای بررسی مضربی از 3 بودن و MultipleofFiveHandler  برای بررسی مضربی از 5 بودن است.

اجازه بدهید یک مثال بزنیم و ببینیم که چه اتفاقی می‌افتد:
c1.processMultiple(new Multiple(95)) // Multiple of 5: 95  

اولین handler در زنجیره که c1 است، یک multiple (95) را دریافت می‌کند و چک می‌کند که آیا مضربی از 2 است یا نه. جواب خیر است؛ بنابراین multiple به دومین handler  در زنجیره پاس داده میشود؛ یعنی به handler بررسی کننده‌ی مضربی از 3 . در اینجا دوباره بررسی میشود که آیا عدد مورد نظر، مضربی از 3 است یا نه؟ که جواب خیر است. در ادامه multiple به handler سوم در زنجیره که بررسی کننده‌ی مضربی از 5 است، پاس داده میشود. در اینجا، شرط درست است و عدد 95 به عنوان مضربی از 5 چاپ میشود. 


چه زمانی از این الگو استفاده کنیم؟
به منظور مدیریت کردن انواع درخواست‌ها، به روش‌های متفاوت، بدون دانستن ترتیب و نوع درخواست از قبل، از این الگو استفاده می‌کنیم. این الگو به ما اجازه می‌دهد که زنجیره‌ای از چند handler را داشته باشیم. تمامی handler‌ها، یک شانس را جهت پردازش درخواست دارند.  
مطالب
برنامه نویسی موازی بخش دوم (محافظت از مقادیر مشترک)
 در بخش قبلی، مروری کلی بر مفاهیم اصلی برنامه نویسی موازی، از جمله شرایط و نکات استفاده از آن را بررسی کردیم. در انتهای بخش اول عنوان کردیم که در روند برنامه نویسی موازی، اگر دو یا چند Thread به طور مشترک به داده‌ای دسترسی داشته باشند، امکان بروز Race condition وجود خواهد داشت. پس باید کد خود را Thread Safe کنیم. می‌توان برای کنترل رفتارهای عجیب اشیاء در محیط‌های Multi Thread، عنوان Thread Safety را بکار برد.

به طور کلی ۴ روش در #C برای ایجاد Thread Safety وجود دارند:


1- Lock/Monitor
این دو روش یکسان هستند و مانند هم عمل می‌کنند. در واقع در ابتدا روش Monitor وجود داشته و بعد روش lock برای کوتاهی syntax، به صورت بلاکی به #C افزوده شده‌است. این روش تنهای بر روی Thread‌های داخلی App Domain کنترل دارد (اجازه ورود یک Thread) و نمی‌تواند بر روی Thread‌های خارج از این حوزه در محیط‌های Multi Thread محدودیتی اعمال نماید. منظور از Thread‌های داخلی، Thread هایی هستند که داخل Application ما ایجاد شده‌اند.

به تکه کد زیر توجه کنید:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Threading;

 class Program
    {
        static int a = 0;
        static int b = 0;
        static Random random = new Random();
        
        static void Main(string[] args)
        {

            Thread obj = new Thread(Division);
            obj.Start();

            Division();
        }

        static void Division()
        {

            for (int i = 0; i <= 500; i++)
            {

                try
                {
                   
                        //Choosing random numbers between 1 to 5
                        a = random.Next(1, 10);
                        b = random.Next(1, 10);


                        //Dividing
                        double ans = a / b;


                        //Reset Variables
                        a = 0;
                        b = 0;

                        Console.WriteLine("Answer : {0} --> {1}", i, ans);
                    
                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex.ToString());
                }
            }
        }
    }

همانطور که در کد بالا ملاحظه می‌کنید، متد Division به صورت Thread Safe پیاده سازی نشده‌است! اما مشکل کجاست!؟

با برسی این متد و عملکرد آن متوجه می‌شویم که این متد در یک چرخه‌ی تکرار ۵۰۰ مرتبه‌ای، دو عدد تصادفی را در بازه‌ی ۱ تا ۱۰، انتخاب کرده و آن‌ها را بر هم تقسیم و متغیر‌های تصادفی را با مقدار ۰ پر می‌کند. همین عمل Reset Variable در این متد، باعث بروز خطا در محیط Multi Thread خواهد شد. بدین صورت که اگر این متد مانند مثال بالا توسط دو Thread مجزا فراخوانی شود، یکبار توسط New Thread و بلافاصله در Thread اصلی Application، احتمال این وجود خواهد داشت که در Thread دوم، بعد از انتخاب دو مقدار تصادفی و درست قبل از عملیات تقسیم، به طور همزمان Thread اول عملیات Reset Variable را انجام دهد که باعث بروز خطای تقسیم بر ۰ در Thread دوم می‌شود. این همان مشکلی است که گاها یافتن آن از طریق Debug بسیار دشوار خواهد بود.
اما با تغییر کد به شکل زیر
class Program
    {
        static int a = 0;
        static int b = 0;
        static Random random = new Random();
        static readonly object _object = new object();
        static void Main(string[] args)
        {

            Thread obj = new Thread(Division);
            obj.Start();

            Division();
        }

        static void Division()
        {

            for (int i = 0; i <= 500; i++)
            {

                try
                {
                    Monitor.Enter(_object);
                   
                        //Choosing random numbers between 1 to 5
                        a = random.Next(1, 10);
                        b = random.Next(1, 10);


                        //Dividing
                        double ans = a / b;


                        //Reset Variables
                        a = 0;
                        b = 0;

                        Console.WriteLine("Answer : {0} --> {1}", i, ans);
                    Monitor.Exit(_object);

                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex.ToString());
                }
            }
        }
    }

مادامی که یک Thread در حالت انتخاب اعداد تصادفی تا تقسیم و اعلام نتیجه می‌باشد، به Thread‌های داخلی دیگر، اجازه‌ی ورود به این بخش که تحت کنترل Monitor می‌باشد داده نخواهد شد. همانطور که گفته شده، بازه‌ی تحت کنترل مانیتور میتواند با بلاک Lock(object) جایگزین شود. شیء object یک شیء مشترک (static) میان تمام اشیاء است برای کنترل ورود Thread‌ها و قفل گزاری مشترک بین این اشیاء.

2- Mutex:
این نوع قفل گزاری به منظور محافظت منابع مشترک برای جلوگیری از ورود Thread‌های بیرونی استفاده می‌شود. منظور از Thread‌های بیرونی Thread‌های یک کامپیوتر است. همچنین می‌توان از Mutex بجای lock نیز استفاده کرد؛ اما به دلیل هدف کاری Mutex، باید هزینه‌ی بیشتری (تقریبا 50 برابر کندتر از Lock) پرداخت کرد.
 static void Main()
  { 
    using (var mutex = new Mutex (false, "dotnettips.info Demo"))
    {
     
      if (!mutex.WaitOne (TimeSpan.FromSeconds (3), false))
      {
        Console.WriteLine ("Another app instance is running. Bye!");
        return;
      }
      RunProgram();
    }
  }
 
  static void RunProgram()
  {
    Console.WriteLine ("Running. Press Enter to exit");
    Console.ReadLine();
  }
در مثال بالا از یک Mutex نام دار استفاده شده است که به ما این امکان را می‌دهد تا به صورت Computer-Wide روی Thread‌ها ایجاد محدودیت نماییم. اگر متد بالا را در دو ترمینال اجرا کنید، نسخه‌ی دوم اجرا نخواهد شد. البته این نکته را در نظر داشته باشید که این امکان در سیتم عامل‌های مبتنی بر Linux غیرفعال است .
Mutex دارای دو متد مهم است :

۱- WaiteOne : شروع Blocking با این متد خواهد بود و اگر بتواند عملیات blocking را انجام دهد مقدار True را باز می‌گرداند. این متد دارای دو ورودی دیگر نیز هست که در مقالات بعدی به طور مفصل به آن‌ها اشاره خواهد شد. اما بطور خلاصه می‌توان اینگونه عنوان نمود که یک پارامتر زمان وجود دارد که مدت زمان انتظار برای Blocking را مشخص می‌کند و پارامتر Boolean دیگری که در حالت synchronization مورد استفاده قرار می‌گیرد و خروج و یا عدم خروج از دامنه synchronization را مشخص می‌کند.

۲- ReleaseMutex : شروع آزاد سازی انحصار، با این متد انجام می‌شود.

هیچگاه نباید یک Mutex را در کد رها کرد؛ زیرا باعث به‌وجود آمدن خطاهایی در کد خواهد شد. روش‌هایی برای رها سازی وجود دارد مانند Dispose کردن Mutex و یا استفاده از متد ReleaseMutex. قبل از خروج از کد باید دقت داشت در بخش هایی از کد که از این نوع قفل گزاری استفاده شده‌است، حتما باید مکانیسم‌های Exception Handling و یا Disposing را برای مدیریت Mutex ایجاد شده اعمال کرد.

3 -Semaphore 
یک نسخه پیشرفته‌تر از Mutex است که می‌تواند برای Thread‌های داخلی و یا خارجی استفاده شود و روی آنها اعمال محدودیت کند. همچنین می‌تواند اجازه‌ی ورود یک تا چند Thread را به بخشی از کد، برای محافظت از منابع بدهد. Semaphore نیز مانند Mutex دارای متد‌های Wait و Release است. یک Semaphore با ظرفیت ورود یک Thread در لحظه همان Mutex است. همچنین از Semaphore‌‌ها می‌توان در متدهای Async نیز استفاده کرد.

4- SemaphoreSlim
در واقع یک نسخه‌ی پیشرفته از Monitor و یک نسخه‌ی سبک وزن از Semaphore است و به همان شکل به شما اجازه‌ی محدودیت گزاری فقط بر روی Thread‌های داخلی را می‌دهد. اما بجای اجازه‌ی ورود فقط یک Thread، به شما این امکان را می‌دهد که اجازه‌ی ورود همزمان یک یا چند Thread را به انتخاب خود بدهید.

هزینه‌ی اعمال محدودیت (قفل گزاری) روی Thread ها
به طور کل هزینه‌ی قفل گزاری بر روی Thread‌ها بالاست. اما در صورت نیاز باید انتخاب درستی از بین موارد عنوان شده را انتخاب نمود. lock/Monitor و SemaphoreSlim دارای کمترین هزینه و Mutex و Semaphore دارای بیشترین هزینه و سربار هستند. اگر در Application‌های بزرگ از Mutex و Semaphore به درستی استفاده نشود، به جد باعث کندی خواهد شد.

در بخش بعدی مقاله، Double-checked locking را مورد بررسی قرار خواهیم داد.
مطالب
راه‌اندازی Http Interceptor در Angular
ماژول Http در Angular، برای برقراری ارتباط بین کلاینت و سمت سرور، مورد استفاده قرار می‌گیرد. معمولا هنگام ساخت درخواست‌های Http، یکسری کدهای تکراری برای تنظیم هدر (برای اعتبارسنجی و همچنین تنظیمات دیگر) نوشته می‌شوند که در هر درخواست یکسان هستند. همچنین بعد از آمدن جواب (Response) از سمت سرور نیز یکسری کدهای تکراری جهت برسی کد response و یا تغییر فرمت اطلاعات رسیده، به ساختار مورد توافق نوشته خواهند شد.

برای مثال در صورتیکه در برنامه خود از اعتبار سنجی مبتنی بر توکن (Token Base Authentication) استفاده می‌کنید، قبل از ارسال هر درخواست (request)، کدهایی مشابه کد زیر باید نوشته شوند:
let headers = new Headers();
let token = localStorage.getItem('token');
headers.append('Authorization', 'bearer ' + token);
this.http.get('/api/controller/action', { headers: headers })

همچنین فرض کنید بعد از رسیدن جواب هر درخواست، می‌خواهید response code را چک کنید و خطاهای احتمالی را مدیریت کنید. مثلا درصورت دریافت کد 401، کاربر را به صفحه «ورود» و با دریافت کد 404 آنرا را به صفحه «یافت نشد» هدایت کنید و یا با دریافت کد 403 یا 500 پیغام مناسبی را نمایش دهید. بدیهی است در این صورت بعد از هر آمدن پاسخ از سمت سرور (response)، این کدها بایستی تکرار شوند.

جهت پرهیز از این کدهای تکراری، می‌توان برای ماژول Http، یک interceptor واحد درنظر گرفت که تمامی کدهای تکراری را تنها یکبار داخل آن پیاده سازی کرد. مزیت این روش، مدیریت راحت کد، کاهش پیچیدگی‌ها و همچنین حذف کدهای تکراری و یکسان سازی آنها است.
هرچند در Angular دیگر به مانند Angular 1.x مفهوم intercept بر روی Http را به صورت توکار نداریم، ولی به دلایل زیر ما نیاز به پیاده سازی interceptor برای ماژول Http را داریم:
- تنظیم هدرهای سفارشی و اصلاح آدرس، قبل از ارسال درخواست به سمت سرور
- تنظیم token در هدر درخواست، جهت اعتبار سنجی
- مدیریت سراسری خطاهای Http
- انجام هرگونه عملیات crosscutting

حالا که Angular مفهموم intercept را برای ماژول Http خود به صورت توکار درنظر نگرفته است، راه‌حل چیست؟ بهترین راه‌حل برای پیاده سازی موارد مطرح شده در بالا، ارث بری و یا گسترش (extend) مستقیم ماژول Http است:
import { Injectable } from "@angular/core";
import { ConnectionBackend, RequestOptions, Request, RequestOptionsArgs, Response, Http, Headers } from "@angular/http";
import { Observable } from "rxjs/Rx";
import 'rxjs/add/operator/catch';
import 'rxjs/add/observable/throw';

@Injectable()
export class InterceptedHttp extends Http {
    constructor(backend: ConnectionBackend, defaultOptions: RequestOptions) {
        super(backend, defaultOptions);
    }

    request(url: string | Request, options?: RequestOptionsArgs): Observable<Response> {
        // اصلاح url
        if (typeof (url) === 'string')
            url = this.updateUrl((url as string));
        else
            url.url = this.updateUrl((url as Request).url);

        return super.request(url, this.getRequestOptionArgs(options)).catch((err: Response) => {
            // Exception handling
            switch (err.status) {
                case 400:
                    console.log('interceptor: 400');
                    console.log(err);
                    break;
                case 404:
                    console.log('interceptor: 404');
                    console.log(err);
                    break;
                case 500:
                    console.log('interceptor: 500');
                    console.log(err);
                    break;
                case 401:
                    console.log('interceptor: 401');
                    console.log(err);
                    break;
                case 403:
                    console.log('interceptor: 403');
                    console.log(err);
                    break;
                default:
                    console.log('interceptor: ' + err.status);
                    console.log(err);
            }
            return Observable.throw(err);

        });
    }

    private updateUrl(req: string) {
        return `http://localhost:61366/api/${req}`
    }

    private getRequestOptionArgs(options?: RequestOptionsArgs): RequestOptionsArgs {
        if (options == null) {
            options = new RequestOptions();
        }
        if (options.headers == null) {
            options.headers = new Headers();
        }
        // هدر درخواست تنظیم
        let token = localStorage.getItem('token');
        options.headers.append('Authorization', 'bearer ' + token);


        return options;
    }
}
تمامی افعال Http، از جمله get ،post ،put ،delete ،patch ،head و options در نهایت از متد request موجود در ماژول http برای ارسال درخواست خود استفاده می‌کنند. به همین جهت تمامی عملیات crosscutting را در این متد پیاده سازی کرده‌ایم. به علاوه قبل از ارسال درخواست، توسط متد updateUrl آدرس url خود را اصلاح کرده‌ایم. همچنین توسط متد getRequestOptionArgs هدر درخواست را جهت اعتبار سنجی مقداردهی کرده‌ایم. در اینجا بعد از ارسال درخواست و آمدن response از سمت سرور، توسط catch خطاهای احتمالی را برسی کرده‌ایم.

نکته: به عنوان مثال، در صورتیکه قصد دارید، برای درخواست‌هایی از جنس get، هدر متفاوتی نسبت به دیگر درخواست‌ها داشته باشید، آنگاه پیاده سازی عملیات اصلاح هدر در متد request جواب کار را نخواهد داد. برای حل این موضوع می‌توانید به جای اصلاح header در متد request، تمامی متدهای get ،post، put ،delete ،patch ،head و options را باز نویسی کرده و در هرکدام از این متدها اینکار را انجام دهید.

حالا با تغییر قسمت providers در ماژول اصلی برنامه به شکل زیر، Angular را مجبور می‌کنیم بجای استفاده از ماژول Http توکار خود، از ماژول جدید InterceptedHttp استفاده کند:
//…
providers: [{
        provide: Http,
        useFactory: (backend: XHRBackend, options: RequestOptions) => {
            return new InterceptedHttp(backend, options);
        },
        deps: [XHRBackend, RequestOptions],
    }],
//…

همه چیز آماده است. اکنون کافی است ماژول Http را در سرویس یا کامپوننت‌های خود تزریق کرده و درخواست‌های Http را بدون هیچگونه نوشتن کد اضافی برای تنظیم هدر و غیره (با فرض اینکه تمامی آنها در متد request از ماژول http نوشته شده‌اند)، به مانند قبل صادر کنید. برای نمونه کد زیر را ببینید.
import { Http, URLSearchParams } from '@angular/http';

//…
constructor(private _http: Http) { }

ngOnInit() {
    let urlSearchParams: URLSearchParams = new URLSearchParams();
    urlSearchParams.append('page', page.toString());
    urlSearchParams.append('count', count.toString());
    let params = urlSearchParams.toString();
    this._http.get(`/cars`, { params: params })
        .subscribe(result => {
            console.log('service: Succ');
            this.cars = result.json();
        }, err => {
            console.log('service: error');
        });
}
//…
با اینکه Angular از interceptor پشتیبانی نمی‌کند، ولی کتابخانه‌هایی برای ایجاد قابلیت مشابه interceptor به وجود آمده‌اند که برخی از آنها عبارتند از:  angular2-cool-http ، ng2-http-interceptor ، ng2-interceptors . به جای extend مستقیم ماژول Http توسط خودتان، اینکار را می‌توانید به این کتابخانه‌ها بسپارید.
مطالب
بررسی وجود اتصال اینترنتی در اندروید
یکی از اصلی‌ترین کارهایی که در اپلیکیشن‌هایی که قصد اتصال به اینترنت را دارند انجام می‌دهیم این است که قبل از هر کاری وضعیت اتصال اینترنتی را مشخص کنیم تا در هنگام اجرای فرآیندها به مشکل یا خطایی برخورد نکنیم تا برنامه منجر به خطای Force Close شود. با یک جست و جوی ساده در گوگل به تکه کد زیر می‌رسیم:
 public boolean isNetworkAvailable(Context context) {
        ConnectivityManager connectivityManager
                = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
        NetworkInfo activeNetworkInfo = connectivityManager.getActiveNetworkInfo();
        return activeNetworkInfo != null && activeNetworkInfo.isConnected();
    }
برای اجرای تکه کد بالا شما نیاز به مجوز زیر دارید:
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
تا به اینجای کار بسیار راحت بود. ولی اگر با دقت مجوز بالا را بخوانید نوشته است که شما به وضعیت شبکه دسترسی دارید. یعنی اینکه ممکن است گوشی شما از طریق هر آداپتور یا قطعه‌ای به یک شبکه متصل باشد. ولی الزامی نیست که شبکه مورد نظر اینترنت باشد. این تکه کد فقط وضعیت شبکه‌های فعالی را که عموما از طریق wifi و mobile data متصل می‌باشد را برای شما باز می‌گرداند.

البته توصیه ما نیز استفاده از این کد هست و توصیه می‌شود که استثناءها یا وضعیت خروجی‌ها را کنترل نمایید. روش‌های زیر تنها تحلیل کوچکی برای بررسی وضعیت اینترنت است یا اینکه واقعا به این بررسی‌های نیاز داشته باشید. در غیر این صورت برای بسیاری از برنامه‌ها همین کد کفایت می‌کند. راه حل‌های پایین مواردی است که از تجربه خود به دست آورده‌ام تا شاید راهنمایی برای افرادی باشد که میخواهند این کار را آغاز کنند تا در وقتشان صرفه جویی شود.

مثال‌های زیر وضعیت‌هایی را نشان میدهند که شبکه موجود است ولی اینترنتی در دسترس نیست:
  • مودم وای فای را فعال کرده است، ولی اینترنت را در اختیار ندارد که این علل میتواند عدم ثابت شدن چراغ DSL یا راه اندازی مجدد مودم باشد که وای فای زودتر از DSL فعال می‌شود و یا اینکه اشتراک شما تمام شده است یا در شبکه به مشکل برخورد کرده‌اید.
  • شما از طریق mobile data قصد اتصال دارید. در این حالت یا اعتبار شما پایان یافته است یا شبکه آنان دچار اختلال است.
  • شما در یک محیط اداری هستید که به عنوان مثال سیستمشان توسط روترهای میکروتیک هدایت می‌شود. در این حالت شما میتوانید وارد شبکه بدون کلمه عبور آنان شوید. ولی نیاز دارید که حتما صفحه لاگین را رد نمایید تا اینترنت در اختیار شما قرار بگیرد.

در همه مثال‌های بالا اینترنتی وجود ندارد، ولی تکه کد بالا true را برخواهد گرداند.
برای اینکار می‌توان از دو راهکار استفاده کرد. یکی از روش‌ها پینگ زدن به سرورهای اینترنتی است که اگر وضعیت پینگ پاسخ داده شود، شما مطمئن می‌شوید که به شبکه جهانی متصلید. تکه کد زیر می‌تواند اینکار را انجام دهد.
 public boolean IsInternetConnected()
    {
        try {
            Process ipProcess = Runtime.getRuntime().exec("/system/bin/ping -c 1 4.2.2.4");
            int     exitValue = ipProcess.waitFor();
            return (exitValue == 0);
        } catch (IOException e)          { e.printStackTrace(); }
        catch (InterruptedException e) { e.printStackTrace(); }
        return false;
    }
در خط اول از متد exec استفاده کردیم که معادل آن در دات نت استفاده از
System.Diagnostics.Process.Start("processName");
می‌باشد. عبارتی که به عنوان نام پروسس نوشتیم در واقع نحوه اجرای یک ICMP ساده در سیستم‌های مبتنی بر یونیکس است و از آنجا که اندروید از لینوکس وام گرفته شده است پس می‌توان پروسه بالا را صدا زد.
فرمان یا دستور بالا به شرح زیر است:
در سیستم عامل لینکوس تمام برنامه‌های سیستمی مورد نیاز، در شاخه bin قرار می‌گیرند و پینگ، یکی از آن هاست. سوییچ c هم که مخفف count است، به معنی تعداد درخواست‌های یک اکو است که در این دستور گفته‌ایم تنها یک درخواست اکو echo ارسال کن. (ااطلاعات بیشتر در مورد دستور پینگ ).
در خط بعدی از آنجا که این دستور، یک دستور زمان بر است، باید مدتی در این کد توقف شود تا مقدار مورد نظر دریافت شود. در صورتی که مقدار 0 بازگردانده شود، اکو پاسخ داده شده است و یعنی اینکه شما به اینترنت متصلید. (مشاهده کدهای وضعیتی ICMP )
 وجود catch‌های بالا الزامی است از آنجا که متد‌های استفاده شده توسط استثناءهای زیر throw شده‌اند، جاوا شما را ملزم به استفاده از catch‌های این استثناها خواهد کرد.
 public Process exec(String prog) throws java.io.IOException {
        return exec(prog, null, null);
    }

  public abstract int waitFor() throws InterruptedException;

برای اجرا این تکه کد شما نیاز به مجوز اتصال به اینترنت دارید:
 <uses-permission android:name="android.permission.INTERNET"/>

نکته مهم اینکه نگران اجرای این دستور در گوشی کاربر نباشید. این دستور نیاز به مجوز روت ندارد.

با اجرای این تکه کد تمام مسائل بالا حل می‌شود، به جز سرعت کند آن جهت پینگ زدن و دیگری مورد آخر که سیستم شما توسط یک روتر با وضعیت گفته شده کنترل شود. در این سیستم‌ها حتی اگر به اینترنت هم متصل باشید، پینگ شما پاسخی داده نمی‌شود. به همین علت یک روش ساده‌تر نیز وجود دارد و آن درخواست یک صفحه اینترنتی مطمئن و با دوام چون گوگل است که در بسیاری از سایت‌ها این روش نیز پیشنهاد شده است.
تکه کد زیر صفحه گوگل را درخواست می‌کند و در نهایت وضعیت کد http آن را دریافت می‌کنیم و اگر این کد وضعیت برابر 200 بود به این معنی است که اینترنت متصل می‌باشد. ولی در یک سیستم میکروتیک که هنوز وارد سیستم آن نشده باشید، به صفحه لاگین هدایت می‌شوید و وضعیت دیگری را دریافت خواهید مانند آدرس درخواستی شما redirect شده است یا اینکه باز هم کد 200 را دریافت می‌کنید که در بیشتر حالات هم به همین شکل است. برای رفع این مسئله بهتر است url فعلی را با url درخواستی مطابقت دهیم. برای این قضیه گوگل در بخش Handling Network Sign-On این صفحه چنین کدی را پیشنهاد داده است:
 HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
   try {
     InputStream in = new BufferedInputStream(urlConnection.getInputStream());
     if (!url.getHost().equals(urlConnection.getURL().getHost())) {
       // we were redirected! Kick the user out to the browser to sign on?
     
     ...
   } finally {
     urlConnection.disconnect();
   }
 }

ولی با توجه به تحقیقات و مشاهداتی که کرده‌ام، در بعضی از گوشی‌ها این کد کارکرد مناسبی ندارد و برای خودم هم پاسخی دریافت نکردم. اگر واقعا باز هم مصر هستید که این وضعیت را بررسی کنید، می‌تواند بررسی یک url با محتوای خاص باشد و بعد از دریافت این صفحه محتوای آن را بررسی کنید.
ولی با این همه بسیاری از برنامه‌ها از همان تکه کد بالا استفاده می‌کنند و با مدیریت استثناءها سعی در جلوگیری از خطا دارند. در غیر این صورت شما باید مدام در حال بررسی وضعیت اینترنت به شکل بالا باشید که بسیار زمان بر خواهد شد.
در صورتی که شما روش بهتری را برای بررسی وضعیت اینترنت دارید یا راه حل خاصی به نظرتان می‌رسد بسیار عالی خواهد بود که آن را با ما به اشتراک بگذارید.