معماری میکروسرویسها
مشاهدهی جزئیات اطلاعات سرور و بستههای نصب شدهی بر روی آن
در نگارشهای قبل از RTM، با فراخوانی app.UseRuntimeInfoPage در متد Configure کلاس Startup، ریز اطلاعاتی از وضعیت سرور و بستههای موجود در آن با مراجعهی به آدرس http://site/runtimeinfo نمایش داده میشدند. این مورد خاص از نگارش RTM حذف شدهاست (احتمالا به دلایل امنیتی). البته اگر علاقمند به بررسی کدهای آن باشید، هنوز تاریخچهی آن در GitHub موجود است .
مدیریت خطاها در برنامههای ASP.NET Core 1.0
به متد Configure کلاس Startup مراجعه کرد و یک سطر استثناء را به ابتدای کدهای Middleware انتهایی آن اضافه کنید:
public void Configure(IApplicationBuilder app) { app.Run(async context => { throw new Exception("Generic Error"); await context.Response.WriteAsync("Hello DNT!"); }); }
در این حالت اگر برنامه را اجرا کنیم، این خروجی را دریافت خواهیم کرد:
و اگر به وضعیت بازگشت داده شدهی از طرف سرور دقت کنیم، فقط internal server error است:
در اینجا برخلاف نگارشهای قبلی ASP.NET، دیگر حتی صفحهی زرد رنگ معروف نمایش خطاها (yellow screen of death) نیز فعال نیستند. برای فعال سازی آن نیاز است Middleware مرتبط با آنرا به نحو ذیل به برنامه معرفی کنیم:
public void Configure(IApplicationBuilder app) { app.UseDeveloperExceptionPage();
به دلایل امنیتی و عدم نشت اطلاعات سمت سرور و خصوصا عدم امکان دیباگ از راه دور برنامه توسط مهاجمین، این Middleware به صورت پیش فرض فعال نیست.
بنابراین این سؤال مطرح میشود که چگونه میتوان این صفحه را تنها در حین توسعهی برنامه نمایش داد؟
پاسخ آن به نحوهی طراحی متد Configure در کلاس Startup بر میگردد. این متد امضای ثابتی را ندارد. هر تعداد سرویسی را که نیاز داشتید، میتوانید به عنوان پارامتر این متد معرفی کنید و کار تزریق وابستگیها و نمونه سازی آنها، توسط امکانات توکار ASP.NET Core به صورت خودکار انجام میشود. برای مثال سرویس IApplicationBuilder، یکی از سرویسهای توکار ASP.NET Core است و برای تنظیم آن نیازی نیست تا کار خاصی را انجام دهیم. به همین جهت است که صرفا معرفی اینترفیس آن در این متد، وهلهای را از سازندهی برنامه در اختیار ما قرار میدهد. سرویسها را در مطلبی جداگانه مورد بررسی قرار خواهیم داد، اما فعلا جهت تکمیل بحث باید درنظر داشت که یکی دیگر از سرویسهای توکار ASP.NET Core، به نام IHostingEnvironment، اطلاعاتی را در مورد محیطی که برنامه را در آن اجرا میکنیم در اختیار ما قرار میدهد:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); }
این متغیر محیطی میتواند سه مقدار Development, Staging و Production را داشته باشد و بر اساس این متغیر و مقدار آن است که یکی از سه متد ذیل مفهوم پیدا میکنند و true یا false را باز میگردانند:
if(env.IsDevelopment()){ } if(env.IsProduction()){ } if(env.IsStaging()){ }
نمایش و مدیریت خطاها در حالت Production
از app.UseDeveloperExceptionPage صرفا در حالت توسعه استفاده کنید؛ چون اطلاعات نمایش داده شدهی توسط آن، بیش از اندازه برای مهاجمین مفید است. اما در حالت توزیع نهایی بر روی سرور چه باید کرد؟
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler(errorHandlingPath: "/MyControllerName/SomeActionMethodName"); }
به علاوه در اینجا (در این قسمت خاص برنامه که توسط پارامتر errorHandlingPath مشخص شدهاست) با استفاده از قطعه کد ذیل، دسترسی کاملی را به اطلاعات خطای رخ داده، جهت ثبت و لاگ آن دارید:
var feature = HttpContext.Features.Get<IExceptionHandlerFeature>(); var error = feature?.Error;
بررسی میانافزار StatusCode
این میان افزار برای مدیریت responseهایی که status code آنها بین 400 تا 600 هستند، طراحی شدهاست. بر اساس این شمارهها، میتوان خطای خاصی را بازگشت داده و یا کاربر را به یک صفحه یا کنترلر خاصی در برنامه، هدایت کرد.
در حالت عادی ثبت آن
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseStatusCodePages(); app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler(errorHandlingPath: "/MyControllerName/SomeActionMethodName"); } }
برای نمونه در اینجا مسیری درخواست داده شدهاست که توسط برنامه پردازش نمیشود و وجود ندارد.
اگر خواستید تا status code واقعی، به کاربر بازگشت داده شود، اما خروجی نمایش داده شده را سفارشی سازی کنید، میتوانید از متد UseStatusCodePagesWithReExecute استفاده نمائید:
app.UseStatusCodePagesWithReExecute("/MyControllerName/SomeActionMethodName/{0}");
برای خیلی ممکن است سوال پیش آمده باشد چطور یک برنامه نویس از پروژه ای که به صورت اوپن سورس منتشر میکند محافظت کرده و از سوء استفاده جلوگیری میکند ؟ بر اساس همین سوال شخص لینوس توروالدز Git را ایجاد کرد برای ذخیره پروژههای متن باز و حفظ حقوق برنامه نویس پروژه
سایت گیت هاب (github.com) بر پایه Git تشکیل شده و به همین منظور استفاده میشود. البته برنامه نویس میتواند پروژه را بصورت خصوصی ذخیره کند و از انتشار عمومی پروژه خودداری کند. با استفاده از این سیستم برنامه نویسان پروژههای متن باز را با خیال راحت و با حفظ حقوق منتشر کنند و به این ترتیب پروژه به نام آن برنامه نویس ثبت خواهد شد. در این سیکل برنامه نویس یک اکانت در این سایت ایجاد و برای هر پروژه متن باز که منتشر میکند یک صفحه (مخزن) ساخته و پروژه را در آن ذخیره میکند.
یکی دیگر از مواردی که ممکن است برای برنامههای متن باز پیش بیاید این است که اگر برنامه نویسی یک پروژه متن باز را از گیت هاب توسعه داد ، موارد اضافه شده بر عهده برنامه نویس اول گذاشته نشه و حق برنامه نویس اصلی رعایت شود ؛ برای این منظور سیکلی در سایت گیت هاب ایجاد شده با عنوان Forking که یک برنامه نویس میتواند پروژه را داشته باشد و پس از توسعه پروژه ، تغییرات ایجاد شده در برنامه را به برنامه نویس اصلی ارسال کند و پس از تایید ، تغییرات ایجاد شده در مخزن اصلی پروژه اعمال شود.
گیت هاب امکانات بیشتری را در خود پیاده کرده که این سایت را تبدیل به شبکه اجتماعی برای برنامه نویسان کرده است. موارد از قبیل انجمن برای پرسش و مشکلات ، ارسال پیغام خصوصی برای سایر اعضا و ….
آیا از قابلیت FromService و تزریق سرویسها در سازنده مدلهای برنامه فقط زمانی میتونیم استفاده کنیم که مدلها و سرویسها در یک پروژه باشن ؟
چون در غیر این صورت معمولا لایه سرویس ما لایه مدل رو به عنوان رفرنس اضافه میکنه و مجددا برعکس این حالت یعنی لایه مدل به سرویس غیر ممکن میشه.
با آمدن Asp.Net Web API کار ساختن Web APIها برای برنامه نویسها به خصوص دسته ای که با ساخت API و
وب سرویس آشنا نبودند خیلی سادهتر شد . اگر با Asp.Net MVC آشنا باشید
خیلی سریع میتوانید اولین Web Service خودتان را بسازید .
در صفحه مربوط به Asp.Net Web API آمده است که این فریمورک بستر مناسبی برای ساخت و توسعه برنامه های RESTful است . اما تنها ساختن کنترلر و اکشن و برگشت دادن دادهها به سمت کلاینت ، به خودی خود برنامه شما رو تبدیل به یک RESTful API نمیکند .
مثل تمام مفاهیم و ابزارها ، طراحی و ساختن RESTful API هم دارای اصول و Best Practice هایی است که رعایت آنها به خصوص در این زمینه از اهمیت زیادی برخوردار است . همانطور که از تعریف API برمی آید شما در حال طراحی رابطی هستید تا به توسعه دهندگان دیگر امکان دهید از دادهها و یا خدمات شما در برنامهها و سرویس هایشان استفاده کنند . مانند APIهای توئیتر و نقشه گوگل که برنامههای زیادی بر مبنای آنها ساخته شده اند . در واقع توسعه دهندگان مشتریان API شما هستند .
بهره وری توسعه دهنده مهمترین اصل
اینطور میتوان نتیجه گرفت که اولین و
مهمترین اصل در طراحی API باید رضایت و موفقیت توسعه دهنده در درک و
یادگیری سریع API شما ،نه تنها با کمترین زحمت بلکه همراه با حس نشاط ، باشد. ( تجربه کاربری در اینجا هم میتواند صدق کند ). سعی کنید در زمان
انتخاب از بین روشهای طراحی موجود ، از دیدگاه توسعه دهنده به مسئله نگاه کنید .
خود را به جای او قرار دهید و تصور کنید که میخواهید با استفاده از API
موجود یک رابط کاربری طراحی کنید یا یک اپلیکشن برای موبایل بنویسید و اصل را این
نکته قرار دهید که بهره وری برنامه نویس را حداکثر کنید. ممکن است گاهی بین طرحی که بر اساس این اصل برای API خود در نظر داریم و یکی از اصول یا استانداردها تعارض بوجود بیاید . در این موارد بعد از اینکه مطمئن شدیم این اختلاف ناشی از طراحی و درک اشتباه خودمان نیست (که اکثرا هست ) ارجحیت را باید به طراحی بدهیم .
تهیه مستندات API
اگر برای پروژه وب سایتتان هیچ نوشته ای یا توضیحی ندارید ، جالب نیست اما خودتان ساختار برنامه خود را میشناسید و کار را پیش میبرید. اما توسعه دهنده ای که از API شما میخواهد استفاده کند و به احتمال زیاد شما را نمیشناسد ، عضو تیم شما هم نیست ، هیچ ایده ای درباره ساختار آن ، روش نامگذاری توابع و منابع، ساختار Urlها ، چگونگی و گامهای پروسه درخواست تا دریافت پاسخ ندارد ،و به مستندات شما وابسته است و تمام اینها باید در مستندات شما باشد. بیشتر توسعه دهندهها قبل از تست کردن API شما سری به مستندات میزنند ، دنبال نمونه کد آموزشی میگردند و در اینترنت درباره آن جستجو میکنند . ازینرو مستندات ( کارامد ) یک ضرورت است :
1- در مستندات باید هم درباره کلیت و هم در مورد تک تک توابع ( پارامترهای معتبر ، ساختار پاسخها و ... ) توضیحات وجود داشته باشد.
2- باید شامل مثالهایی از سیکل کامل درخواستها / پاسخها باشند .
3- تغییرات اعمال شده نسبت به نسخههای قبلی باید در مستندات بیان شوند .
4- (در وب ) یافتن و جستجو کردن در مستنداتی که به صورت فایل Pdf هستند یا برای دسترسی نیاز به Login داشته باشند سخت و آزاردهنده هستند.
5- کسی را داشته باشید تا با و بدون مستندات با API شما کار کند و از این روش برای تکمیل و اصلاح مستندات استفاده کنید.
رعایت نسخه بندی و حفظ نسخههای قبلی به صورت فعال برای مدت معین
یک API تقریبا هیچوقت کاملا پایدار نمیشود و اعمال تغییرات برای بهبود آن اجتناب ناپذیر هستند . مسئله مهم این است که چطور این تغییرات مدیریت شوند . مستند کردن تغییرات ، اعلام به موقع آنها و دادن یک بازه زمانی کافی برای ارتقا یافتن برنامه هایی که از نسخههای قدیمیتر استفاده میکنند نکات مهمی هستند . همیشه در کنار نسخه بروز و اصلی یک یا دو نسخه ( بسته به API و کلاینتهای آن ) قدیمیتر را برای زمان مشخصی در حالت سرویس دهی داشته باشید .
داشتن یک روش مناسب برای اعلام تغییرات و ارائه مستندات و البته دریافت بازخورد از استفاده کنندگان
تعامل با کاربران برنامه باید از کانالهای مختلف وجود داشته باشد .از وبلاگ ، Mailing List ، Google Groups و دیگر ابزارهایی که در اینترنت وجود دارند برای انتشار مستندات ، اعلام بروزرسانیها ، قرار دادن مقالات و نمونه کدهای آموزشی ، پرسش و پاسخ با کاربران استفاده کنید .
مدیریت خطاها به شکل صحیح که به توسعه دهنده در آزمودن برنامه اش کمک کند.
از منظر برنامه نویسی که از API شما استفاده میکند هرآنچه در آنسوی API اتفاق میافتد یک جعبه سیاه است . به همین جهت خطاهای API شما ابزار کلیدی برای او هستند که خطایابی و اصلاح برنامه در حال توسعه اش را ممکن میکنند . علاوه بر این ، زمانی که برنامه نوشته شده با API شما مورد استفاده کاربر نهایی قرار گرفت ، خطاهای به دقت طراحی شده API شما کمک بزرگی برای توسعه دهنده در عیب یابی هستند .
1- از Status Code های HTTP استفاده کنید و سعی کنید تا حد ممکن آنها را نزدیک به مفهوم استانداردشان بکار ببرید .
2- خطا و علت آن را به زبان روشن توضیح دهید و در توضیح خساست به خرج ندهید .
3- در صورت امکان لینکی به یک صفحه وب که حاوی توضیحات بیشتری است را در خطا بگنجانید .
رعایت ثبات و یکدستی در تمام بخشهای طراحی که توانایی پیش بینی توسعه دهنده را در استفاده از API افزایش میدهد .
داشتن مستندات لازم است اما این بدین معنی نیست که خود API نباید خوانا و قابل پیش بینی باشد . از هر روش و تکنیکی که استفاده میکنید آن را در تمام پروژه حفظ کنید . نامگذاری توابع/منابع ، ساختار پاسخها ، Urlها ، نقش و عملیاتی که HTTP methodها در API شما انجام میدهند باید ثبات داشته باشند . از این طریق توسعه دهنده لازم نیست برای هر بخشی از API شما به سراغ فایلها راهنما برود . و به سرعت کار خود را به پیش میبرد .
انعطاف پذیر بودن API
API توسط کلاینتهای مختلفی و برای افراد مختلفی مورد استفاده قرار میگیرد که لزوما همهی آنها ساختار یکسانی ندارند و API شما باید تا جای ممکن بتواند همه آنها را پوشش دهد . محدود بودن فرمت پاسخ ، ثابت بودن فیلدهای ارسالی به کلاینت ، ندادن امکان صفحه بندی ، مرتب سازی و جستجو در دادهها به کلاینت ، داشتن تنها یک نوع احراز هویت ، وابسته بودن به کوکی و ... از مشخصات یک API منجمد و انعطاف ناپذیر هستند .
اینها اصولی کلی بودند که بسیاری از آنها مختص طراحی API نیستند و در تمام حوزهها قابل استفاده بوده ، جز الزامات هستند . در قسمتهای بعدی نکات اختصاصیتری را بررسی خواهیم کرد .
تعریف ساختار ماژولهای ویژگیهای معماری vertical slices
برای تعریف ساختار ماژولی که کار ثبت تمام نیازمندیهای یک ویژگی را انجام میدهد، مانند ثبت سرویسها، endpoints و میانافزارها، ابتدا پوشهای به نام Contracts را به پروژهی Api اضافه میکنیم؛ با این اینترفیس:
namespace MinimalBlog.Api.Contracts; public interface IModule { IEndpointRouteBuilder RegisterEndpoints(IEndpointRouteBuilder endpoints); }
ثبت خودکار ماژولهای برنامه در ابتدای اجرای آن
پس از تعریف این قرارداد، اکنون میخواهیم هر ماژولی که در برنامه، اینترفیس فوق را پیاده سازی میکند، در ابتدای اجرای برنامه به صورت خودکار، یافت شده و اطلاعات آن به سیستم اضافه شود. برای این منظور متدهای الحاقی زیر را تعریف میکنیم:
public static class ServiceCollectionExtensions { public static IServiceCollection AddApplicationServices(this IServiceCollection services, WebApplicationBuilder builder) { // ... builder.Services.AddAllModules(typeof(Program)); return services; } private static void AddAllModules(this IServiceCollection services, params Type[] types) { // Using the `Scrutor` to add all of the application's modules at once. services.Scan(scan => scan.FromAssembliesOf(types) .AddClasses(classes => classes.AssignableTo<IModule>()) .AsImplementedInterfaces() .WithSingletonLifetime()); } }
سپس کلاسهای ثبت شده که هم اکنون جزئی از سیستم تزریق وابستگیهای برنامه هستند، یافت شده و متد RegisterEndpoints آنها فراخوانی میشوند تا دیگر نیازی نباشد به ازای هر ماژول، یکبار ثبت دستی این موارد در کلاس Program انجام شود.
using MinimalBlog.Api.Contracts; namespace MinimalBlog.Api.Extensions; public static class ModuleExtensions { public static WebApplication RegisterEndpoints(this WebApplication app) { if (app == null) { throw new ArgumentNullException(nameof(app)); } var modules = app.Services.GetServices<IModule>(); foreach (var module in modules) { module.RegisterEndpoints(app); } return app; } }
using MinimalBlog.Api.Extensions; var builder = WebApplication.CreateBuilder(args); builder.Services.AddApplicationServices(builder); var app = builder.Build(); app.ConfigureApplication(); app.RegisterEndpoints(); app.Run();
ایجاد اولین Feature برنامه؛ ویژگی نویسندگان
برای تعریف اولین ویژگی برنامه که مختص به نویسندگان است، پوشههای جدید Features\Authors را در برنامهی Api ایجاد میکنیم.
- اولین کاری را که در ادامه انجام خواهیم داد، انتقال فایل AuthorDto.cs که در قسمت قبل ایجاد کردیم، به درون این پوشهی جدید است.
- سپس ماژول نویسندگان را به صورت زیر به آن اضافه میکنیم:
namespace MinimalBlog.Api.Features.Authors; public class AuthorModule : IModule { public IEndpointRouteBuilder RegisterEndpoints(IEndpointRouteBuilder endpoints) { endpoints.MapGet("/api/authors", async (MinimalBlogDbContext ctx) => { var authors = await ctx.Authors.ToListAsync(); return authors; }); endpoints.MapPost("/api/authors", async (MinimalBlogDbContext ctx, AuthorDto authorDto) => { var author = new Author(); author.FirstName = authorDto.FirstName; author.LastName = authorDto.LastName; author.Bio = authorDto.Bio; author.DateOfBirth = authorDto.DateOfBirth; ctx.Authors.Add(author); await ctx.SaveChangesAsync(); return author; }); return endpoints; } }
کار نمونه سازی و اجرای متدهای این ماژولها نیز توسط متدهای الحاقی کلاس ModuleExtensions، در ابتدای اجرای برنامه به صورت خودکار انجام میشود و نیازی به شلوغ کردن کلاس Program برای ثبت دستی آنها نیست.
افزودن AutoMapper و MediatR به پروژهی Api
در ادامه برای ساده سازی کار نگاشتهای Dtoهای برنامه به مدلهای دومین آن، از AutoMapper استفاده خواهیم کرد؛ همچنین از MediatR نیز برای پیاده سازی الگوی CQRS که در قسمت بعدی پیگیری خواهد شد. بنابراین در ابتدا بستههای نیوگت این دو را به پروژهی Api اضافه میکنیم:
<Project Sdk="Microsoft.NET.Sdk.Web"> <ItemGroup> <PackageReference Include="AutoMapper.Extensions.Microsoft.DependencyInjection" Version="11.0.0" /> <PackageReference Include="MediatR.Extensions.Microsoft.DependencyInjection" Version="10.0.1" /> </ItemGroup> </Project>
public static class ServiceCollectionExtensions { public static IServiceCollection AddApplicationServices(this IServiceCollection services, WebApplicationBuilder builder) { // ... builder.Services.AddMediatR(typeof(Program)); builder.Services.AddAutoMapper(typeof(Program)); return services; } }
using AutoMapper; using MinimalBlog.Domain.Model; namespace MinimalBlog.Api.Features.Authors; public class AuthorProfile : Profile { public AuthorProfile() { CreateMap<AuthorDto, Author>().ReverseMap(); } }
SignalR
Async library for .NET to help build real-time, multi-user interactive web applications.
The real-time web is a set of technologies and practices that enable users to receive information as soon as it is published by its authors, rather than requiring that they or their software check a source periodically for updates.
- تکنولوژی جدید WebSocket (^) که خوشبختانه پشتیبانی کاملی از اون در دات نت 4.5 (چهار نقطه پنج! نه چهار و نیم!) وجود داره. اما تمام مرورگرها و تمام وب سرورها از این تکنولوژی پشتیبانی نمیکنند و تنها برخی نسخههای جدید قابلیت استفاده از آخرین ورژن WebSocket رو دارند که میشه به کروم 16 به بالا و فایرفاکس 11 به بالا و اینترنت اکسپلورر 10 اشاره کرد (برای استفاده از این تکنولوژی در ویندوز نیاز به IIS 8.0 است که متاسفانه فقط در ویندوز 8.0 موجوده):
Chrome 16, Firefox 11 and Internet Explorer 10 are currently the only browsers supporting the latest specification (RFC 6455). - یه روش دیگه Server-sent Events نام داره که دادههای جدید رو به فرم رویدادهای DOM به سمت کلاینت میفرسته(^).
- روش دیگهای که موجوده به Forever Frame معروفه که در این روش یک iframe مخفی درون کد html مسئول تبادل دادههاست. این iframe مخفی بهصورت یک بلاک Chunked (^) به سمت کلاینت فرستاده میشه. این iframe که مسئول رندر دادههای جدید در سمت کلاینت هست ارتباط خودش رو با سرور تا ابد! (برای همین بهش forever میگن) حفظ میکنه. هر وقت رویدادی سمت سرور رخ میده با استفاده از این روش دادهها بهصورت تگهای script به این فریم مخفی فرستاده میشوند و چون مرورگرها محتوای html رو به صورت افزایشی (incrementally) رندر میکنن بنابراین این اسکریپتها بهترتیب زمان دریافت اجرا میشوند. (البته ظاهرا عبارت forever frame در صنعت عکاسی! معروفتره بنابراین در جستجو در زمینه این روش ممکنه کمی مشکل داشته باشین) (^).
- روش آخر که در کتابخونه SignalR ازش استفاده میشه long-polling نام داره. در روش polling معمولی پس از ارسال درخواست توسط کلاینت، سرور بلافاصله نتیجه حاصله رو به سمت کلاینت میفرسته و ارتباط قطع میشه. بنابراین برای دادههای جدید درخواست جدیدی باید به سمت سرور فرستاده بشه که تکرار این روش باعث افزایش شدید بار بر روی سرور و کاهش کارآمدی اون میشه. اما در روش long-polling پس از برقراری ارتباط کلاینت با سرور این ارتباط تا مدت زمان معینی (که توسط یه مقدار تایم اوت مشخص میشه و مقدار پیشفرضش 2 دقیقه است) برقرار میمونه. بنابراین کلاینت میتونه بدون ایجاد مشکلی در کارایی، دادههای جدید رو از سرور دریافت کنه. به این روش در برنامهنویسی وب اصطلاحا برنامهنویسی کامت (Comet Programming) میگن (^ ^).
- کلاس سطح پایین PersistentConnection
- کلاس سطح بالای Hub
PM> Install-Package SignalR.Sample
PM> Install-Package SignalR
Microsoft.Web.Infrastructure Newtonsoft.Json SignalR SignalR.Hosting.AspNet SignalR.Hosting.Common
jquery-1.6.4.js jquery.signalR-0.5.1.js
using SignalR.Hubs; namespace SimpleChatWithSignalR { public class SimpleChat : Hub { public void SendMessage(string message) { Clients.reciveMessage(message); } } }
<input type="text" id="msg" /> <input type="button" value="Send" id="send" /><br /> <textarea id='messages' readonly="true" style="height: 200px; width: 200px;"></textarea> <script src="Scripts/jquery-1.6.4.min.js" type="text/javascript"></script> <script src="Scripts/jquery.signalR-0.5.1.min.js" type="text/javascript"></script> <script src="signalr/hubs" type="text/javascript"></script> <script type="text/javascript"> var chat = $.connection.simpleChat; chat.reciveMessage = function (msg) { $('#messages').val($('#messages').val() + "-" + msg + "\r\n"); }; $.connection.hub.start(); $('#send').click(function () { chat.sendMessage($('#msg').val()); }); </script>
<script src="signalr/hubs" type="text/javascript"></script>
به روز رسانی
در دورهای به نام SignalR در سایت، به روز شدهای این مباحث را میتوانید مطالعه کنید.
مهارتهای تزریق وابستگیها در برنامههای NET Core. - قسمت نهم - تعریف سرویسهای Open Generics
public async Task<IActionResult> Index( [FromServices] MusicStoreContext dbContext, [FromServices] IMemoryCache cache)
ابتدا یک پروژه با دو Console Application با نام های Service و Client ایجاد کنید. سپس در پروژه Service یک سرویس به نام BookService ایجاد کنید و کدهای زیر را در آن کپی نمایید:
Contract مربوطه به صورت زیر است:
[ServiceContract] public interface IBookService { [OperationContract] int GetCountOfBook(); }
[ServiceBehavior(IncludeExceptionDetailInFaults = true)] public class BookService : IBookService { public int GetCountOfBook() { return 10; } }
class Program { static void Main(string[] args) { ServiceHost host = new ServiceHost(typeof(BookService)); var binding = new BasicHttpBinding(); host.AddServiceEndpoint(typeof(IBookService), binding, "http://localhost/BookService"); host.Open(); Console.Write("BookService host"); Console.ReadKey(); } }
حال نوبت به پیاده سازی سمت کلاینت میرسد. فایل Program سمت کلاینت را باز کرده و کدهای زیر را نیز در آن کپی نمایید:
static void Main(string[] args) { Thread.Sleep(2000); BasicHttpBinding binding = new BasicHttpBinding(); ChannelFactory<IBookService> channel = new ChannelFactory<IBookService>(binding, new EndpointAddress("http://localhost/BookService")); Console.WriteLine("Count of book: {0}", channel.CreateChannel().GetCountOfBook()); Console.ReadKey(); }
خروجی زیر مشاهده میشود:
تا اینجا هیچ گونه اعتبار سنجی انجام نشد. برای پیاده سازی اعتبار سنجی باید یک سری تنظیمات بر روی Binding و Hosting سمت سرور و البته کلاینت بر قرار شود. فایل Program پروزه Service را باز نمایید و محتویات آن را به صورت زیر تغییر دهید:
static void Main(string[] args) { ServiceHost host = new ServiceHost(typeof(BookService)); var binding = new BasicHttpBinding(); binding.Security = new BasicHttpSecurity(); binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly; binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic; host.Credentials.UserNameAuthentication.UserNamePasswordValidationMode = System.ServiceModel.Security.UserNamePasswordValidationMode.Custom; host.Credentials.UserNameAuthentication.CustomUserNamePasswordValidator = new CustomUserNamePasswordValidator(); host.AddServiceEndpoint(typeof(IBookService), binding, "http://localhost/BookService"); host.Open(); Console.Write("BookService host"); Console.ReadKey(); }
ابتدا نوع Security در Binding را به حالت TransportCredentialOnly تنظیم کردیم. در یک جمله هیچ گونه تضمینی برای صحت اطلاعات انتقالی در این حالت وجود ندارد و فقط یک اعتبار سنجی اولیه انجام خواهد شد. در نتیجه هنگام استفاده از این حالت باید با دقت عمل نمود و نباید فقط به پیاده سازی این حالت اکتفا کرد.( Encryption اطلاعات سرویسها مورد بحث این پست نیست)
ClientCredentialType نیز باید به حالت Basic تنظیم شود. در WCF اعتبار سنجی به صورت پیش فرض در حالت Windows است (بعنی UserNamePasswordValidationMode برابر مقدار Windows است و اعتبار سنجی بر اساس کاربر انجام میشود) . این مورد باید به مقدار Custom تغییر یابد. در انتها نیز باید مدل اعتبار سنجی دلخواه خود را به صورت زیر پیاده سازی کنیم:
در پروژه سرویس یک کلاس به نام CustomUserNamePasswordValidator بسازید و کدهای زیر را در آن کپی کنید:
public class CustomUserNamePasswordValidator : UserNamePasswordValidator { public override void Validate(string userName, string password) { if (userName != "Masoud" || password != "Pakdel") throw new SecurityException("Incorrect userName or password"); } }
تغییرات مورد نیاز سمت کلاینت:
اگر در این حالت پروژه را اجرا نمایید از آن جا که از این به بعد، درخواستها سمت سرور اعتبار سنجی میشوند در نتیجه با خطای زیر روبرو خواهید شد:
این خطا از آن جا ناشی میشود که تنظیمات کلاینت و سرور از نظر امنیتی با هم تناسب ندارد. در نتیجه باید تنظیمات Binding کلاینت و سرور یکی شود. برای این کار کد زیر را به فایل Program سمت کلاینت اضافه میکنیم:
static void Main(string[] args) { Thread.Sleep(2000); BasicHttpBinding binding = new BasicHttpBinding(); binding.Security = new BasicHttpSecurity(); binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly; binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic; ChannelFactory<IBookService> channel = new ChannelFactory<IBookService>(binding, new EndpointAddress("http://localhost/BookService")); channel.Credentials.UserName.UserName = "WrongUserName"; channel.Credentials.UserName.Password = "WrongPassword";
Console.WriteLine("Count of book: {0}", channel.CreateChannel().GetCountOfBook()); Console.ReadKey(); }
channel.Credentials.UserName.UserName = "WrongUserName"; channel.Credentials.UserName.Password = "WrongPassword";
دریافت سورس مثال بالا