اشتراکها
پکیج منجر gem
اشتراکها
راهنمای React Hooks
در قسمت قبل، دسترسی به قسمتهایی از برنامهی کلاینت را توسط ویژگی Authorize و همچنین نقشهای مشخصی، محدود کردیم. در این مطلب میخواهیم اگر کاربری هنوز وارد سیستم نشدهاست و قصد مشاهدهی صفحات محافظت شده را دارد، به صورت خودکار به صفحهی لاگین هدایت شود و یا اگر کاربری که وارد سیستم شدهاست اما نقش مناسبی را جهت دسترسی به یک صفحه ندارد، بجای هدایت به صفحهی لاگین، پیام مناسبی را دریافت کند.
هدایت سراسری و خودکار کاربران اعتبارسنجی نشده به صفحهی لاگین
در برنامهی این سری، اگر کاربری که به سیستم وارد نشدهاست، بر روی دکمهی Book یک اتاق کلیک کند، فقط پیام «Not Authorized» را مشاهده خواهد کرد که تجربهی کاربری مطلوبی بهشمار نمیرود. بهتر است در یک چنین حالتی، کاربر را به صورت خودکار به صفحهی لاگین هدایت کرد و پس از لاگین موفق، مجددا او را به همین آدرس درخواستی پیش از نمایش صفحهی لاگین، هدایت کرد. برای مدیریت این مساله کامپوننت جدید RedirectToLogin را طراحی میکنیم که جایگزین پیام «Not Authorized» در کامپوننت ریشهای BlazorWasm.Client\App.razor خواهد شد. بنابراین ابتدا فایل جدید BlazorWasm.Client\Pages\Authentication\RedirectToLogin.razor را ایجاد میکنیم. چون این کامپوننت بدون مسیریابی خواهد بود و قرار است مستقیما داخل کامپوننت دیگری درج شود، نیاز است فضای نام آنرا نیز به فایل BlazorWasm.Client\_Imports.razor اضافه کرد:
پس از آن، محتوای این کامپوننت را به صورت زیر تکمیل میکنیم:
توضیحات:
در اینجا روش کار کردن با AuthenticationState را از طریق کدنویسی ملاحظه میکنید. در زمان بارگذاری اولیهی این کامپوننت، بررسی میشود که آیا کاربر جاری، به سیستم وارد شدهاست یا خیر؟ اگر خیر، او را به سمت صفحهی لاگین هدایت میکنیم. اما اگر کاربر پیشتر به سیستم وارد شده باشد، متن شما دسترسی ندارید، به همراه لیست نقشهای او در صفحه ظاهر میشوند که برای دیباگ برنامه مفید است و دیگر به سمت صفحهی لاگین هدایت نمیشود.
چون این کامپوننت اکنون در بالاترین سطح سلسله مراتب کامپوننتهای تعریف شده قرار دارد، به صورت سراسری به تمام صفحات و کامپوننتهای برنامه اعمال میشود.
چگونه دسترسی نقش ثابت Admin را به تمام صفحات محافظت شده برقرار کنیم؟
اگر خاطرتان باشد در زمان ثبت کاربر ادمین Identity، تنها نقشی را که برای او ثبت کردیم، Admin بود که در تصویر فوق هم مشخص است؛ اما ویژگی Authorize استفاده شده جهت محافظت از کامپوننت (attribute [Authorize(Roles = ConstantRoles.Customer)]@)، تنها نیاز به نقش Customer را دارد. به همین جهت است که کاربر وارد شدهی به سیستم، هرچند از دیدگاه ما ادمین است، اما به این صفحه دسترسی ندارد. بنابراین اکنون این سؤال مطرح است که چگونه میتوان به صورت خودکار دسترسی نقش Admin را به تمام صفحات محافظت شدهی با نقشهای مختلف، برقرار کرد؟
برای رفع این مشکل همانطور که پیشتر نیز ذکر شد، نیاز است تمام نقشهای مدنظر را با یک کاما از هم جدا کرد و به خاصیت Roles ویژگی Authorize انتساب داد؛ و یا میتوان این عملیات را به صورت زیر نیز خلاصه کرد:
در این حالت، AuthorizeAttribute سفارشی تهیه شده، همواره به همراه نقش ثابت ConstantRoles.Admin هم هست و همچنین دیگر نیازی نیست کار جمع زدن قسمتهای مختلف را با کاما انجام داد؛ چون string.Join نوشته شده همینکار را انجام میدهد.
پس از این تعریف میتوان در کامپوننتها، ویژگی Authorize نقش دار را با ویژگی جدید Roles، جایگزین کرد که همواره دسترسی کاربر Admin را نیز برقرار میکند:
مدیریت سراسری خطاهای حاصل از درخواستهای HttpClient
تا اینجا نتایج حاصل از شکست اعتبارسنجی سمت کلاینت را به صورت سراسری مدیریت کردیم. اما برنامههای سمت کلاینت، به کمک HttpClient خود نیز میتوانند درخواستهایی را به سمت سرور ارسال کرده و در پاسخ، برای مثال not authorized و یا forbidden را دریافت کنند و یا حتی internal server error ای را در صورت بروز استثنایی در سمت سرور.
فرض کنید Web API Endpoint جدید زیر را تعریف کردهایم که نقش ادیتور را میپذیرد. این نقش، جزو نقشهای تعریف شدهی در برنامه و سیستم Identity ما نیست. بنابراین هر درخواستی که به سمت آن ارسال شود، برگشت خواهد خورد و پردازش نمیشود:
برای مدیریت سراسری یک چنین خطای سمت سروری در یک برنامهی Blazor WASM میتوان یک Http Interceptor نوشت:
توضیحات:
با ارثبری از کلاس پایهی DelegatingHandler میتوان متد SendAsync تمام درخواستهای ارسالی توسط برنامه را بازنویسی کرد و تحت نظر قرار داد. برای مثال در اینجا، پیش از فراخوانی await base.SendAsync کلاس پایه (یا همان درخواست اصلی که در قسمتی از برنامه صادر شدهاست)، یک توکن را به هدرهای درخواست، اضافه کردهایم و یا پس از این فراخوانی (که معادل فراخوانی اصل کد در حال اجرای برنامه است)، با بررسی StatusCode بازگشتی از سمت سرور، کاربر را به یکی از صفحات یافت نشد، خطایی رخ دادهاست و یا دسترسی ندارید، هدایت کردهایم. برای نمونه کامپوننت Unauthorized.razor را با محتوای زیر تعریف کردهایم:
که سبب میشود زمانیکه StatusCode مساوی 401 و یا 403 را از سمت سرور دریافت کردیم، خطای فوق را به صورت خودکار به کاربر نمایش دهیم.
پس از تدارک این Interceptor سراسری، نوبت به معرفی آن به برنامهاست که ... در ابتدا نیاز به نصب بستهی نیوگت زیر را دارد:
این بستهی نیوگت، امکان دسترسی به متدهای الحاقی AddHttpClient و سپس AddHttpMessageHandler را میسر میکند که توسط متد AddHttpMessageHandler است که میتوان Interceptor سراسری را به سیستم معرفی کرد. بنابراین تعاریف قبلی و پیشفرض HttpClient را حذف کرده و با AddHttpClient جایگزین میکنیم:
پس از این تنظیمات، در هر قسمتی از برنامه که با HttpClient تزریق شده کار میشود، تفاوتی نمیکند که چه نوع درخواستی به سمت سرور ارسال میشود، هر نوع درخواستی که باشد، تحت نظر قرار گرفته شده و بر اساس پاسخ دریافتی از سمت سرور، واکنش نشان داده خواهد شد. به این ترتیب دیگر نیازی نیست تا switch (response.StatusCode) را که در Interceptor تکمیل کردیم، در تمام قسمتهای برنامه که با HttpClient کار میکنند، تکرار کرد. همچنین مدیریت سراسری افزودن JWT به تمام درخواستها نیز به صورت خودکار انجام میشود.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: Blazor-5x-Part-33.zip
هدایت سراسری و خودکار کاربران اعتبارسنجی نشده به صفحهی لاگین
در برنامهی این سری، اگر کاربری که به سیستم وارد نشدهاست، بر روی دکمهی Book یک اتاق کلیک کند، فقط پیام «Not Authorized» را مشاهده خواهد کرد که تجربهی کاربری مطلوبی بهشمار نمیرود. بهتر است در یک چنین حالتی، کاربر را به صورت خودکار به صفحهی لاگین هدایت کرد و پس از لاگین موفق، مجددا او را به همین آدرس درخواستی پیش از نمایش صفحهی لاگین، هدایت کرد. برای مدیریت این مساله کامپوننت جدید RedirectToLogin را طراحی میکنیم که جایگزین پیام «Not Authorized» در کامپوننت ریشهای BlazorWasm.Client\App.razor خواهد شد. بنابراین ابتدا فایل جدید BlazorWasm.Client\Pages\Authentication\RedirectToLogin.razor را ایجاد میکنیم. چون این کامپوننت بدون مسیریابی خواهد بود و قرار است مستقیما داخل کامپوننت دیگری درج شود، نیاز است فضای نام آنرا نیز به فایل BlazorWasm.Client\_Imports.razor اضافه کرد:
@using BlazorWasm.Client.Pages.Authentication
@using System.Security.Claims @inject NavigationManager NavigationManager if(AuthState is not null) { <div class="alert alert-danger"> <p>You [@AuthState.User.Identity.Name] do not have access to the requested page</p> <div> Your roles: <ul> @foreach (var claim in AuthState.User.Claims.Where(c => c.Type == ClaimTypes.Role)) { <li>@claim.Value</li> } </ul> </div> </div> } @code { [CascadingParameter] private Task<AuthenticationState> AuthenticationState {set; get;} AuthenticationState AuthState; protected override async Task OnInitializedAsync() { AuthState = await AuthenticationState; if (!IsAuthenticated(AuthState)) { var returnUrl = NavigationManager.ToBaseRelativePath(NavigationManager.Uri); if (string.IsNullOrEmpty(returnUrl)) { NavigationManager.NavigateTo("login"); } else { NavigationManager.NavigateTo($"login?returnUrl={Uri.EscapeDataString(returnUrl)}"); } } } private bool IsAuthenticated(AuthenticationState authState) => authState?.User?.Identity is not null && authState.User.Identity.IsAuthenticated; }
در اینجا روش کار کردن با AuthenticationState را از طریق کدنویسی ملاحظه میکنید. در زمان بارگذاری اولیهی این کامپوننت، بررسی میشود که آیا کاربر جاری، به سیستم وارد شدهاست یا خیر؟ اگر خیر، او را به سمت صفحهی لاگین هدایت میکنیم. اما اگر کاربر پیشتر به سیستم وارد شده باشد، متن شما دسترسی ندارید، به همراه لیست نقشهای او در صفحه ظاهر میشوند که برای دیباگ برنامه مفید است و دیگر به سمت صفحهی لاگین هدایت نمیشود.
در ادامه برای استفاده از این کامپوننت، به کامپوننت ریشهای BlazorWasm.Client\App.razor مراجعه کرده و قسمت NotAuthorized آنرا به صورت زیر، با معرفی کامپوننت RedirectToLogin، جایگزین میکنیم:
<NotAuthorized> <RedirectToLogin></RedirectToLogin> </NotAuthorized>
چگونه دسترسی نقش ثابت Admin را به تمام صفحات محافظت شده برقرار کنیم؟
اگر خاطرتان باشد در زمان ثبت کاربر ادمین Identity، تنها نقشی را که برای او ثبت کردیم، Admin بود که در تصویر فوق هم مشخص است؛ اما ویژگی Authorize استفاده شده جهت محافظت از کامپوننت (attribute [Authorize(Roles = ConstantRoles.Customer)]@)، تنها نیاز به نقش Customer را دارد. به همین جهت است که کاربر وارد شدهی به سیستم، هرچند از دیدگاه ما ادمین است، اما به این صفحه دسترسی ندارد. بنابراین اکنون این سؤال مطرح است که چگونه میتوان به صورت خودکار دسترسی نقش Admin را به تمام صفحات محافظت شدهی با نقشهای مختلف، برقرار کرد؟
برای رفع این مشکل همانطور که پیشتر نیز ذکر شد، نیاز است تمام نقشهای مدنظر را با یک کاما از هم جدا کرد و به خاصیت Roles ویژگی Authorize انتساب داد؛ و یا میتوان این عملیات را به صورت زیر نیز خلاصه کرد:
using System; using BlazorServer.Common; using Microsoft.AspNetCore.Authorization; namespace BlazorWasm.Client.Utils { [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)] public class RolesAttribute : AuthorizeAttribute { public RolesAttribute(params string[] roles) { Roles = $"{ConstantRoles.Admin},{string.Join(",", roles)}"; } } }
پس از این تعریف میتوان در کامپوننتها، ویژگی Authorize نقش دار را با ویژگی جدید Roles، جایگزین کرد که همواره دسترسی کاربر Admin را نیز برقرار میکند:
@attribute [Roles(ConstantRoles.Customer, ConstantRoles.Employee)]
مدیریت سراسری خطاهای حاصل از درخواستهای HttpClient
تا اینجا نتایج حاصل از شکست اعتبارسنجی سمت کلاینت را به صورت سراسری مدیریت کردیم. اما برنامههای سمت کلاینت، به کمک HttpClient خود نیز میتوانند درخواستهایی را به سمت سرور ارسال کرده و در پاسخ، برای مثال not authorized و یا forbidden را دریافت کنند و یا حتی internal server error ای را در صورت بروز استثنایی در سمت سرور.
فرض کنید Web API Endpoint جدید زیر را تعریف کردهایم که نقش ادیتور را میپذیرد. این نقش، جزو نقشهای تعریف شدهی در برنامه و سیستم Identity ما نیست. بنابراین هر درخواستی که به سمت آن ارسال شود، برگشت خواهد خورد و پردازش نمیشود:
namespace BlazorWasm.WebApi.Controllers { [Route("api/[controller]")] [Authorize(Roles = "Editor")] public class MyProtectedEditorsApiController : Controller { [HttpGet] public IActionResult Get() { return Ok(new ProtectedEditorsApiDTO { Id = 1, Title = "Hello from My Protected Editors Controller!", Username = this.User.Identity.Name }); } } }
namespace BlazorWasm.Client.Services { public class ClientHttpInterceptorService : DelegatingHandler { private readonly NavigationManager _navigationManager; private readonly ILocalStorageService _localStorage; private readonly IJSRuntime _jsRuntime; public ClientHttpInterceptorService( NavigationManager navigationManager, ILocalStorageService localStorage, IJSRuntime JsRuntime) { _navigationManager = navigationManager ?? throw new ArgumentNullException(nameof(navigationManager)); _localStorage = localStorage ?? throw new ArgumentNullException(nameof(localStorage)); _jsRuntime = JsRuntime ?? throw new ArgumentNullException(nameof(JsRuntime)); } protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) { // How to add a JWT to all of the requests var token = await _localStorage.GetItemAsync<string>(ConstantKeys.LocalToken); if (token is not null) { request.Headers.Authorization = new AuthenticationHeaderValue("bearer", token); } var response = await base.SendAsync(request, cancellationToken); if (!response.IsSuccessStatusCode) { await _jsRuntime.ToastrError($"Failed to call `{request.RequestUri}`. StatusCode: {response.StatusCode}."); switch (response.StatusCode) { case HttpStatusCode.NotFound: _navigationManager.NavigateTo("/404"); break; case HttpStatusCode.Forbidden: // 403 case HttpStatusCode.Unauthorized: // 401 _navigationManager.NavigateTo("/unauthorized"); break; default: _navigationManager.NavigateTo("/500"); break; } } return response; } } }
با ارثبری از کلاس پایهی DelegatingHandler میتوان متد SendAsync تمام درخواستهای ارسالی توسط برنامه را بازنویسی کرد و تحت نظر قرار داد. برای مثال در اینجا، پیش از فراخوانی await base.SendAsync کلاس پایه (یا همان درخواست اصلی که در قسمتی از برنامه صادر شدهاست)، یک توکن را به هدرهای درخواست، اضافه کردهایم و یا پس از این فراخوانی (که معادل فراخوانی اصل کد در حال اجرای برنامه است)، با بررسی StatusCode بازگشتی از سمت سرور، کاربر را به یکی از صفحات یافت نشد، خطایی رخ دادهاست و یا دسترسی ندارید، هدایت کردهایم. برای نمونه کامپوننت Unauthorized.razor را با محتوای زیر تعریف کردهایم:
@page "/unauthorized" <div class="alert alert-danger mt-3"> <p>You don't have access to the requested resource.</p> </div>
پس از تدارک این Interceptor سراسری، نوبت به معرفی آن به برنامهاست که ... در ابتدا نیاز به نصب بستهی نیوگت زیر را دارد:
dotnet add package Microsoft.Extensions.Http
namespace BlazorWasm.Client { public class Program { public static async Task Main(string[] args) { var builder = WebAssemblyHostBuilder.CreateDefault(args); //... // builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) }); /*builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.Configuration.GetValue<string>("BaseAPIUrl")) });*/ // dotnet add package Microsoft.Extensions.Http builder.Services.AddHttpClient( name: "ServerAPI", configureClient: client => { client.BaseAddress = new Uri(builder.Configuration.GetValue<string>("BaseAPIUrl")); client.DefaultRequestHeaders.Add("User-Agent", "BlazorWasm.Client 1.0"); } ) .AddHttpMessageHandler<ClientHttpInterceptorService>(); builder.Services.AddScoped<ClientHttpInterceptorService>(); builder.Services.AddScoped(sp => sp.GetRequiredService<IHttpClientFactory>().CreateClient("ServerAPI")); //... } } }
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: Blazor-5x-Part-33.zip
روزگاری دریافت مجوزهای SSL، گران و سخت بود. برای رفع این مشکلات مؤسسههایی مانند Let's Encrypt پدیدار شدهاند که مجوزهای SSL رایگانی را برای سایتهای اینترنتی صادر میکنند. دسترسی به سرویس آنها از طریق API ارائه شدهی آن، بسیار ساده بوده، کار با آن رایگان است و نیاز به مجوز خاصی ندارد. فقط باید دقت داشت که گواهینامههای Let's Encrypt دو ماهه هستند و وبسرور سایت شما باید اجازهی دسترسی به محل ویژهای را که جهت تعیین اعتبار دومین درخواستی ایجاد میشود، صادر کند. البته درخواست گواهی مجدد و تمدید آن در هر زمانی، حتی اگر پیش از انقضای آن باشد، مسیر است و از این لحاظ محدودیتی ندارد. در ادامه نحوهی کار با این سرویس را در ویندوزهای سرور بررسی خواهیم کرد.
دریافت برنامهی win-acme
برنامهی win-acme کار دریافت، نصب و تنظیم به روز رسانی خودکار مجوزهای Let’s Encrypt را در ویندوز بسیار ساده کردهاست و تقریبا به برنامهی استاندارد انجام اینکار تبدیل شدهاست. این برنامه، انجام مراحل زیر را خودکار کردهاست:
- اسکن IIS برای یافتن bindings و نام سایتها
- اتصال به Let’s Encrypt certificate authority و دریافت مجوزهای لازم
- درج خودکار مجوزهای دریافتی در Windows certificate store
- ایجاد HTTPS binding خودکار در IIS
- استفاده از Windows Task Scheduler، جهت ایجاد وظیفهی به روز رسانی خودکار مجوزهای درخواست شده
به همین جهت پیش از هر کاری نیاز است این برنامه را دریافت کنید:
https://github.com/PKISharp/win-acme/releases
این برنامه از دات نت نگارش 4.6.2 استفاده میکند. بنابراین نیاز است این نگارش و یا ترجیحا آخرین نگارش دات نت فریم ورک را بر روی سرور نصب کنید.
آماده سازی برنامهی ASP.NET جهت دریافت مجوزهای Let’s Encrypt
را بر روی سرور شما بررسی خواهد کرد (بنابراین سرور شما باید به اینترنت متصل بوده و همچنین مجوز دسترسی به این مسیر را عمومی کند). برنامهی win-acme این id را از سرور Let’s Encrypt به صورت خودکار دریافت کرده و فایلی را در مسیر یاد شده ایجاد میکند. سپس سرور Let’s Encrypt یکبار این مسیر را خواهد خواند. مشکل اینجا است که دسترسی به این فایل بدون پسوند در برنامههای MVC به صورت پیشفرض مسیر نیست و نیازی به تنظیمات خاصی دارد:
روش انجام اینکار در ASP.NET Core به صورت زیر است:
این اکشن متد را در هر کنترلری قرار دهید، تفاوتی نمیکند و کار خواهد کرد؛ چون attribute routing آن مستقل از محل قرارگیری آن است.
در MVC 5x پارامتر env را حذف و بجای آن از Server.MapPath و در آخر از return File استفاده کنید.
اگر این مرحله را تنظیم نکنید، در وسط کار دریافت مجوز توسط برنامهی win-acme، به علت اینکه مشخص نیست آیا شما صاحب دامنه هستید یا خیر، خطایی را دریافت کرده و برنامه متوقف میشود.
آماده سازی IIS برای دریافت مجوزهای Let’s Encrypt
ابتدا به قسمت Edit bindings وب سایتی که قرار است مجوز را دریافت کند مراجعه کرده:
و سپس bindings مناسبی را ایجاد کنید (از نوع HTTP و نه HTTPS):
برای مثال اگر سایت شما قرار است توسط آدرسهای www.dotnettips.info و dotnettips.info در دسترس باشد، نیاز است دو binding را در اینجا ثبت کنید. برای تمام موارد ثبت شده هم این تنظیمات را مدنظر داشته باشید:
برنامهی win-acme بر اساس این HTTP Bindings است که معادلهای متناظر HTTPS آنها را به صورت خودکار ثبت و تنظیم میکند.
اجرای برنامهی win-acme بر روی ویندوز سرور 2008
IISهای 8 به بعد (و یا ویندوز سرور 2012 به بعد) دارای ویژگی هستند به نام Server Name Indication و یا SNI که اجاز میدهند بتوان چندین مجوز SSL را بر روی یک IP تنظیم کرد.
در اینجا به ازای هر Bindings تعریف شدهی در قسمت قبل، یک مجوز Let’s Encrypt دریافت خواهد شد. اما چون ویندوز سرور 2008 به همراه IIS 7.5 است، فاقد ویژگی SNI است. به همین جهت در حالت عادی برای مثال فقط برای www.dotnettips.info مجوزی را دریافت میکنید و اگر کاربر به آدرس dotnettips.info مراجعه کند، دیگر نمیتواند به سایت وارد شود و پیام غیرمعتبر بودن مجوز SSL را مشاهده خواهد کرد.
برنامهی win-acme برای رفع این مشکل، از ویژگی خاصی به نام «SAN certificate» پشتیبانی میکند.
به این ترتیب با ویندوز سرور 2008 هم میتوان دامنهی اصلی و زیر دامنههای تعریف شده را نیز پوشش داد و سایت به این ترتیب بدون مشکل کار خواهد کرد. مراحل تنظیم SAN توسط برنامهی win-acme به این صورت است:
ابتدا که برنامهی win-acme را با دسترسی admin اجرا میکنید، چنین منویی نمایش داده میشود:
گزینهی N یا ایجاد مجوز جدید را انتخاب کنید.
سپس منوی بعدی را نمایش میدهد:
در این حالت برای ویندوز سرور 2008، فقط و فقط گزینهی 2 را انتخاب کنید.
سپس لیست سایتهای نصب شدهی در IIS را نمایش میدهد:
در اینجا برای مثال شمارهی 1 یا هر شمارهی دیگر متناظر با وب سایت مدنظر را انتخاب کنید.
در ادامه منوی زیر را نمایش میدهد:
لیستی را که در اینجا مشاهده میکنید، همان Bindings است که پیشتر ایجاد کردیم. عنوان میکند که برای کدامیک از اینها نیاز است مجوز دریافت و نصب شود. کلید enter را فشار دهید تا برای تمام آنها اینکار صورت گیرد.
و ... همین! پس از آن کار دریافت، نصب و به روز رسانی Bindings در IIS به صورت خودکار انجام خواهد شد. اکنون اگر به قسمت Binding سایت مراجعه کنید، این تنظیمات خودکار جدید را مشاهده خواهید کرد:
اگر به لاگ نصب مجوزها دقت کنید این دو سطر نیز در انتهای آن ذکر میشوند:
علت اینجا است که مجوزهای Let’s Encrypt طول عمر کمی دارند و در صورت به روز نشدن مداوم، کاربران دیگر قادر به مرور سایت نخواهند بود. به همین جهت این برنامه یک Scheduled Task ویندوز را نیز جهت به روز رسانی خودکار این مجوزها ایجاد و تنظیم میکند.
اجرای برنامهی win-acme بر روی ویندوزهای سرور 2012 به بعد
چون IIS ویندوزهای سرور 2012 به بعد، از نصب و فعالسازی بیش از یک مجوز SSL به ازای یک IP به صورت توکار تحت عنوان ویژگی SNI پشتیبانی میکنند، مراحل انجام آن سادهتر هستند.
ابتدا که برنامهی win-acme را با دسترسی admin اجرا میکنید، چنین منویی نمایش داده میشود:
گزینهی N یا ایجاد مجوز جدید را انتخاب کنید.
سپس منوی بعدی را نمایش میدهد:
در این حالت گزینهی 4 را انتخاب کنید (با فرض اینکه از IIS 8.0 به بعد استفاده میکنید).
سپس از شما درخواست میکند که لیست دامنه و زیر دامنههایی را که قرار است برای آنها مجوز SSL صادر شوند، به صورت لیست جدا شدهی توسط کاما، وارد کنید:
در ادامه لیست وب سایتهای ثبت شدهی در IIS را نمایش میدهد:
در اینجا شمارهی سایتی را که میخواهید برای آن مجوز صادر شود، انتخاب کنید.
و ... همین! پس از آن مجوزهای SSL درخواستی، دریافت، نصب و تنظیم خواهند شد. همچنین یک Scheduled Task هم برای به روز رسانی خودکار آن تنظیم میشود.
دریافت برنامهی win-acme
برنامهی win-acme کار دریافت، نصب و تنظیم به روز رسانی خودکار مجوزهای Let’s Encrypt را در ویندوز بسیار ساده کردهاست و تقریبا به برنامهی استاندارد انجام اینکار تبدیل شدهاست. این برنامه، انجام مراحل زیر را خودکار کردهاست:
- اسکن IIS برای یافتن bindings و نام سایتها
- اتصال به Let’s Encrypt certificate authority و دریافت مجوزهای لازم
- درج خودکار مجوزهای دریافتی در Windows certificate store
- ایجاد HTTPS binding خودکار در IIS
- استفاده از Windows Task Scheduler، جهت ایجاد وظیفهی به روز رسانی خودکار مجوزهای درخواست شده
به همین جهت پیش از هر کاری نیاز است این برنامه را دریافت کنید:
https://github.com/PKISharp/win-acme/releases
این برنامه از دات نت نگارش 4.6.2 استفاده میکند. بنابراین نیاز است این نگارش و یا ترجیحا آخرین نگارش دات نت فریم ورک را بر روی سرور نصب کنید.
آماده سازی برنامهی ASP.NET جهت دریافت مجوزهای Let’s Encrypt
سرور Let’s Encrypt، در حین صدور مجوز برای سایت شما نیاز دارد بررسی کند که آیا شما واقعا صاحب همان دومین هستید یا خیر. به همین جهت مسیر
/.well-known/acme-challenge/id
[HttpGet("/.well-known/acme-challenge/{id}")] public IActionResult LetsEncrypt(string id, [FromServices] IHostingEnvironment env) { id = Path.GetFileName(id); // security cleaning var file = Path.Combine(env.ContentRootPath, ".well-known", "acme-challenge", id); return PhysicalFile(file, "text/plain"); }
در MVC 5x پارامتر env را حذف و بجای آن از Server.MapPath و در آخر از return File استفاده کنید.
[Route(".well-known/acme-challenge/{id}")] public ActionResult LetsEncrypt(string id) { id = Path.GetFileName(id); // security cleaning var file = Path.Combine(Server.MapPath("~/.well-known/acme-challenge"), id); return File(file, "text/plain", id); }
آماده سازی IIS برای دریافت مجوزهای Let’s Encrypt
ابتدا به قسمت Edit bindings وب سایتی که قرار است مجوز را دریافت کند مراجعه کرده:
و سپس bindings مناسبی را ایجاد کنید (از نوع HTTP و نه HTTPS):
برای مثال اگر سایت شما قرار است توسط آدرسهای www.dotnettips.info و dotnettips.info در دسترس باشد، نیاز است دو binding را در اینجا ثبت کنید. برای تمام موارد ثبت شده هم این تنظیمات را مدنظر داشته باشید:
Type:http Port:80 IP address:All Unassigned
اجرای برنامهی win-acme بر روی ویندوز سرور 2008
IISهای 8 به بعد (و یا ویندوز سرور 2012 به بعد) دارای ویژگی هستند به نام Server Name Indication و یا SNI که اجاز میدهند بتوان چندین مجوز SSL را بر روی یک IP تنظیم کرد.
در اینجا به ازای هر Bindings تعریف شدهی در قسمت قبل، یک مجوز Let’s Encrypt دریافت خواهد شد. اما چون ویندوز سرور 2008 به همراه IIS 7.5 است، فاقد ویژگی SNI است. به همین جهت در حالت عادی برای مثال فقط برای www.dotnettips.info مجوزی را دریافت میکنید و اگر کاربر به آدرس dotnettips.info مراجعه کند، دیگر نمیتواند به سایت وارد شود و پیام غیرمعتبر بودن مجوز SSL را مشاهده خواهد کرد.
برنامهی win-acme برای رفع این مشکل، از ویژگی خاصی به نام «SAN certificate» پشتیبانی میکند.
به این ترتیب با ویندوز سرور 2008 هم میتوان دامنهی اصلی و زیر دامنههای تعریف شده را نیز پوشش داد و سایت به این ترتیب بدون مشکل کار خواهد کرد. مراحل تنظیم SAN توسط برنامهی win-acme به این صورت است:
ابتدا که برنامهی win-acme را با دسترسی admin اجرا میکنید، چنین منویی نمایش داده میشود:
N: Create new certificate M: Create new certificate with advanced options L: List scheduled renewals R: Renew scheduled S: Renew specific A: Renew *all* V: Revoke certificate C: Cancel scheduled renewal X: Cancel *all* scheduled renewals Q: Quit
سپس منوی بعدی را نمایش میدهد:
[INFO] Running in Simple mode 1: Single binding of an IIS site 2: SAN certificate for all bindings of an IIS site 3: SAN certificate for all bindings of multiple IIS sites 4: Manually input host names C: Cancel
سپس لیست سایتهای نصب شدهی در IIS را نمایش میدهد:
1: Default Web Site C: Cancel Choose site: 1
در ادامه منوی زیر را نمایش میدهد:
* www.dotnettips.info * dotnettips.info Press enter to include all listed hosts, or type a comma-separated lists of exclusions:
و ... همین! پس از آن کار دریافت، نصب و به روز رسانی Bindings در IIS به صورت خودکار انجام خواهد شد. اکنون اگر به قسمت Binding سایت مراجعه کنید، این تنظیمات خودکار جدید را مشاهده خواهید کرد:
اگر به لاگ نصب مجوزها دقت کنید این دو سطر نیز در انتهای آن ذکر میشوند:
[INFO] Adding renewal for Default Web Site [INFO] Next renewal scheduled at 2018/7/21 4:19:20 AM
اجرای برنامهی win-acme بر روی ویندوزهای سرور 2012 به بعد
چون IIS ویندوزهای سرور 2012 به بعد، از نصب و فعالسازی بیش از یک مجوز SSL به ازای یک IP به صورت توکار تحت عنوان ویژگی SNI پشتیبانی میکنند، مراحل انجام آن سادهتر هستند.
ابتدا که برنامهی win-acme را با دسترسی admin اجرا میکنید، چنین منویی نمایش داده میشود:
N: Create new certificate M: Create new certificate with advanced options L: List scheduled renewals R: Renew scheduled S: Renew specific A: Renew *all* V: Revoke certificate C: Cancel scheduled renewal X: Cancel *all* scheduled renewals Q: Quit
سپس منوی بعدی را نمایش میدهد:
[INFO] Running in Simple mode 1: Single binding of an IIS site 2: SAN certificate for all bindings of an IIS site 3: SAN certificate for all bindings of multiple IIS sites 4: Manually input host names C: Cancel
سپس از شما درخواست میکند که لیست دامنه و زیر دامنههایی را که قرار است برای آنها مجوز SSL صادر شوند، به صورت لیست جدا شدهی توسط کاما، وارد کنید:
Enter comma-separated list of host names, starting with the primary one: dotnettips.info, www.dotnettips.info
1: Default Web Site 2: mysiteName Choose site to create new bindings: 1
و ... همین! پس از آن مجوزهای SSL درخواستی، دریافت، نصب و تنظیم خواهند شد. همچنین یک Scheduled Task هم برای به روز رسانی خودکار آن تنظیم میشود.
Without a doubt, maps are one of the most useful tools for users when included in an app. This tutorial is the first in a series going over Google Maps v2 for Android. It will cover setting up the Google Maps API through the Google Developer Console, including a map fragment in your applications, displaying the user's location, adding markers, drawing on the map, and some general methods that will add utility to your app.
Intermediate & Advanced
Intermediate & Advanced
اشتراکها
سایت CodePlex آرشیو شد
اشتراکها