new { Controller = x.DeclaringType.Name.Replace("Controller",""), ... })
بررسی Bad code smell ها: کلاس بزرگ
public MyController(ITransactionRepository transRepo; IAccountRepository accountRepo; ISystemsRepository sysRepo; IScheduleRepository schRepo; IProfileRepository profileRepo)
اضافه کردن دو خاصیت جدید به کلاس PagedQueryModel سمت کلاینت جهت مشخص سازی ستونی که قرار است بر روی آن جستجو انجام شود و همچنین مقدار آن:
export class PagedQueryModel { constructor( // ... public filterByColumn: string, public filterByValue: string, ) { } }
doFilter() { this.queryModel.page = 1; this.getPagedProductsList(); } resetFilter() { this.queryModel.page = 1; this.queryModel.filterByColumn = ""; this.queryModel.filterByValue = ""; this.getPagedProductsList(); }
پس از آن، قالب این گرید (products-list.component.html) جهت افزودن جستجو، به صورت زیر تغییر میکند:
<div class="panel panel-default"> <div class="panel-body"> <div class="form-group"> <input type="text" [(ngModel)]="queryModel.filterByValue" placeholder="Search For ..." class="form-control" /> </div> <div class="form-group"> <select class="form-control" name="filterColumn" [(ngModel)]="queryModel.filterByColumn"> <option value="">Filter by ...</option> <option *ngFor="let column of columns" [value]="column.propertyName"> {{ column.title }} </option> </select> </div> <button class="btn btn-primary" type="button" (click)="doFilter()">Search</button> <button class="btn btn-default" type="button" (click)="resetFilter()">Reset</button> </div> </div>
با این شکل:
تغییرات سمت سرور آن نیز به صورت ذیل است:
ابتدا IPagedQueryModel را با همان دو خاصیت جدید ستون فیلتر شونده و مقدار آن، تکمیل میکنیم:
public interface IPagedQueryModel { // .... string FilterByColumn { get; set; } string FilterByValue { get; set; } } public class ProductQueryViewModel : IPagedQueryModel { // ... other properties ... // ... public string FilterByColumn { get; set; } public string FilterByValue { get; set; } }
public static class IQueryableExtensions { public static IQueryable<T> ApplyFiltering<T>( this IQueryable<T> query, IPagedQueryModel model, IDictionary<string, Expression<Func<T, object>>> columnsMap) { if (string.IsNullOrWhiteSpace(model.FilterByValue) || !columnsMap.ContainsKey(model.FilterByColumn)) { return query; } var func = columnsMap[model.FilterByColumn].Compile(); return query.Where(x => func(x).ToString() == model.FilterByValue); }
در آخر، به کنترلر ProductController و اکشن متد GetPagedProducts آن مراجعه کرده و پیش از ApplyOrdering، متد جدید ApplyFiltering فوق را اضافه میکنیم:
var columnsMap = new Dictionary<string, Expression<Func<Product, object>>>() { ["productId"] = p => p.ProductId, ["productName"] = p => p.ProductName, ["isAvailable"] = p => p.IsAvailable, ["price"] = p => p.Price }; query = query.ApplyFiltering(queryModel, columnsMap); query = query.ApplyOrdering(queryModel, columnsMap);
کدهای کامل این تغییرات را از اینجا میتوانید دریافت کنید.
تهیه گزارش در Blazor Wasm با استیمول ریپورت
using Microsoft.AspNetCore.Mvc; namespace BlazorWasmShowBinaryFiles.Server.Controllers { [ApiController] [Route("api/[controller]")] public class ReportsController : ControllerBase { [HttpGet("[action]")] public IActionResult GetReportFile() { return File(virtualPath: "~/app_data/Report.mrt", contentType: "application/octet-stream", fileDownloadName: "Report.mrt"); } } }
با پیشرفت بیشتر تکنولوژی وب در سالهای اخیر و رشد کاربران فضای اینترنتی، خدمات و پیچیدگیهای بیشتری به نرم افزارها اضافه شده و به همین دلیل استفاده از میکروسرویسها بجای حالت قدیمی مونولوتیک (یک برنامه همه کاره) طرفداران بیشتری پیدا کردهاست. در این حالت برنامه به قسمتهای خرد و مجزایی تبدیل شده و هر پروژه ساختار و تکنولوژی مخصوص به خود را مدیریت میکند و در این بین با استفاده روشهای متفاوتی به ایجاد ارتباط با یکدیگر میپردازند .
مشکلی که در این حالت میتواند رخ دهد، زیاد شدن مسیرهای متفاوت برای اتصال به هر یک از سرویسها و سختتر شدن به روزرسانی این مسیرها میباشد. به همین دلیل در این بخش، نیاز به ابزاری میباشد تا بتوان از طریق آن، مسیردهی سادهای را ایجاد کرد و در پشت صحنه مسیردهیهای متفاوتی را کنترل نمود. با ایجاد چنین ابزاری در واقع شما API Gateway ایجاد نمودهاید. یکی از معروفترین کتابخانههای این حوزه، Ocelot میباشد. کار با این ابزار بسیار ساده بوده و امکانات بسیار زیاد و قدرتمندی را فراهم مینماید.
برای اینکار ابتدا سه پروژه را میسازیم که موارد زیر را شامل میگردد:
پروژه اول نوع Api : با دریافت Id در اکشنمتد مورد نظر، شیء user بازگردانده میشود:
public class User { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public string UserName { get; set; } public static List<User> GetUsers() { return new List<User>() { new() { Id = 1, FirstName = "علی", LastName = "یگانه مقدم", UserName = "yeganehaym" }, new () { Id = 2, FirstName = "وحید", LastName = "نصیری", UserName = "VahidN" }, }; } }
[ApiController] [Route("/api/[controller]/{id?}")] public class UserController : ControllerBase { [HttpGet] public User GetUser(int id) { var users = Users.User.GetUsers(); var user = users.FirstOrDefault(x => x.Id == id); return user; } }
پروژه دوم نوع Api : دریافت لیستی از محصولات:
public class Product { public int Id { get; set; } public string Name { get; set; } public int Price { get; set; } public int Quantity { get; set; } public static List<Product> GetProducts() { return new List<Product>() { new() { Id = 1, Name = "LCD", Price = 20000, Quantity = 10 }, new() { Id = 1, Name = "Mouse", Price = 320000, Quantity = 15 }, new() { Id = 1, Name = "Keyboard", Price = 50000, Quantity = 25 }, }; } }
[ApiController] [Route("api/[controller]")] public class ProductController : ControllerBase { [HttpGet] public List<Product> GetProducts() { return Product.GetProducts(); } }
پروژه سوم همان ApiGateway هست و همینکه یک پروژهی وب خالی باشد، کفایت میکند. در این پروژه Ocelot را نصب نموده و سپس فایلی با نام ocelot.json را با محتوای زیر به ریشهی پروژه همانند فایلهای appsettings.json اضافه میکنیم:
{ "Routes":[ { "DownstreamPathTemplate":"/api/User/{id}", "DownstreamScheme":"https", "DownstreamHostAndPorts":[ { "Host":"localhost", "Port":"7279" } ], "UpstreamPathTemplate":"/GetUser/{id}", "UpstreamHttpMethod":[ "GET" ]}, { "DownstreamPathTemplate":"/api/Product", "DownstreamScheme":"https", "DownstreamHostAndPorts":[ { "Host":"localhost", "Port":"7261" } ], "UpstreamPathTemplate":"/Products", "UpstreamHttpMethod":[ "GET" ] } ] }
این فایلها شامل دو قسمتUpStream و DownStream میشوند. آپاستریمها در واقع آدرسی است که شما قصد اتصال به آنرا دارید و قسمت داوناستریم، سرویس مقصدی است که ocelot باید درخواست شما را به سمت آن ارسال نماید. بهعنوان مثل شما با ارسال درخواستی به آدرس Products ، در پشت صحنه به آدرس localhost:7261/api/product ارسال میگردد. بدین صورت سیستم نهایی تنها به یک دامنه و آدرس منسجم ارسال شده، ولی در پشت صحنه این آدرسها ممکن است به تعداد زیادی سرویس در آدرسهای متفاوتی ارسال گردند.
جهت راه اندازی نهایی، کد زیر را به فایل Program.cs اضافه میکنیم:
builder.Services.AddOcelot();
app.UseOcelot();
پس از اضافه کردن پیکربندی و middleware آن، کد زیر را نیز جهت شناسایی فایل ocelot به فایل Program.cs نیز اضافه مینماییم:
builder.Configuration.SetBasePath(builder.Environment.ContentRootPath) .AddJsonFile("ocelot.json", optional: false, reloadOnChange: true);
همچنین
در صورت تمایل میتوانید کد را به شکل زیر هم نوشته تا بتوانید تنظیمات متفاوتی را برای محیط اجرایی متفاوتی ایجاد نمایید:
builder.Configuration.SetBasePath(builder.Environment.ContentRootPath) .AddJsonFile("ocelot.json", optional: false, reloadOnChange: true) .AddJsonFile($"ocelot.{builder.Environment.EnvironmentName}.json", optional: false, reloadOnChange: true);
هر
سه برنامه را با هم اجرا نمایید و با استفاده از برنامهی PostMan درخواستی را برای هر یک از موارد مورد نظر /Products و /GetUser/{1,2} به سمت پروژه ApiGateway
ارسال نمایید.
Ocelot موارد دیگری از قبیل تنظیم Load Balancer بین سرویس ها، اتصال به سرویسهای Service Discoveryچون Consul یا یوریکا و کش کردن و ... را نیز فراهم مینماید.
عملیات کشینگ
جهت بحث کشینگ، ابتدا بسته زیر را اضافه نمایید:
Install-Package Ocelot.Cache.CacheManager
سپس
پیکربندی ابتدایی را به شکل زیر تغییر دهید:
builder.Services.AddOcelot() .AddCacheManager(x => x.WithDictionaryHandle());
در ادامه در فایل Ocelot جیسون،
برای هر بخشی که مدنظر شماست تا کشی را انجام دهد، کد زیر اضافه نمایید:
"FileCacheOptions":{ "TtlSeconds":30, "Region":"custom" }
TtlSeconds : مدت
زمان کش به ثانیه
Region : یک عبارت رشتهای همانند یک عنوان یا نام که بعدا میتوانید از طریق api ها به آن متصل شوید و عملیاتی چون خالی کردن کش را صادر نمایید.
حال برای بخش محصولات این تنظیمات ذکر میگردد:
{ "Routes":[ { "DownstreamPathTemplate":"/api/User/{id}", "DownstreamScheme":"https", "DownstreamHostAndPorts":[ { "Host":"localhost", "Port":"7279" } ], "UpstreamPathTemplate":"/GetUser/{id}", "UpstreamHttpMethod":[ "GET" ] }, { "DownstreamPathTemplate":"/api/Product", "DownstreamScheme":"https", "DownstreamHostAndPorts":[ { "Host":"localhost", "Port":"7261" } ], "UpstreamPathTemplate":"/Products", "UpstreamHttpMethod":[ "GET" ], "FileCacheOptions":{ "TtlSeconds":30, "Region":"custom" } } ] }
برای اینکه متوجه عملکرد آن شوید یک نقطه توقف را در اکشن دریافت محصول قرار دهید و سپس برنامه را در حالت دیباگ اجرا نمایید. در مرتبه اول باید نقطه توقف بتواند اجرای کد را به شما نمایش دهد ولی تا 30 ثانیه آینده هر چقدر از طریق Postman درخواستی را ارسال نمایید نقطه توقف اجرا نخواهد گردید، ولی نتیجهی قبل برای شما ارسال خواهد شد.
این مورد را برای بخش کاربران هم انجام دهید و میبینید که برای هر userId و هر شکل Url، یک پاسخ منحصر به فرد، دریافت و کش خواهد شد.
جلوگیری از درخواستهای بیش از حد
یکی دیگر از ویژگیهای Ocelot، جلوگیری از درخواست بیش از حد میباشد. به همین علت ابتدا کد زیر را به هر درخواستی که مدنظر شماست اضافه نمایید:
"RateLimitOptions":{ "ClientWhitelist":[ ], "EnableRateLimiting":true, "Period":"5s", "PeriodTimespan":1, "Limit":1, "HttpStatusCode":429 }
WhiteClients : برای مشخص کردن کلاینتهایی که نباید اعمال محدودیت روی آنها صورت بگیرد.
EnableRateLimiting : این مورد باعث فعالسازی آن میگردد.
Period: مدت زمانیکه حداکثر تعداد درخواست باید در آن بازه صورت بگیرد. به ترتیب برای ثانیه، دقیقه، ساعت و روز حروف s - m - h و d استفاده میگردد.
PeriodTimespan: بعد از محدود شدن، بعد از چه مدتی دوباره بتواند درخواستی را ارسال نماید. در اینجا بعد از محدودیت ارسال درخواست، بعد از یک ثانیه مجدد اجازه ارسال درخواست باز میگردد.
Limit: در بازه زمانی مشخص شده چند درخواست مورد قبول واقع میشود و بعد از آن دیگر اجازه ارسال درخواست را نخواهد داشت.
HttpStatusCode: در صورت فیلتر شدن درخواستهای رسیده، چه کد وضعیتی باید برگردانده شود که عدد 429 به معنای Too Many Request میباشد.
با تنظیمات بالا هر کلاینت میتواند در 5 ثانیه، نهایتا یک درخواست را ارسال نماید و با ارسال بقیه درخواستها، Ocelot بجای هدایت درخواست به سرویس مربوطه، کد وضعیت 429 را باز میگرداند و یک ثانیه بعد از گذشت 5 ثانیه میتواند مجددا درخواست خود را ارسال نماید.
در نهایت به یک فایل مشابه زیر میرسیم:
{ "Routes":[ { "DownstreamPathTemplate":"/api/User/{id}", "DownstreamScheme":"https", "DownstreamHostAndPorts":[ { "Host":"localhost", "Port":"7279" } ], "UpstreamPathTemplate":"/GetUser/{id}", "UpstreamHttpMethod":[ "GET" ], "FileCacheOptions":{ "TtlSeconds":30, "Region":"custom" } }, { "DownstreamPathTemplate":"/api/Product", "DownstreamScheme":"https", "DownstreamHostAndPorts":[ { "Host":"localhost", "Port":"7261" } ], "UpstreamPathTemplate":"/Products", "UpstreamHttpMethod":[ "GET" ], "RateLimitOptions":{ "ClientWhitelist":[ ], "EnableRateLimiting":true, "Period":"5s", "PeriodTimespan":1, "Limit":1, "HttpStatusCode":429 } } ], "DangerousAcceptAnyServerCertificateValidator": true }
برای تست آن با استفاد از PostMan مرتبا به آدرس Products/ درخواست ارسال نمایید.
فایل پروژه : Ocelot.zip
دریافت افزونهی jsTree
برای دریافت افزونهی jsTree میتوان به مخزن کد آن در Github مراجعه کرد و همچنین مستندات آنرا در سایت jstree.com قابل مطالعه هستند.
تنظیمات مقدماتی jsTree
در این مطلب فرض شدهاست که فایل jstree.min.js، در پوشهی Scripts و فایلهای CSS آن در پوشهی Content\themes\default کپی شدهاند.
به این ترتیب layout برنامه چنین شکلی را خواهد یافت:
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width" /> <title>@ViewBag.Title</title> <link href="~/Content/Site.css" rel="stylesheet" /> <link href="~/Content/themes/default/style.min.css" rel="stylesheet" /> <script src="~/Scripts/jquery.min.js"></script> <script src="~/Scripts/jstree.min.js"></script> </head> <body dir="rtl"> @RenderBody() @RenderSection("scripts", required: false) </body> </html>
نمایش راست به چپ اطلاعات
در کدهای این افزونه به تگ body و ویژگی dir آن برای تشخیص راست به چپ بودن محیط دقت میشود. به همین جهت این تعریف را در layout فوق ملاحظه میکنید. برای مثال اگر به فایل jstree.contextmenu.js (موجود در مجموعه سورسهای این افزونه) مراجعه کنید، یک چنین تعریفی قابل مشاهده است:
right_to_left = $("body").css("direction") === "rtl";
تهیه ساختاری جهت ارائهی خروجی JSON
با توجه به اینکه قصد داریم به صورت پویا با این افزونه کار کنیم، نیاز است بتوانیم ساختار سلسله مراتبی مدنظر را با فرمت JSON ارائه دهیم. در ادامه کلاسهایی که معادل فرمت JSON قابل قبول توسط این افزونه را تولید میکنند، ملاحظه میکنید:
using System.Collections.Generic; namespace MvcJSTree.Models { public class JsTreeNode { public string id { set; get; } // نام این خواص باید با مستندات هماهنگ باشد public string text { set; get; } public string icon { set; get; } public JsTreeNodeState state { set; get; } public List<JsTreeNode> children { set; get; } public JsTreeNodeLiAttributes li_attr { set; get; } public JsTreeNodeAAttributes a_attr { set; get; } public JsTreeNode() { state = new JsTreeNodeState(); children = new List<JsTreeNode>(); li_attr = new JsTreeNodeLiAttributes(); a_attr = new JsTreeNodeAAttributes(); } } public class JsTreeNodeAAttributes { // به هر تعداد و نام اختیاری میتوان خاصیت تعریف کرد public string href { set; get; } } public class JsTreeNodeLiAttributes { // به هر تعداد و نام اختیاری میتوان خاصیت تعریف کرد public string data { set; get; } } public class JsTreeNodeState { public bool opened { set; get; } public bool disabled { set; get; } public bool selected { set; get; } public JsTreeNodeState() { opened = true; } } }
- هر چند اسامی مانند a_attr، مطابق اصول نامگذاری دات نت نیستند، ولی این نامها را تغییر ندهید. زیرا این افزونه دقیقا به همین نامها و با همین املاء نیاز دارد.
- id، میتواند دقیقا معادل id یک رکورد در بانک اطلاعاتی باشد. Text عنوان گرهای (node) است که نمایش داده میشود. icon در اینجا مسیر یک فایل png است جهت نمایش در کنار عنوان هر گره. توسط state میتوان مشخص کرد که زیر شاخهی جاری به صورت باز نمایش داده شود یا بسته. به کمک خاصیت children میتوان زیر شاخهها را تا هر سطح و تعدادی که نیاز است تعریف نمود.
- خاصیتهای li_attr و a_attr کاملا دلخواه هستند. برای مثال در اینجا دو خاصیت href و data را در کلاسهای مرتبط با آنها مشاهده میکنید. میتوانید در اینجا به هر تعداد ویژگی سفارشی دیگری که جهت تعریف یک گره نیاز است، خاصیت اضافه کنید.
سادهترین مثالی که از ساختار فوق میتواند استفاده کند، اکشن متد زیر است:
[HttpPost] public ActionResult GetTreeJson() { var nodesList = new List<JsTreeNode>(); var rootNode = new JsTreeNode { id = "dir", text = "Root 1", icon = Url.Content("~/Content/images/tree_icon.png"), a_attr = { href = "http://www.bing.com" } }; nodesList.Add(rootNode); nodesList.Add(new JsTreeNode { id = "test1", text = "Root 2", icon = Url.Content("~/Content/images/tree_icon.png"), a_attr = { href = "http://www.bing.com" } }); return Json(nodesList, JsonRequestBehavior.AllowGet); }
بنابراین ساختارهای خود ارجاع دهنده را به خوبی میتوان با این افزونه وفق داد.
فعال سازی اولیه سمت کلاینت افزونه jsTree
برای استفادهی پویای از این افزونه در سمت کلاینت، فقط نیاز به یک DIV خالی است:
<div id="jstree"> </div>
$('#jstree').jstree({ "core": { "multiple": false, "check_callback": true, 'data': { 'url': '@getTreeJsonUrl', "type": "POST", "dataType": "json", "contentType": "application/json; charset=utf8", 'data': function (node) { return { 'id': node.id }; } }, 'themes': { 'variant': 'small', 'stripes': true } }, "types": { "default": { "icon": '@Url.Content("~/Content/images/bookmark_book_open.png")' }, }, "plugins": ["contextmenu", "dnd", "state", "types", "wholerow", "sort", "unique"], "contextmenu": { "items": function (o, cb) { var items = $.jstree.defaults.contextmenu.items(); items["create"].label = "ایجاد زیر شاخه"; items["rename"].label = "تغییر نام"; items["remove"].label = "حذف"; var cpp = items["ccp"]; cpp.label = "ویرایش"; var subMenu = cpp["submenu"]; subMenu["copy"].label = "کپی"; subMenu["paste"].label = "پیست"; subMenu["cut"].label = "برش"; return items; } } });
- multiple : false به این معنا است که نمیخواهیم کاربر بتواند چندین گره را با نگه داشتن دکمهی کنترل انتخاب کند.
- check_callback : true کدهای مرتبط با منوی کلیک سمت راست ماوس را فعال میکند.
- در قسمت data کار تبادل اطلاعات با سرور جهت دریافت فرمت JSON ایی که به آن اشاره شد، انجام میشود. متغیر getTreeJsonUrl یک چنین شکلی را میتواند داشته باشد:
@{ ViewBag.Title = "Demo"; var getTreeJsonUrl = Url.Action(actionName: "GetTreeJson", controllerName: "Home"); }
- در قسمت types که مرتبط است با افزونهای به همین نام، آیکن پیش فرض یک نود جدید ایجاد شده را مشخص کردهایم.
- گزینهی plugins، لیست افزونههای اختیاری این افزونه را مشخص میکند. برای مثال contextmenu منوی کلیک سمت راست ماوس را فعال میکند، dnd همان کشیدن و رها کردن گرهها است در زیر شاخههای مختلف. افزونهی state، انتخاب جاری کاربر را در سمت کلاینت ذخیره و در مراجعهی بعدی او بازیابی میکند. با ذکر افزونهی wholerow سبب میشویم که انتخاب یک گره، معادل انتخاب یک ردیف کامل از صفحه باشد. افزونهی sort کار مرتب سازی خودکار اعضای یک زیر شاخه را انجام میدهد. افزونهی unique سبب میشود تا در یک زیر شاخه نتوان دو عنوان یکسان را تعریف کرد.
- در قسمت contextmenu نحوهی بومی سازی گزینههای منوی کلیک راست ماوس را مشاهده میکنید. در حالت پیش فرض، عناوینی مانند create، rename و امثال آن نمایش داده میشوند که به نحو فوق میتوان آنرا تغییر داد.
با همین حد تنظیم، این افزونه کار نمایش سلسله مراتبی اطلاعات JSON ایی دریافت شده از سرور را انجام میدهد.
ذخیره سازی گرههای جدید و تغییرات سلسله مراتب پویای تعریف شده در سمت سرور
همانطور که عنوان شد، اگر افزونهی اختیاری contextmenu را فعال کنیم، امکان افزودن، ویرایش و حذف گرهها و زیر شاخهها را خواهیم یافت. برای انتقال این تغییرات به سمت سرور، باید به نحو ذیل عمل کرد:
$('#jstree').jstree({ // تمام تنظیمات مانند قبل }).on('delete_node.jstree', function (e, data) { }) .on('create_node.jstree', function (e, data) { }) .on('rename_node.jstree', function (e, data) { }) .on('move_node.jstree', function (e, data) { }) .on('copy_node.jstree', function (e, data) { }) .on('changed.jstree', function (e, data) { }) .on('dblclick.jstree', function (e) { }) .on('select_node.jstree', function (e, data) { });
در تمام این حالات، جایی که data در اختیار ما است، میتوان یک چنین ساختار جاوا اسکریپتی را برای ارسال به سرور طراحی کرد:
function postJsTreeOperation(operation, data, onDone, onFail) { $.post('@doJsTreeOperationUrl', { 'operation': operation, 'id': data.node.id, 'parentId': data.node.parent, 'position': data.position, 'text': data.node.text, 'originalId': data.original ? data.original.id : data.node.original.id, 'href': data.node.a_attr.href }) .done(function (result) { onDone(result); }) .fail(function (result) { alert('failed.....'); onFail(result); }); }
.on('create_node.jstree', function (e, data) { postJsTreeOperation('CreateNode', data, function (result) { data.instance.set_id(data.node, result.id); }, function (result) { data.instance.refresh(); }); })
و معادل سمت سرور دریافت کنندهی این اطلاعات، اکشن متد ذیل میتواند باشد:
[HttpPost] public ActionResult DoJsTreeOperation(JsTreeOperationData data) { switch (data.Operation) { case JsTreeOperation.CopyNode: case JsTreeOperation.CreateNode: //todo: save data var rnd = new Random(); // آی دی رکورد پس از ثبت در بانک اطلاعاتی دریافت و بازگشت داده شود return Json(new { id = rnd.Next() }, JsonRequestBehavior.AllowGet); case JsTreeOperation.DeleteNode: //todo: save data return Json(new { result = "ok" }, JsonRequestBehavior.AllowGet); case JsTreeOperation.MoveNode: //todo: save data return Json(new { result = "ok" }, JsonRequestBehavior.AllowGet); case JsTreeOperation.RenameNode: //todo: save data return Json(new { result = "ok" }, JsonRequestBehavior.AllowGet); default: throw new InvalidOperationException(string.Format("{0} is not supported.", data.Operation)); } }
namespace MvcJSTree.Models { public enum JsTreeOperation { DeleteNode, CreateNode, RenameNode, MoveNode, CopyNode } public class JsTreeOperationData { public JsTreeOperation Operation { set; get; } public string Id { set; get; } public string ParentId { set; get; } public string OriginalId { set; get; } public string Text { set; get; } public string Position { set; get; } public string Href { set; get; } } }
در اینجا Href را نیز مشاهده میکنید. همانطور که عنوان شد، اعضای JsTreeNodeAAttributes اختیاری هستند. بنابراین اگر این اعضاء را تغییر دادید، باید خواص JsTreeOperationData و همچنین اعضای شیء تعریف شده در postJsTreeOperation را نیز تغییر دهید تا با هم تطابق پیدا کنند.
چند نکتهی تکمیلی
اگر میخواهید که با دوبار کلیک بر روی یک گره، کاربر به href آن هدایت شود، میتوان از کد ذیل استفاده کرد:
var selectedData; // ... .on('dblclick.jstree', function (e) { var href = selectedData.node.a_attr.href; alert('selected node: ' + selectedData.node.text + ', href:' + href); // auto redirect if (href) { window.location = href; } // activate edit mode //var inst = $.jstree.reference(selectedData.node); //inst.edit(selectedData.node); }) .on('select_node.jstree', function (e, data) { //alert('selected node: ' + data.node.text); selectedData = data; });
حتی اگر خواستید که با دوبار کلیک بر روی یک گره، گزینهی ویرایش آن فعال شود، کدهای آن را به صورت کامنت مشاهده میکنید.
مثال کامل این بحث را از اینجا میتوانید دریافت کنید:
MvcJSTree.zip
این تصویر را پیشتر در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 6 - سرویسها و تزریق وابستگیها» مشاهده کردهاید. در اینجا لیست سرویسهایی را مشاهده میکنید که به صورت پیش فرض، ثبت شدهاند و فعال هستند و ILogger و ILoggerFactory نیز جزئی از آنها هستند. بنابراین نیازی به فعال سازی آنها نیست؛ اما برای استفادهی از آنها نیاز به انجام یک سری تنظیمات است.
پیاده سازی ثبت وقایع در ASP.NET Core
اولین قدم کار با فریم ورک ثبت وقایع ASP.NET Core، معرفی ILoggerFactory به متد Configure کلاس آغازین برنامه است:
public void Configure(ILoggerFactory loggerFactory, IApplicationBuilder app, IHostingEnvironment env) { loggerFactory.AddConsole(Configuration.GetSection("Logging")); loggerFactory.AddDebug();
سطر اول متد، تنظیمات ثبت وقایع را از خاصیت Logging فایل appsettings.json برنامه میخواند (در مورد خاصیت Configuration، در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 7 - کار با فایلهای config» بیشتر بحث شد) و لاگ کردن ویژهی در کنسول NET Core. را فعال میکند:
{ "Logging": { "IncludeScopes": false, "LogLevel": { "Default": "Debug", "System": "Information", "Microsoft": "Information" } } }
و سطر دوم سبب نمایش اطلاعات لاگ شده در کنسول دیباگ ویژوال استودیو میشود.
متد AddDebug برای شناسایی، نیاز به افزودن وابستگیهای ذیل در فایل project.json برنامه را دارد:
{ "dependencies": { //same as before "Microsoft.Extensions.Logging": "1.0.0", "Microsoft.Extensions.Logging.Console": "1.0.0", "Microsoft.Extensions.Logging.Debug": "1.0.0" } }
در اینجا میتوانید ریز وقایعی را که توسط ASP.NET Core لاگ شدهاست، مشاهده کنید. برای مثال چه درخواستی صورت گرفتهاست و چقدر اجرای آن زمانبردهاست.
این فعال سازی مرتبط است به متد AddDebug که اضافه شد. اگر میخواهید خروجی AddConsole را هم مشاهده کنید، از طریق خط فرمان، به پوشهی اصلی پروژه وارد شده و سپس دستور dotnet run را اجرا کنید:
دستور dotnet run سبب راه اندازی وب سرور برنامه بر روی پورت 5000 شدهاست که در تصویر نیز مشخص است.
بنابراین اینبار برای دسترسی به برنامه باید مسیر http://localhost:5000 را در مرورگر خود طی کنید. در اینجا نیز میتوان حالتهای مختلف اطلاعات لاگ شده را مشاهده کرد و تمام اینها مرتبط هستند به ذکر متد AddConsole .
کار با سرویس ثبت وقایع ASP.NET Core از طریق تزریق وابستگیها
برای کار با سرویس ثبت وقایع توکار ASP.NET Core در قسمتهای مختلف برنامه، میتوان از ترزیق وابستگی ILogger آن استفاده کرد:
[Route("[controller]")] public class AboutController : Controller { private readonly ILogger<AboutController> _logger; public AboutController(ILogger<AboutController> logger) { _logger = logger; } [Route("")] public ActionResult Hello() { _logger.LogInformation("Running Hello"); return Content("Hello from DNT!"); }
سپس با توجه به اینکه این سرویس جزو سرویسهای از پیش ثبت شدهی ASP.NET Core است، امکانات آن بدون نیاز به تنظیمات بیشتری در دسترس است. برای مثال از متد LogInformation آن در اکشن متد Hello استفاده شدهاست و خروجی عبارت لاگ شدهی آنرا در اینجا میتوانید مشاهده کنید:
سطوح مختلف ثبت وقایع
اینترفیس ILogger به همراه متدهای مختلفی است؛ مانند LogError، LogDebug و غیره. معانی آنها به شرح زیر هستند:
Debug (1): ثبت واقعهای است با بیشترین حد جزئیات ممکن که عموما شامل اطلاعات حساسی نیز میباشد. بنابراین نباید در حالت ارائهی نهایی برنامه فعال شود.
(2) Verbose: ثبت وقایعی مفصل، جهت بررسی مشکلات در حین توسعهی برنامه. تنها باید حاوی اطلاعاتی برای دیباگ برنامه باشند.
(3) Information: عموما برای ردیابی قسمتهای مختلف برنامه مورد استفاده قرار میگیرند.
(4) Warning: جهت ثبت واقعهای نامطلوب در سیستم بکار میرود و سبب قطع اجرای برنامه نمیشود.
(5) Errors: مشکلات برنامه را که سبب قطع سرویس دهی آن شدهاند را ثبت میکند. هدف آن ثبت مشکلات واحد جاری است و نه کل برنامه.
Critical (6): هدف آن ثبت مشکلات بحرانی کل سیستم است که سبب از کار افتادن آن شدهاند.
برای مثال در حین تنظیم متد AddDebug که سبب نمایش اطلاعات لاگ شده در کنسول دیباگ ویژوال استودیو میشود، میتوان حداقل سطح ثبت وقایع را نیز ذکر کرد:
loggerFactory.AddDebug(minLevel: LogLevel.Information);
البته ترتیب واقعی این سطوح را در enum مرتبط با آنها بهتر میتوان مشاهده کرد:
public enum LogLevel { Trace, Debug, Information, Warning, Error, Critical, None, }
یک نکته: زمانیکه متد AddDebug را بدون پارامتر فراخوانی میکنید، حداقل سطح ثبت وقایع آن به Information تنظیم شدهاست. یعنی در این لاگ، خبری از اطلاعات Debug نخواهد بود (چون سطح دیباگ پایینتر است از Information). بنابراین اگر میخواهید این اطلاعات را هم مشاهده کنید باید پارامتر minLevel آنرا به LogLevel.Debug تنظیم نمائید.
امکان استفادهی از پروایدرهای ثبت وقایع ثالث
تا اینجا، دو نمونه از پروایدرهای توکار ثبت وقایع ASP.NET Core را بررسی کردیم. اگر نیاز به ثبت این اطلاعات با فرمتهای مختلف و یا در بانک اطلاعاتی وجود دارد، میتوان به تامین کنندههای ثالثی که قابلیت کار با ILoggerFactory را دارند نیز مراجعه کرد. برای مثال:
- elmah.io - provider for the elmah.io service
- Loggr - provider for the Loggr service
- NLog - provider for the NLog library
- Serilog - provider for the Serilog library
بررسی اجزای Hybrid Flow
در قسمت سوم در حین «انتخاب OpenID Connect Flow مناسب برای یک برنامهی کلاینت از نوع ASP.NET Core» به این نتیجه رسیدیم که Flow مناسب یک برنامهی Mvc Client از نوع Hybrid است. در اینجا هر Flow، شروع به ارسال درخواستی به سمت Authorization Endpoint میکند؛ با یک چنین قالبی:
https://idpHostAddress/connect/authorize? client_id=imagegalleryclient &redirect_uri=https://clientapphostaddress/signin-oidcoidc &scope=openid profile &response_type=code id_token &response_mode=form_post &nonce=63626...n2eNMxA0
- سپس client_id جهت تعیین برنامهای که درخواست را ارسال میکند، ذکر شدهاست؛ از این جهت که یک IDP جهت کار با چندین نوع کلاینت مختلف طراحی شدهاست.
- redirect_uri همان Redirect Endpoint است که در سطح برنامهی کلاینت تنظیم میشود.
- در مورد scope در قسمت قبل در حین راه اندازی IdentityServer توضیح دادیم. در اینجا برنامهی کلاینت، درخواست scopeهای openid و profile را دادهاست. به این معنا که نیاز دارد تا Id کاربر وارد شدهی به سیستم و همچنین Claims منتسب به او را در اختیار داشته باشد.
- response_type نیز به code id_token تنظیم شدهاست. توسط response_type، نوع Flow مورد استفاده مشخص میشود. ذکر code به معنای بکارگیری Authorization code flow است. ذکر id_token و یا id_token token هر دو به معنای استفادهی از implicit flow است. اما برای مشخص سازی Hybrid flow یکی از سه مقدار code id_token و یا code token و یا code id_token token با هم ذکر میشوند:
- در اینجا response_mode مشخص میکند که اطلاعات بازگشتی از سمت IDP که توسط response_type مشخص شدهاند، با چه قالبی به سمت کلاینت بازگشت داده شوند که میتواند از طریق Form POST و یا URI باشد.
در Hybrid flow با response_type از نوع code id_token، ابتدا کلاینت یک درخواست Authentication را به Authorization Endpoint ارسال میکند (با همان قالب URL فوق). سپس در سطح IDP، کاربر برای مثال با ارائهی کلمهی عبور و نام کاربری، تعیین اعتبار میشود. همچنین در اینجا IDP ممکن است رضایت کاربر را از دسترسی به اطلاعات پروفایل او نیز سؤال بپرسد (تحت عنوان مفهوم Consent). سپس IDP توسط یک Redirection و یا Form POST، اطلاعات authorization code و identity token را به سمت برنامهی کلاینت ارسال میکند. این همان اطلاعات مرتبط با response_type ای است که درخواست کردهایم. سپس برنامهی کلاینت این اطلاعات را تعیین اعتبار کرده و در صورت موفقیت آمیز بودن این عملیات، اکنون درخواست تولید توکن هویت را به token endpoint ارسال میکند. برای این منظور کلاینت سه مشخصهی authorization code ،client-id و client-secret را به سمت token endpoint ارسال میکند. در پاسخ یک identity token را دریافت میکنیم. در اینجا مجددا این توکن تعیین اعتبار شده و سپس Id کاربر را از آن استخراج میکند که در برنامهی کلاینت قابل استفاده خواهد بود. این مراحل را در تصویر زیر میتوانید ملاحظه کنید.
البته اگر دقت کرده باشید، یک identity token در همان ابتدای کار از Authorization Endpoint دریافت میشود. اما چرا از آن استفاده نمیکنیم؟ علت اینجا است که token endpoint نیاز به اعتبارسنجی client را نیز دارد. به این ترتیب یک لایهی امنیتی دیگر نیز در اینجا بکار گرفته میشود. همچنین access token و refresh token نیز از همین token endpoint قابل دریافت هستند.
تنظیم IdentityServer جهت انجام عملیات ورود به سیستم بر اساس جزئیات Hybrid Flow
برای افزودن قسمت لاگین به برنامهی MVC قسمت دوم، نیاز است تغییراتی را در برنامهی کلاینت و همچنین IDP اعمال کنیم. برای این منظور کلاس Config پروژهی IDP را که در قسمت قبل ایجاد کردیم، به صورت زیر تکمیل میکنیم:
namespace DNT.IDP { public static class Config { public static IEnumerable<Client> GetClients() { return new List<Client> { new Client { ClientName = "Image Gallery", ClientId = "imagegalleryclient", AllowedGrantTypes = GrantTypes.Hybrid, RedirectUris = new List<string> { "https://localhost:5001/signin-oidc" }, PostLogoutRedirectUris = new List<string> { "https://localhost:5001/signout-callback-oidc" }, AllowedScopes = { IdentityServerConstants.StandardScopes.OpenId, IdentityServerConstants.StandardScopes.Profile }, ClientSecrets = { new Secret("secret".Sha256()) } } }; } } }
- ابتدا نام کلاینت را مشخص میکنیم. این نام و عنوان، در صفحهی لاگین و Consent (رضایت دسترسی به اطلاعات پروفایل کاربر)، ظاهر میشود.
- همچنین نیاز است یک Id دلخواه را نیز برای آن مشخص کنیم؛ مانند imagegalleryclient در اینجا.
- AllowedGrantTypes را نیز به Hybrid Flow تنظیم کردهایم. علت آنرا در قسمت سوم این سری بررسی کردیم.
- با توجه به اینکه Hybrid Flow از Redirectها استفاده میکند و اطلاعات نهایی را به کلاینت از طریق Redirection ارسال میکند، به همین جهت آدرس RedirectUris را به آدرس برنامهی Mvc Client تنظیم کردهایم (که در اینجا بر روی پورت 5001 کار میکند). قسمت signin-oidc آنرا در ادامه تکمیل خواهیم کرد.
- در قسمت AllowedScopes، لیست scopeهای مجاز قابل دسترسی توسط این کلاینت مشخص شدهاند که شامل دسترسی به ID کاربر و Claims آن است.
- به ClientSecrets نیز جهت client authenticating نیاز داریم.
تنظیم برنامهی MVC Client جهت انجام عملیات ورود به سیستم بر اساس جزئیات Hybrid Flow
برای افزودن قسمت لاگین به سیستم، کلاس آغازین پروژهی MVC Client را به نحو زیر تکمیل میکنیم:
namespace ImageGallery.MvcClient.WebApp { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddAuthentication(options => { options.DefaultScheme = "Cookies"; options.DefaultChallengeScheme = "oidc"; }).AddCookie("Cookies") .AddOpenIdConnect("oidc", options => { options.SignInScheme = "Cookies"; options.Authority = "https://localhost:6001"; options.ClientId = "imagegalleryclient"; options.ResponseType = "code id_token"; //options.CallbackPath = new PathString("...") //options.SignedOutCallbackPath = new PathString("...") options.Scope.Add("openid"); options.Scope.Add("profile"); options.SaveTokens = true; options.ClientSecret = "secret"; options.GetClaimsFromUserInfoEndpoint = true; });
- ابتدا با فراخوانی AddAuthentication، کار تنظیمات میانافزار استاندارد Authentication برنامههای ASP.NET Core انجام میشود. در اینجا DefaultScheme آن به Cookies تنظیم شدهاست تا عملیات Sign-in و Sign-out سمت کلاینت را میسر کند. سپس DefaultChallengeScheme به oidc تنظیم شدهاست. این مقدار با Scheme ای که در ادامه آنرا تنظیم خواهیم کرد، تطابق دارد.
- سپس متد AddCookie فراخوانی شدهاست که authentication-Scheme را به عنوان پارامتر قبول میکند. به این ترتیب cookie based authentication در برنامه میسر میشود. پس از اعتبارسنجی توکن هویت دریافتی و تبدیل آن به Claims Identity، در یک کوکی رمزنگاری شده برای استفادههای بعدی ذخیره میشود.
- در آخر تنظیمات پروتکل OpenID Connect را ملاحظه میکنید. به این ترتیب مراحل اعتبارسنجی توسط این پروتکل در اینجا که Hybrid flow است، پشتیبانی خواهد شد. اینجا است که کار درخواست Authorization، دریافت و اعتبارسنجی توکن هویت صورت میگیرد. اولین پارامتر آن authentication-Scheme است که به oidc تنظیم شدهاست. به این ترتیب اگر قسمتی از برنامه نیاز به Authentication داشته باشد، OpenID Connect به صورت پیشفرض مورد استفاده قرار میگیرد. به همین جهت DefaultChallengeScheme را نیز به oidc تنظیم کردیم. در اینجا SignInScheme به Cookies تنظیم شدهاست که با DefaultScheme اعتبارسنجی تطابق دارد. به این ترتیب نتیجهی موفقیت آمیز عملیات اعتبارسنجی در یک کوکی رمزنگاری شده ذخیره خواهد شد. مقدار خاصیت Authority به آدرس IDP تنظیم میشود که بر روی پورت 6001 قرار دارد. تنظیم این مسیر سبب خواهد شد تا این میانافزار سمت کلاینت، به discovery endpoint دسترسی یافته و بتواند مقادیر سایر endpoints برنامهی IDP را به صورت خودکار دریافت و استفاده کند. سپس ClientId تنظیم شدهاست که باید با مقدار تنظیم شدهی آن در سمت IDP یکی باشد و همچنین مقدار ClientSecret در اینجا نیز باید با ClientSecrets سمت IDP یکی باشد. ResponseType تنظیم شدهی در اینجا با AllowedGrantTypes سمت IDP تطابق دارد که از نوع Hybrid است. سپس دو scope درخواستی توسط این برنامهی کلاینت که openid و profile هستند در اینجا اضافه شدهاند. به این ترتیب میتوان به مقادیر Id کاربر و claims او دسترسی داشت. مقدار CallbackPath در اینجا به RedirectUris سمت IDP اشاره میکند که مقدار پیشفرض آن همان signin-oidc است. با تنظیم SaveTokens به true امکان استفادهی مجدد از آنها را میسر میکند.
پس از تکمیل قسمت ConfigureServices و انجام تنظیمات میانافزار اعتبارسنجی، نیاز است این میانافزار را نیز به برنامه افزود که توسط متد UseAuthentication انجام میشود:
namespace ImageGallery.MvcClient.WebApp { public class Startup { public void Configure(IApplicationBuilder app, IHostingEnvironment env) { app.UseAuthentication();
پس از این تنظیمات، با اعمال ویژگی Authorize، دسترسی به کنترلر گالری برنامهی MVC Client را صرفا محدود به کاربران وارد شدهی به سیستم میکنیم:
namespace ImageGallery.MvcClient.WebApp.Controllers { [Authorize] public class GalleryController : Controller { // .... public async Task WriteOutIdentityInformation() { var identityToken = await HttpContext.GetTokenAsync(OpenIdConnectParameterNames.IdToken); Debug.WriteLine($"Identity token: {identityToken}"); foreach (var claim in User.Claims) { Debug.WriteLine($"Claim type: {claim.Type} - Claim value: {claim.Value}"); } }
فراخوانی متد GetTokenAsync با پارامتر IdToken، همان Identity token دریافتی از IDP را بازگشت میدهد. این توکن با تنظیم SaveTokens به true در تنظیمات AddOpenIdConnect که پیشتر انجام دادیم، قابل استخراج از کوکی اعتبارسنجی برنامه شدهاست.
این متد را در ابتدای اکشن متد Index فراخوانی میکنیم:
public async Task<IActionResult> Index() { await WriteOutIdentityInformation(); // ....
اجرای برنامه جهت آزمایش تنظیمات انجام شده
برای اجرای برنامه:
- ابتدا به پوشهی src\WebApi\ImageGallery.WebApi.WebApp وارد شده و dotnet_run.bat آنرا اجرا کنید تا WebAPI برنامه راه اندازی شود.
- سپس به پوشهی src\IDP\DNT.IDP مراجعه کرده و و dotnet_run.bat آنرا اجرا کنید تا برنامهی IDP راه اندازی شود.
- در آخر به پوشهی src\MvcClient\ImageGallery.MvcClient.WebApp وارد شده و dotnet_run.bat آنرا اجرا کنید تا MVC Client راه اندازی شود.
اکنون که هر سه برنامه با هم در حال اجرا هستند، مرورگر را گشوده و مسیر https://localhost:5001 را درخواست کنید:
در این حالت چون فیلتر Authorize به کل اکشن متدهای کنترلر گالری اعمال شده، میانافزار Authentication که در فایل آغازین برنامهی کلاینت MVC تنظیم شدهاست، وارد عمل شده و کاربر را به صفحهی لاگین سمت IDP هدایت میکند (شماره پورت آن 6001 است). لاگ این اعمال را هم در برگهی network مرورگر میتواند مشاهده کنید.
در اینجا نام کاربری و کلمهی عبور اولین کاربر تعریف شدهی در فایل Config.cs برنامهی IDP را که User 1 و password است، وارد میکنیم. پس از آن صفحهی Consent ظاهر میشود:
در اینجا از کاربر سؤال میپرسد که آیا به برنامهی کلاینت اجازه میدهید تا به Id و اطلاعات پروفایل و یا همان Claims شما دسترسی پیدا کند؟
فعلا گزینهی remember my design را انتخاب نکنید تا همواره بتوان این صفحه را در دفعات بعدی نیز مشاهده کرد. سپس بر روی گزینهی Yes, Allow کلیک کنید.
اکنون به صورت خودکار به سمت برنامهی MVC Client هدایت شده و میتوانیم اطلاعات صفحهی اول سایت را کاملا مشاهده کنیم (چون کاربر اعتبارسنجی شدهاست، از فیلتر Authorize رد خواهد شد).
همچنین در اینجا اطلاعات زیادی نیز جهت دیباگ برنامه لاگ میشوند که در آینده جهت عیب یابی آن میتوانند بسیار مفید باشند:
با دنبال کردن این لاگ میتوانید مراحل Hybrid Flow را مرحله به مرحله با مشاهدهی ریز جزئیات آن بررسی کنید. این مراحل به صورت خودکار توسط میانافزار Authentication انجام میشوند و در نهایت اطلاعات توکنهای دریافتی به صورت خودکار در اختیار برنامه برای استفاده قرار میگیرند. یعنی هم اکنون کوکی رمزنگاری شدهی اطلاعات اعتبارسنجی کاربر در دسترس است و به اطلاعات آن میتوان توسط شیء this.User، در اکشن متدهای برنامهی MVC، دسترسی داشت.
تنظیم برنامهی MVC Client جهت انجام عملیات خروج از سیستم
ابتدا نیاز است یک لینک خروج از سیستم را به برنامهی کلاینت اضافه کنیم. برای این منظور به فایل Views\Shared\_Layout.cshtml مراجعه کرده و لینک logout را در صورت IsAuthenticated بودن کاربر جاری وارد شدهی به سیستم، نمایش میدهیم:
<div class="navbar-collapse collapse"> <ul class="nav navbar-nav"> <li><a asp-area="" asp-controller="Gallery" asp-action="Index">Home</a></li> <li><a asp-area="" asp-controller="Gallery" asp-action="AddImage">Add an image</a></li> @if (User.Identity.IsAuthenticated) { <li><a asp-area="" asp-controller="Gallery" asp-action="Logout">Logout</a></li> } </ul> </div>
شیء this.User، هم در اکشن متدها و هم در Viewهای برنامه، جهت دسترسی به اطلاعات کاربر اعتبارسنجی شده، در دسترس است.
این لینک به اکشن متد Logout، در کنترلر گالری اشاره میکند که آنرا به صورت زیر تکمیل خواهیم کرد:
namespace ImageGallery.MvcClient.WebApp.Controllers { [Authorize] public class GalleryController : Controller { public async Task Logout() { // Clears the local cookie ("Cookies" must match the name of the scheme) await HttpContext.SignOutAsync("Cookies"); await HttpContext.SignOutAsync("oidc"); }
سپس نیاز است از برنامهی IDP نیز logout شویم. به همین جهت سطر دوم SignOutAsync با پارامتر oidc را مشاهده میکنید. بدون وجود این سطر، کاربر فقط از برنامهی کلاینت logout میشود؛ اما اگر به IDP مجددا هدایت شود، مشاهده خواهد کرد که در آن سمت، هنوز نام کاربری او توسط IDP شناسایی میشود.
بهبود تجربهی کاربری Logout
پس از logout، بدون انجام یکسری از تنظیمات، کاربر مجددا به برنامهی کلاینت به صورت خودکار هدایت نخواهد شد و در همان سمت IDP متوقف میشد. برای بهبود این وضعیت و بازگشت مجدد به برنامهی کلاینت، اینکار را یا توسط مقدار دهی خاصیت SignedOutCallbackPath مربوط به متد AddOpenIdConnect میتوان انجام داد و یا بهتر است مقدار پیشفرض آنرا به تنظیمات IDP نسبت داد که پیشتر در تنظیمات متد GetClients آنرا ذکر کرده بودیم:
PostLogoutRedirectUris = new List<string> { "https://localhost:5001/signout-callback-oidc" },
البته هنوز یک مرحلهی انتخاب و کلیک بر روی لینک بازگشت وجود دارد. برای حذف آن و خودکار کردن Redirect نهایی آن، میتوان کدهای IdentityServer4.Quickstart.UI را که در قسمت قبل به برنامهی IDP اضافه کردیم، اندکی تغییر دهیم. برای این منظور فایل src\IDP\DNT.IDP\Quickstart\Account\AccountOptions.cs را گشوده و سپس فیلد AutomaticRedirectAfterSignOut را که false است، به true تغییر دهید.
تنظیمات بازگشت Claims کاربر به برنامهی کلاینت
به صورت پیشفرض، Identity Server اطلاعات Claims کاربر را ارسال نمیکند و Identity token صرفا به همراه اطلاعات Id کاربر است. برای تنظیم آن میتوان در سمت تنظیمات IDP، در متد GetClients، زمانیکه new Client صورت میگیرد، خاصیت AlwaysIncludeUserClaimsInIdToken هر کلاینت را به true تنظیم کرد؛ اما ایده خوبی نیست. Identity token از طریق Authorization endpoint دریافت میشود. در اینجا اگر این اطلاعات از طریق URI دریافت شود و Claims به Identity token افزوده شوند، به مشکل بیش از حد طولانی شدن URL نهایی خواهیم رسید و ممکن است از طرف وب سرور یک چنین درخواستی برگشت بخورد. به همین جهت به صورت پیشفرض اطلاعات Claims به Identity token اضافه نمیشوند.
در اینجا برای دریافت Claims، یک endpoint دیگر در IDP به نام UserInfo endpoint درنظر گرفته شدهاست. در این حالت برنامهی کلاینت، مقدار Access token دریافتی را که به همراه اطلاعات scopes متناظر با Claims است، به سمت UserInfo endpoint ارسال میکند. باید دقت داشت زمانیکه Identity token دوم از Token endpoint دریافت میشود (تصویر ابتدای بحث)، به همراه آن یک Access token نیز صادر و ارسال میگردد. اینجا است که میانافزار oidc، این توکن دسترسی را به سمت UserInfo endpoint ارسال میکند تا user claims را دریافت کند:
در تنظیمات سمت کلاینت AddOpenIdConnect، درخواست openid و profile، یعنی درخواست Id کاربر و Claims آن وجود دارند:
options.Scope.Add("openid"); options.Scope.Add("profile");
options.GetClaimsFromUserInfoEndpoint = true;
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید.
برای اجرای برنامه:
- ابتدا به پوشهی src\WebApi\ImageGallery.WebApi.WebApp وارد شده و dotnet_run.bat آنرا اجرا کنید تا WebAPI برنامه راه اندازی شود.
- سپس به پوشهی src\IDP\DNT.IDP مراجعه کرده و و dotnet_run.bat آنرا اجرا کنید تا برنامهی IDP راه اندازی شود.
- در آخر به پوشهی src\MvcClient\ImageGallery.MvcClient.WebApp وارد شده و dotnet_run.bat آنرا اجرا کنید تا MVC Client راه اندازی شود.
اکنون که هر سه برنامه با هم در حال اجرا هستند، مرورگر را گشوده و مسیر https://localhost:5001 را درخواست کنید. در صفحهی login نام کاربری را User 1 و کلمهی عبور آنرا password وارد کنید.
GET https://localhost:7092/WeatherForecast
در اینجا میتوانیم تعدادی متغیر را نیز تعریف کرده و از آنها استفاده کنیم:
@hostname = localhost @port = 7092 @host = {{hostname}}:{{port}} GET https://{{host}}/WeatherForecast
حال میخواهیم یک درخواست Post را ایجاد و ارسال کنیم. برای این منظور ابتدا داخل کنترلر WeatherForecast، یک اکشن متد Post را ایجاد میکنیم که در این مثال کاری با دیتای وارد شده نمیکند و فقط آنرا بازگشت میدهد:
[HttpPost] public ActionResult Post(WeatherForecast weatherForecast) { //Code ... return Ok(weatherForecast); }
@hostname = localhost @port = 7092 @host = {{hostname}}:{{port}} @contentType = application/json POST https://{{host}}/WeatherForecast Content-Type:{{contentType}} { "date": "2023-03-29", "temperatureC": 30, "summary": "Hot" }
به این مورد دقت داشته باشید که برای داشتن چند درخواست در یک فایل، برای جدا کردن آنها از هم باید از ### استفاده کنید:
@hostname = localhost @port = 7092 @host = {{hostname}}:{{port}} @contentType = application/json GET https://{{host}}/WeatherForecast ### POST https://{{host}}/WeatherForecast Content-Type:{{contentType}} { "date": "2023-03-29", "temperatureC": 30, "summary": "Hot" }