مرحله | معادل آن در پروژههای قدیمی MVC 5 |
ایجاد یک پروژهی جدید ASP.NET Core در VS 2017 | یک پروژهی جدید Web API را ایجاد کنید. |
تنظیمات یک برنامهی ASP.NET Core خالی برای اجرای یک برنامهی Angular CLI | به این موارد نیازی نخواهید داشت. چون پروژههای MVC 5 برخلاف ASP.NET Core، پوشههایی را که دستی به آن اضافه نکنید، به صورت خودکار به پروژه اضافه نمیکند. بنابراین فایلهای Angular-CLI را به Solution Explorer وارد نکنید و بهترین روش کار کردن با آنها از طریق VSCode است. در اینجا برای back-end (کار با Web API) از VS کامل استفاده کنید و برای front-end از VSCode. |
افزودن یک کنترلر Web API جدید | کلیات آن با MVC 5 یکی است. |
تنظیمات فایل آغازین یک برنامهی ASP.NET Core جهت ارائهی برنامههای Angular | معادل قسمت URL Rewrite آن، از نکتهی web.config مطلب «مسیریابی در Angular - قسمت اول - معرفی»، قسمت «تفاوت بین آدرسهای HTML 5 و Hash-based» استفاده کنید. |
ایجاد ساختار اولیهی برنامهی Angular CLI در داخل پروژهی جاری | یکی هست. |
تنظیم محل خروجی نهایی Angular CLI به پوشهی wwwroot | یکی هست. فقط شاید علاقمند باشید مسیر "" (پوشهی ریشه) را بجای wwwroot تنظیم کنید. |
فراخوانی کنترلر Web API برنامه در برنامهی Angular CLI | یکی هست. |
نصب وابستگیهای برنامهی Angular CLI | یکی هست. |
روش اول اجرای برنامههای مبتنی بر ASP.NET Core و Angular CLI | یکی هست. |
روش دوم اجرای برنامههای مبتنی بر ASP.NET Core و Angular CLI | در اینجا نیازی به آن نیست ولی در کل مطالعهی نکات آن مفید است. |
فایلهای bat ارائه شده و یا روش NPM Task Runner در نظرات | یکی هستند. |
از Claims جهت ارائهی اطلاعات مرتبط با هویت هر کاربر و همچنین Authorization استفاده میشود. برای مثال درنگارشهای قبلی ASP.NET، مفاهیمی مانند «نقشها» وجود دارند. در نگارشهای جدیدتر آن، «نقشها» تنها یکی از انواع «User Claims» هستند. در قسمتهای قبل روش تعریف این Claims را در IDP و همچنین تنظیمات مورد نیاز جهت دریافت آنها را در سمت برنامهی Mvc Client بررسی کردیم. در اینجا مطالب تکمیلی کار با User Claims را مرور خواهیم کرد.
بررسی Claims Transformations
میخواهیم Claims بازگشت داده شدهی توسط IDP را به یکسری Claims که کار کردن با آنها در برنامهی MVC Client سادهتر است، تبدیل کنیم.
زمانیکه اطلاعات Claim، توسط میانافزار oidc دریافت میشود، ابتدا بررسی میشود که آیا دیکشنری نگاشتها وجود دارد یا خیر؟ اگر بله، کار نگاشتها از یک claim type به claim type دیگر انجام میشود.
برای مثال لیست claims اصلی بازگشت داده شدهی توسط IDP، پس از تبدیلات و نگاشتهای آن در برنامهی کلاینت، یک چنین شکلی را پیدا میکند:
در ادامه میخواهیم نوعهای آنها را سادهتر کنیم و آنها را دقیقا تبدیل به همان claim typeهایی کنیم که در سمت IDP تنظیم شدهاند. برای این منظور به فایل src\MvcClient\ImageGallery.MvcClient.WebApp\Startup.cs مراجعه کرده و سازندهی آنرا به صورت زیر تغییر میدهیم:
در اینجا جدول نگاشتهای پیشفرض Claims بازگشت داده شدهی توسط IDP به Claims سمت کلاینت، پاک میشود.
در ادامه اگر مجددا لیست claims را پس از logout و login، بررسی کنیم، به این صورت تبدیل شدهاست:
اکنون این نوعها دقیقا با آنچیزی که IDP ارائه میدهد، تطابق دارند.
کار با مجموعهی User Claims
تا اینجا لیست this.User.Claims، به همراه تعدادی Claims است که به آنها نیازی نداریم؛ مانند sid که بیانگر session id در سمت IDP است و یا idp به معنای identity provider میباشد. حذف آنها حجم کوکی نگهداری کنندهی آنها را کاهش میدهد. همچنین میخواهیم تعدادی دیگر را نیز به آنها اضافه کنیم.
علاوه بر اینها میانافزار oidc، یکسری از claims دریافتی را راسا فیلتر و حذف میکند؛ مانند زمان منقضی شدن توکن و امثال آن که در عمل واقعا به تعدادی از آنها نیازی نداریم. اما میتوان این سطح تصمیم گیری فیلتر claims رسیده را نیز کنترل کرد. در تنظیمات متد AddOpenIdConnect، خاصیت options.ClaimActions نیز وجود دارد که توسط آن میتوان بر روی حذف و یا افزوده شدن Claims، کنترل بیشتری را اعمال کرد:
در اینجا فراخوانی متد Remove، به معنای حذف فیلتری است که کار حذف کردن خودکار claim ویژهی amr را که بیانگر نوع authentication است، انجام میدهد (متد Remove در اینجا یعنی مطمئن شویم که amr در لیست claims باقی میماند). همچنین فراخوانی متد DeleteClaim، به معنای حذف کامل یک claim موجود است.
اکنون اگر پس از logout و login، لیست this.User.Claims را بررسی کنیم، دیگر خبری از sid و idp در آن نیست. همچنین claim از نوع amr نیز به صورت پیشفرض حذف نشدهاست:
افزودن Claim جدید آدرس کاربر
برای افزودن Claim جدید آدرس کاربر، به کلاس src\IDP\DNT.IDP\Config.cs مراجعه کرده و آنرا به صورت زیر تکمیل میکنیم:
در اینجا در لیست Resources، گزینهی IdentityResources.Address نیز اضافه شدهاست که به Claim آدرس مرتبط است.
همین مورد را به لیست AllowedScopes متد GetClients نیز اضافه میکنیم:
در آخر Claim متناظر با Address را نیز به اطلاعات هر کاربر، در متد GetUsers، اضافه میکنیم:
تا اینجا تنظیمات IDP برای افزودن Claim جدید آدرس به پایان میرسد.
پس از آن به کلاس ImageGallery.MvcClient.WebApp\Startup.cs مراجعه میکنیم تا درخواست این claim را به لیست scopes میانافزار oidc اضافه کنیم:
همچنین میخواهیم مطمئن شویم که این claim درون claims identity قرار نمیگیرد. به همین جهت DeleteClaim در اینجا فراخوانی شدهاست تا این Claim به کوکی نهایی اضافه نشود تا بتوانیم همواره آخرین مقدار به روز شدهی آنرا از UserInfo Endpoint دریافت کنیم.
یک نکته: فراخوانی DeleteClaim بر روی address غیر ضروری است و میشود این سطر را حذف کرد. از این جهت که اگر به سورس OpenID Connect Options مایکروسافت مراجعه کنیم، مشاهده خواهیم کرد که میانافزار اعتبارسنجی استاندارد ASP.NET Core، تنها تعداد معدودی از claims را نگاشت میکند. به این معنا که هر claim ای که در token وجود داشته باشد، اما اینجا نگاشت نشده باشد، در claims نهایی حضور نخواهند داشت و address claim یکی از اینها نیست. بنابراین در لیست نهایی this.User.Claims حضور نخواهد داشت؛ مگر اینکه مطابق همین سورس، با استفاده از متد options.ClaimActions.MapUniqueJsonKey، یک نگاشت جدید را برای آن تهیه کنیم و البته چون نمیخواهیم آدرس در لیست claims وجود داشته باشد، این نگاشت را تعریف نخواهیم کرد.
دریافت اطلاعات بیشتری از کاربران از طریق UserInfo Endpoint
همانطور که در قسمت قبل با بررسی «تنظیمات بازگشت Claims کاربر به برنامهی کلاینت» عنوان شد، میانافزار oidc با UserInfo Endpoint کار میکند که تمام عملیات آن خودکار است. در اینجا امکان کار با آن از طریق برنامه نویسی مستقیم نیز جهت دریافت اطلاعات بیشتری از کاربران، وجود دارد. برای مثال شاید به دلایل امنیتی نخواهیم آدرس کاربر را در لیست Claims او قرار دهیم. این مورد سبب کوچکتر شدن کوکی متناظر با این اطلاعات و همچنین دسترسی به اطلاعات به روزتری از کاربر میشود.
درخواستی که به سمت UserInfo Endpoint ارسال میشود، باید یک چنین فرمتی را داشته باشد:
یک درخواست از نوع GET و یا POST است که به سمت آدرس UserInfo Endpoint ارسال میشود. در اینجا ذکر Access token نیز ضروری است. از این جهت که بر اساس scopes ذکر شدهی در آن، لیست claims درخواستی مشخص شده و بازگشت داده میشوند.
اکنون برای دریافت دستی اطلاعات آدرس از IDP و UserInfo Endpoint آن، ابتدا نیاز است بستهی نیوگت IdentityModel را به پروژهی Mvc Client اضافه کنیم:
توسط این بسته میتوان به DiscoveryClient دسترسی یافت و به کمک آن آدرس UserInfo Endpoint را استخراج میکنیم:
در اینجا یک اکشن متد جدید را جهت سفارش نگارش قاب شدهی تصاویر گالری اضافه کردهایم. کار این اکشن متد، دریافت آخرین آدرس شخص از IDP و سپس ارسال آن به View متناظر است. برای این منظور ابتدا یک DiscoveryClient را بر اساس آدرس IDP تشکیل دادهایم. حاصل آن متادیتای این IDP است که یکی از مشخصات آن UserInfoEndpoint میباشد. سپس بر این اساس، UserInfoClient را تشکیل داده و Access token جاری را به سمت این endpoint ارسال میکنیم. حاصل آن، آخرین Claims کاربر است که مستقیما از IDP دریافت شده و از کوکی جاری کاربر خوانده نمیشود. سپس از این لیست، مقدار Claim متناظر با address را استخراج کرده و آنرا به View ارسال میکنیم.
OrderFrameViewModel ارسالی به View، یک چنین شکلی را دارد:
و View متناظر با این اکشن متد در آدرس Views\Gallery\OrderFrame.cshtml به صورت زیر تعریف شدهاست که آدرس شخص را نمایش میدهد:
سپس به Shared\_Layout.cshtml مراجعه کرده و لینکی را به این اکشن متد و View، اضافه میکنیم:
اکنون اگر برنامه را اجرا کنیم، پس از login، یک چنین خروجی قابل مشاهده است:
همانطور که ملاحظه میکنید، آدرس شخص به صورت مستقیم از UserInfo Endpoint دریافت و نمایش داده شدهاست.
بررسی Authorization مبتنی بر نقشها
تا اینجا مرحلهی Authentication را که مشخص میکند کاربر وار شدهی به سیستم کیست، بررسی کردیم که اطلاعات آن از Identity token دریافتی از IDP استخراج میشود. مرحلهی پس از ورود به سیستم، مشخص کردن سطوح دسترسی کاربر و تعیین این مورد است که کاربر مجاز به انجام چه کارهایی میباشد. به این مرحله Authorization میگویند و روشهای مختلفی برای مدیریت آن وجود دارد:
الف) RBAC و یا Role-based Authorization و یا تعیین سطوح دسترسی بر اساس نقشهای کاربر
در این حالت claim ویژهی role، از IDP دریافت شده و توسط آن یکسری سطوح دسترسی کاربر مشخص میشوند. برای مثال کاربر وارد شدهی به سیستم میتواند تصویری را اضافه کند و یا آیا مجاز است نگارش قاب شدهی تصویری را درخواست دهد؟
ب) ABAC و یا Attribute based access control روش دیگر مدیریت سطوح دسترسی است و عموما آنرا نسبت به حالت الف ترجیح میدهند که آنرا در قسمتهای بعدی بررسی خواهیم کرد.
در اینجا روش «تعیین سطوح دسترسی بر اساس نقشهای کاربر» را بررسی میکنیم. برای این منظور به تنظیمات IDP در فایل src\IDP\DNT.IDP\Config.cs مراجعه کرده و claims جدیدی را تعریف میکنیم:
در اینجا دو نقش FreeUser و PayingUser به صورت claimهایی جدید به دو کاربر IDP اضافه شدهاند.
سپس باید برای این claim جدید یک scope جدید را نیز به قسمت GetIdentityResources اضافه کنیم تا توسط client قابل دریافت شود:
چون roles یکی از scopeهای استاندارد نیست، آنرا به صورت یک IdentityResource سفارشی تعریف کردهایم. زمانیکه scope ای به نام roles درخواست میشود، لیستی از نوع claimTypes بازگشت داده خواهد شد.
همچنین باید به کلاینت مجوز درخواست این scope را نیز بدهیم. به همین جهت آنرا به AllowedScopes مشخصات Client نیز اضافه میکنیم:
در ادامه قرار است تنها کاربری که دارای نقش PayingUser است، امکان دسترسی به سفارش نگارش قاب شدهی تصاویر را داشته باشد. به همین جهت به کلاس ImageGallery.MvcClient.WebApp\Startup.cs برنامهی کلاینت مراجعه کرده و درخواست scope نقشهای کاربر را به متد تنظیمات AddOpenIdConnect اضافه میکنیم:
برای آزمایش آن، یکبار از برنامه خارج شده و مجددا به آن وارد شوید. اینبار در صفحهی consent، از کاربر مجوز دسترسی به نقشهای او نیز سؤال پرسیده میشود:
اما اگر به لیست موجود در this.User.Claims در برنامهی کلاینت مراجعه کنیم، نقش او را مشاهده نخواهیم کرد و به این لیست اضافه نشدهاست:
همانطور که در نکتهای پیشتر نیز ذکر شد، چون role جزو لیست نگاشتهای OpenID Connect Options مایکروسافت نیست، آنرا به صورت خودکار به لیست claims اضافه نمیکند؛ دقیقا مانند آدرسی که بررسی کردیم. برای رفع این مشکل و افزودن نگاشت آن در متد تنظیمات AddOpenIdConnect، میتوان از متد MapUniqueJsonKey به صورت زیر استفاده کرد:
برای آزمایش آن، یکبار از برنامه خارج شده و مجددا به آن وارد شوید. اینبار لیست this.User.Claims به صورت زیر تغییر کردهاست که شامل role نیز میباشد:
استفاده از نقش تعریف شده جهت محدود کردن دسترسی به سفارش تصاویر قاب شده
در ادامه قصد داریم لینک درخواست تصاویر قاب شده را فقط برای کاربرانی که دارای نقش PayingUser هستند، نمایش دهیم. به همین جهت به فایل Views\Shared\_Layout.cshtml مراجعه کرده و آنرا به صورت زیر تغییر میدهیم:
در این حالت از متد استاندارد User.IsInRole برای بررسی نقش کاربر جاری استفاده شدهاست. اما این متد هنوز نمیداند که نقشها را باید از کجا دریافت کند و اگر آنرا آزمایش کنید، کار نمیکند. برای تکمیل آن به فایل ImageGallery.MvcClient.WebApp\Startup.cs مراجعه کرده تنظیمات متد AddOpenIdConnect را به صورت زیر تغییر میدهیم:
TokenValidationParameters نحوهی اعتبارسنجی توکن دریافتی از IDP را مشخص میکند. همچنین مشخص میکند که چه نوع claim ای از token دریافتی از IDP به RoleClaimType سمت ASP.NET Core نگاشت شود.
اکنون برای آزمایش آن یکبار از سیستم خارج شده و مجددا به آن وارد شوید. پس از آن لینک درخواست نگارش قاب شدهی تصاویر، برای کاربر User 1 نمایان خواهد بود و نه برای User 2 که FreeUser است.
البته هرچند تا این لحظه لینک نمایش View متناظر با اکشن متد OrderFrame را امن کردهایم، اما هنوز خود این اکشن متد به صورت مستقیم با وارد کردن آدرس https://localhost:5001/Gallery/OrderFrame در مرورگر قابل دسترسی است. برای رفع این مشکل به کنترلر گالری مراجعه کرده و دسترسی به اکشن متد OrderFrame را توسط فیلتر Authorize و با مقدار دهی خاصیت Roles آن محدود میکنیم:
خاصیت Roles فیلتر Authorize، میتواند چندین نقش جدا شدهی توسط کاما را نیز دریافت کند.
برای آزمایش آن، توسط مشخصات کاربر User 2 به سیستم وارد شده و آدرس https://localhost:5001/Gallery/OrderFrame را مستقیما در مرورگر وارد کنید. در این حالت یک چنین تصویری نمایان خواهد شد:
همانطور که مشاهده میکنید، علاوه بر عدم دسترسی به این اکشن متد، به صفحهی Account/AccessDenied که هنوز در برنامهی کلاینت تعریف نشدهاست، هدایت شدهایم. به همین جهت خطای 404 و یا یافت نشد، نمایش داده شدهاست.
برای تغییر مقدار پیشفرض صفحهی عدم دسترسی، ابتدا Controllers\AuthorizationController.cs را با این محتوا ایجاد میکنیم:
سپس View آنرا در فایل Views\Authorization\AccessDenied.cshtml به صورت زیر تکمیل خواهیم کرد که لینک به logout نیز در آن وجود دارد:
اکنون نیاز است تا این آدرس جدید را به کلاس ImageGallery.MvcClient.WebApp\Startup.cs معرفی کنیم.
آدرس جدید Authorization/AccessDenied باید به تنظیمات AddCookie اضافه شود تا توسط سیستم شناخته شده و مورد استفاده قرار گیرد. علت اینجا است که role claims، از کوکی رمزنگاری شدهی برنامه استخراج میشوند. به همین جهت تنظیم آن مرتبط است به AddCookie.
برای آزمایش آن، یکبار از برنامه خارج شده و مجددا با اکانت User 2 به آن وارد شوید و آدرس https://localhost:5001/Gallery/OrderFrame را مستقیما در مرورگر وارد کنید. اینبار تصویر زیر که همان آدرس جدید تنظیم شدهاست نمایش داده خواهد شد:
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید.
برای اجرای برنامه:
- ابتدا به پوشهی 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 وارد کنید.
بررسی Claims Transformations
میخواهیم Claims بازگشت داده شدهی توسط IDP را به یکسری Claims که کار کردن با آنها در برنامهی MVC Client سادهتر است، تبدیل کنیم.
زمانیکه اطلاعات Claim، توسط میانافزار oidc دریافت میشود، ابتدا بررسی میشود که آیا دیکشنری نگاشتها وجود دارد یا خیر؟ اگر بله، کار نگاشتها از یک claim type به claim type دیگر انجام میشود.
برای مثال لیست claims اصلی بازگشت داده شدهی توسط IDP، پس از تبدیلات و نگاشتهای آن در برنامهی کلاینت، یک چنین شکلی را پیدا میکند:
Claim type: sid - Claim value: f3940d6e58cbb576669ee49c90e22cb1 Claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier - Claim value: d860efca-22d9-47fd-8249-791ba61b07c7 Claim type: http://schemas.microsoft.com/identity/claims/identityprovider - Claim value: local Claim type: http://schemas.microsoft.com/claims/authnmethodsreferences - Claim value: pwd Claim type: given_name - Claim value: Vahid Claim type: family_name - Claim value: N
namespace ImageGallery.MvcClient.WebApp { public class Startup { public Startup(IConfiguration configuration) { Configuration = configuration; JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear(); }
در ادامه اگر مجددا لیست claims را پس از logout و login، بررسی کنیم، به این صورت تبدیل شدهاست:
• Claim type: sid - Claim value: 91f5a09da5cdbbe18762526da1b996fb • Claim type: sub - Claim value: d860efca-22d9-47fd-8249-791ba61b07c7 • Claim type: idp - Claim value: local • Claim type: given_name - Claim value: Vahid • Claim type: family_name - Claim value: N
کار با مجموعهی User Claims
تا اینجا لیست this.User.Claims، به همراه تعدادی Claims است که به آنها نیازی نداریم؛ مانند sid که بیانگر session id در سمت IDP است و یا idp به معنای identity provider میباشد. حذف آنها حجم کوکی نگهداری کنندهی آنها را کاهش میدهد. همچنین میخواهیم تعدادی دیگر را نیز به آنها اضافه کنیم.
علاوه بر اینها میانافزار oidc، یکسری از claims دریافتی را راسا فیلتر و حذف میکند؛ مانند زمان منقضی شدن توکن و امثال آن که در عمل واقعا به تعدادی از آنها نیازی نداریم. اما میتوان این سطح تصمیم گیری فیلتر claims رسیده را نیز کنترل کرد. در تنظیمات متد AddOpenIdConnect، خاصیت options.ClaimActions نیز وجود دارد که توسط آن میتوان بر روی حذف و یا افزوده شدن Claims، کنترل بیشتری را اعمال کرد:
namespace ImageGallery.MvcClient.WebApp { public void ConfigureServices(IServiceCollection services) { // ... .AddOpenIdConnect("oidc", options => { // ... options.ClaimActions.Remove("amr"); options.ClaimActions.DeleteClaim("sid"); options.ClaimActions.DeleteClaim("idp"); }); }
اکنون اگر پس از logout و login، لیست this.User.Claims را بررسی کنیم، دیگر خبری از sid و idp در آن نیست. همچنین claim از نوع amr نیز به صورت پیشفرض حذف نشدهاست:
• Claim type: sub - Claim value: d860efca-22d9-47fd-8249-791ba61b07c7 • Claim type: amr - Claim value: pwd • Claim type: given_name - Claim value: Vahid • Claim type: family_name - Claim value: N
افزودن Claim جدید آدرس کاربر
برای افزودن Claim جدید آدرس کاربر، به کلاس src\IDP\DNT.IDP\Config.cs مراجعه کرده و آنرا به صورت زیر تکمیل میکنیم:
namespace DNT.IDP { public static class Config { // identity-related resources (scopes) public static IEnumerable<IdentityResource> GetIdentityResources() { return new List<IdentityResource> { new IdentityResources.OpenId(), new IdentityResources.Profile(), new IdentityResources.Address() }; }
همین مورد را به لیست AllowedScopes متد GetClients نیز اضافه میکنیم:
AllowedScopes = { IdentityServerConstants.StandardScopes.OpenId, IdentityServerConstants.StandardScopes.Profile, IdentityServerConstants.StandardScopes.Address },
namespace DNT.IDP { public static class Config { public static List<TestUser> GetUsers() { return new List<TestUser> { new TestUser { // ... Claims = new List<Claim> { // ... new Claim("address", "Main Road 1") } }, new TestUser { // ... Claims = new List<Claim> { // ... new Claim("address", "Big Street 2") } } }; }
پس از آن به کلاس ImageGallery.MvcClient.WebApp\Startup.cs مراجعه میکنیم تا درخواست این claim را به لیست scopes میانافزار oidc اضافه کنیم:
namespace ImageGallery.MvcClient.WebApp { public class Startup { public void ConfigureServices(IServiceCollection services) { // ... .AddOpenIdConnect("oidc", options => { // ... options.Scope.Add("address"); // … options.ClaimActions.DeleteClaim("address"); }); }
یک نکته: فراخوانی DeleteClaim بر روی address غیر ضروری است و میشود این سطر را حذف کرد. از این جهت که اگر به سورس OpenID Connect Options مایکروسافت مراجعه کنیم، مشاهده خواهیم کرد که میانافزار اعتبارسنجی استاندارد ASP.NET Core، تنها تعداد معدودی از claims را نگاشت میکند. به این معنا که هر claim ای که در token وجود داشته باشد، اما اینجا نگاشت نشده باشد، در claims نهایی حضور نخواهند داشت و address claim یکی از اینها نیست. بنابراین در لیست نهایی this.User.Claims حضور نخواهد داشت؛ مگر اینکه مطابق همین سورس، با استفاده از متد options.ClaimActions.MapUniqueJsonKey، یک نگاشت جدید را برای آن تهیه کنیم و البته چون نمیخواهیم آدرس در لیست claims وجود داشته باشد، این نگاشت را تعریف نخواهیم کرد.
دریافت اطلاعات بیشتری از کاربران از طریق UserInfo Endpoint
همانطور که در قسمت قبل با بررسی «تنظیمات بازگشت Claims کاربر به برنامهی کلاینت» عنوان شد، میانافزار oidc با UserInfo Endpoint کار میکند که تمام عملیات آن خودکار است. در اینجا امکان کار با آن از طریق برنامه نویسی مستقیم نیز جهت دریافت اطلاعات بیشتری از کاربران، وجود دارد. برای مثال شاید به دلایل امنیتی نخواهیم آدرس کاربر را در لیست Claims او قرار دهیم. این مورد سبب کوچکتر شدن کوکی متناظر با این اطلاعات و همچنین دسترسی به اطلاعات به روزتری از کاربر میشود.
درخواستی که به سمت UserInfo Endpoint ارسال میشود، باید یک چنین فرمتی را داشته باشد:
GET idphostaddress/connect/userinfo Authorization: Bearer R9aty5OPlk
اکنون برای دریافت دستی اطلاعات آدرس از IDP و UserInfo Endpoint آن، ابتدا نیاز است بستهی نیوگت IdentityModel را به پروژهی Mvc Client اضافه کنیم:
dotnet add package IdentityModel
namespace ImageGallery.MvcClient.WebApp.Controllers { [Authorize] public class GalleryController : Controller { public async Task<IActionResult> OrderFrame() { var discoveryClient = new DiscoveryClient(_configuration["IDPBaseAddress"]); var metaDataResponse = await discoveryClient.GetAsync(); var userInfoClient = new UserInfoClient(metaDataResponse.UserInfoEndpoint); var accessToken = await HttpContext.GetTokenAsync(OpenIdConnectParameterNames.AccessToken); var response = await userInfoClient.GetAsync(accessToken); if (response.IsError) { throw new Exception("Problem accessing the UserInfo endpoint.", response.Exception); } var address = response.Claims.FirstOrDefault(c => c.Type == "address")?.Value; return View(new OrderFrameViewModel(address)); }
OrderFrameViewModel ارسالی به View، یک چنین شکلی را دارد:
namespace ImageGallery.MvcClient.ViewModels { public class OrderFrameViewModel { public string Address { get; } = string.Empty; public OrderFrameViewModel(string address) { Address = address; } } }
@model ImageGallery.MvcClient.ViewModels.OrderFrameViewModel <div class="container"> <div class="h3 bottomMarginDefault">Order a framed version of your favorite picture.</div> <div class="text bottomMarginSmall">We've got this address on record for you:</div> <div class="text text-info bottomMarginSmall">@Model.Address</div> <div class="text">If this isn't correct, please contact us.</div> </div>
سپس به Shared\_Layout.cshtml مراجعه کرده و لینکی را به این اکشن متد و View، اضافه میکنیم:
<li><a asp-area="" asp-controller="Gallery" asp-action="OrderFrame">Order a framed picture</a></li>
اکنون اگر برنامه را اجرا کنیم، پس از login، یک چنین خروجی قابل مشاهده است:
همانطور که ملاحظه میکنید، آدرس شخص به صورت مستقیم از UserInfo Endpoint دریافت و نمایش داده شدهاست.
بررسی Authorization مبتنی بر نقشها
تا اینجا مرحلهی Authentication را که مشخص میکند کاربر وار شدهی به سیستم کیست، بررسی کردیم که اطلاعات آن از Identity token دریافتی از IDP استخراج میشود. مرحلهی پس از ورود به سیستم، مشخص کردن سطوح دسترسی کاربر و تعیین این مورد است که کاربر مجاز به انجام چه کارهایی میباشد. به این مرحله Authorization میگویند و روشهای مختلفی برای مدیریت آن وجود دارد:
الف) RBAC و یا Role-based Authorization و یا تعیین سطوح دسترسی بر اساس نقشهای کاربر
در این حالت claim ویژهی role، از IDP دریافت شده و توسط آن یکسری سطوح دسترسی کاربر مشخص میشوند. برای مثال کاربر وارد شدهی به سیستم میتواند تصویری را اضافه کند و یا آیا مجاز است نگارش قاب شدهی تصویری را درخواست دهد؟
ب) ABAC و یا Attribute based access control روش دیگر مدیریت سطوح دسترسی است و عموما آنرا نسبت به حالت الف ترجیح میدهند که آنرا در قسمتهای بعدی بررسی خواهیم کرد.
در اینجا روش «تعیین سطوح دسترسی بر اساس نقشهای کاربر» را بررسی میکنیم. برای این منظور به تنظیمات IDP در فایل src\IDP\DNT.IDP\Config.cs مراجعه کرده و claims جدیدی را تعریف میکنیم:
namespace DNT.IDP { public static class Config { public static List<TestUser> GetUsers() { return new List<TestUser> { new TestUser { //... Claims = new List<Claim> { //... new Claim("role", "PayingUser") } }, new TestUser { //... Claims = new List<Claim> { //... new Claim("role", "FreeUser") } } }; }
سپس باید برای این claim جدید یک scope جدید را نیز به قسمت GetIdentityResources اضافه کنیم تا توسط client قابل دریافت شود:
namespace DNT.IDP { public static class Config { public static IEnumerable<IdentityResource> GetIdentityResources() { return new List<IdentityResource> { // ... new IdentityResource( name: "roles", displayName: "Your role(s)", claimTypes: new List<string>() { "role" }) }; }
همچنین باید به کلاینت مجوز درخواست این scope را نیز بدهیم. به همین جهت آنرا به AllowedScopes مشخصات Client نیز اضافه میکنیم:
namespace DNT.IDP { public static class Config { public static IEnumerable<Client> GetClients() { return new List<Client> { new Client { // ... AllowedScopes = { // ... "roles" } // ... } }; }
در ادامه قرار است تنها کاربری که دارای نقش PayingUser است، امکان دسترسی به سفارش نگارش قاب شدهی تصاویر را داشته باشد. به همین جهت به کلاس ImageGallery.MvcClient.WebApp\Startup.cs برنامهی کلاینت مراجعه کرده و درخواست scope نقشهای کاربر را به متد تنظیمات AddOpenIdConnect اضافه میکنیم:
options.Scope.Add("roles");
برای آزمایش آن، یکبار از برنامه خارج شده و مجددا به آن وارد شوید. اینبار در صفحهی consent، از کاربر مجوز دسترسی به نقشهای او نیز سؤال پرسیده میشود:
اما اگر به لیست موجود در this.User.Claims در برنامهی کلاینت مراجعه کنیم، نقش او را مشاهده نخواهیم کرد و به این لیست اضافه نشدهاست:
• Claim type: sub - Claim value: d860efca-22d9-47fd-8249-791ba61b07c7 • Claim type: amr - Claim value: pwd • Claim type: given_name - Claim value: Vahid • Claim type: family_name - Claim value: N
همانطور که در نکتهای پیشتر نیز ذکر شد، چون role جزو لیست نگاشتهای OpenID Connect Options مایکروسافت نیست، آنرا به صورت خودکار به لیست claims اضافه نمیکند؛ دقیقا مانند آدرسی که بررسی کردیم. برای رفع این مشکل و افزودن نگاشت آن در متد تنظیمات AddOpenIdConnect، میتوان از متد MapUniqueJsonKey به صورت زیر استفاده کرد:
options.ClaimActions.MapUniqueJsonKey(claimType: "role", jsonKey: "role");
• Claim type: sub - Claim value: d860efca-22d9-47fd-8249-791ba61b07c7 • Claim type: amr - Claim value: pwd • Claim type: given_name - Claim value: Vahid • Claim type: family_name - Claim value: N • Claim type: role - Claim value: PayingUser
استفاده از نقش تعریف شده جهت محدود کردن دسترسی به سفارش تصاویر قاب شده
در ادامه قصد داریم لینک درخواست تصاویر قاب شده را فقط برای کاربرانی که دارای نقش PayingUser هستند، نمایش دهیم. به همین جهت به فایل Views\Shared\_Layout.cshtml مراجعه کرده و آنرا به صورت زیر تغییر میدهیم:
@if(User.IsInRole("PayingUser")) { <li><a asp-area="" asp-controller="Gallery" asp-action="OrderFrame">Order a framed picture</a></li> }
options.TokenValidationParameters = new TokenValidationParameters { NameClaimType = JwtClaimTypes.GivenName, RoleClaimType = JwtClaimTypes.Role, };
اکنون برای آزمایش آن یکبار از سیستم خارج شده و مجددا به آن وارد شوید. پس از آن لینک درخواست نگارش قاب شدهی تصاویر، برای کاربر User 1 نمایان خواهد بود و نه برای User 2 که FreeUser است.
البته هرچند تا این لحظه لینک نمایش View متناظر با اکشن متد OrderFrame را امن کردهایم، اما هنوز خود این اکشن متد به صورت مستقیم با وارد کردن آدرس https://localhost:5001/Gallery/OrderFrame در مرورگر قابل دسترسی است. برای رفع این مشکل به کنترلر گالری مراجعه کرده و دسترسی به اکشن متد OrderFrame را توسط فیلتر Authorize و با مقدار دهی خاصیت Roles آن محدود میکنیم:
namespace ImageGallery.MvcClient.WebApp.Controllers { [Authorize] public class GalleryController : Controller { [Authorize(Roles = "PayingUser")] public async Task<IActionResult> OrderFrame() {
برای آزمایش آن، توسط مشخصات کاربر User 2 به سیستم وارد شده و آدرس https://localhost:5001/Gallery/OrderFrame را مستقیما در مرورگر وارد کنید. در این حالت یک چنین تصویری نمایان خواهد شد:
همانطور که مشاهده میکنید، علاوه بر عدم دسترسی به این اکشن متد، به صفحهی Account/AccessDenied که هنوز در برنامهی کلاینت تعریف نشدهاست، هدایت شدهایم. به همین جهت خطای 404 و یا یافت نشد، نمایش داده شدهاست.
برای تغییر مقدار پیشفرض صفحهی عدم دسترسی، ابتدا Controllers\AuthorizationController.cs را با این محتوا ایجاد میکنیم:
using Microsoft.AspNetCore.Mvc; public class AuthorizationController : Controller { public IActionResult AccessDenied() { return View(); } }
<div class="container"> <div class="h3">Woops, looks like you're not authorized to view this page.</div> <div>Would you prefer to <a asp-controller="Gallery" asp-action="Logout">log in as someone else</a>?</div> </div>
اکنون نیاز است تا این آدرس جدید را به کلاس ImageGallery.MvcClient.WebApp\Startup.cs معرفی کنیم.
namespace ImageGallery.MvcClient.WebApp { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddAuthentication(options => { // ... }).AddCookie("Cookies", options => { options.AccessDeniedPath = "/Authorization/AccessDenied"; }) // ...
برای آزمایش آن، یکبار از برنامه خارج شده و مجددا با اکانت User 2 به آن وارد شوید و آدرس https://localhost:5001/Gallery/OrderFrame را مستقیما در مرورگر وارد کنید. اینبار تصویر زیر که همان آدرس جدید تنظیم شدهاست نمایش داده خواهد شد:
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید.
برای اجرای برنامه:
- ابتدا به پوشهی 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 وارد کنید.
روش مرسوم اعتبارسنجی اطلاعات مدلهای ASP.NET Core، با استفاده از data annotations توکار آن است که در بسیاری از موارد هم به خوبی کار میکند. اما اگر به دنبال ویژگیهای دیگری مانند نوشتن آزمونهای واحد برای اعتبارسنجی اطلاعات، جداسازی شرطهای اعتبارسنجی از تعاریف مدلها، نوشتن اعتبارسنجیهای پیچیده به همراه تزریق وابستگیها هستید، کتابخانهی FluentValidation میتواند جایگزین بهتر و بسیار کاملتری باشد.
نصب کتابخانهی FluentValidation در پروژه
فرض کنید پروژهی ما از سه پوشهی FluentValidationSample.Web، FluentValidationSample.Models و FluentValidationSample.Services تشکیل شدهاست که اولی یک پروژهی MVC است و دو مورد دیگر classlib هستند.
در پروژهی FluentValidationSample.Models، بستهی نیوگت کتابخانهی FluentValidation را به صورت زیر نصب میکنیم:
جایگزین کردن سیستم اعتبارسنجی مبتنی بر DataAnnotations با FluentValidation
اکنون فرض کنید در پروژهی Models، مدل ثبتنام زیر را اضافه کردهایم که از همان data annotations توکار و استاندارد ASP.NET Core برای اعتبارسنجی اطلاعات استفاده میکند:
برای جایگزین کردن data annotations اعتبارسنجی اطلاعات با روش FluentValidation، میتوان به صورت زیر عمل کرد:
برای این منظور ابتدا یک کلاس Validator را با ارث بری از AbstractValidator از نوع مدلی که میخواهیم قواعد اعتبارسنجی آنرا مشخص کنیم، ایجاد میکنیم. سپس در سازندهی آن، میتوان به متدهای تعریف شدهی در این کلاس پایه دسترسی یافت.
در اینجا در ابتدا به ازای هر خاصیت کلاس مدل مدنظر، یک RuleFor تعریف میشود که با استفاده از static reflection، امکان تعریف strongly typed آنها وجود دارد. سپس ویژگی Required به متد NotNull تبدیل میشود و ویژگی StringLength توسط متد Length قابل تعریف خواهد بود و یا ویژگی Compare توسط متد Equal به صورت strongly typed به خاصیت دیگری متصل میشود.
پس از این تعاریف، میتوان ویژگیهای اعتبارسنجی اطلاعات را از مدل ثبت نام حذف کرد و تنها ویژگیهای خاص Viewهای MVC را در صورت نیاز باقی گذاشت:
تعریف پیامهای سفارشی اعتبارسنجی
روش تعریف پیامهای سفارشی شکست اعتبارسنجی اطلاعات را توسط متد WithMessage در ادامه مشاهده میکنید:
به ازای هر متد تعریف یک قاعدهی اعتبارسنجی جدید، بلافاصله میتوان از متد WithMessage نیز استفاده کرد. همچنین این متد میتواند به اطلاعات اصل model دریافتی نیز همانند پیام سفارشی مرتبط با MinimumLength نام کاربری، دسترسی پیدا کند.
روش تعریف اعتبارسنجیهای سفارشی خواص مدل
فرض کنید میخواهیم یک کلمهی عبور وارد شدهی معتبر، حتما از جمع حروف کوچک، بزرگ، اعداد و symbols تشکیل شده باشد. برای این منظور میتوان از متد Must استفاده کرد:
متد Must، میتواند مقدار خاصیت متناظر را نیز در اختیار ما قرار دهد و بر اساس آن مقدار میتوان خروجی true/false ای را بازگشت داد تا نشان شکست و یا موفقیت آمیز بودن اعتبارسنجی اطلاعات باشد.
البته lambda expression نوشته شده را میتوان توسط method groups، به صورت زیر نیز خلاصه نوشت:
انتقال تعاریف اعتبارسنجهای سفارشی خواص به کلاسهای مجزا
اگر نیاز به استفادهی از متد hasValidPassword در کلاسهای دیگری نیز وجود دارد، میتوان اینگونه اعتبارسنجیهای سفارشی را به کلاسهای مجزایی نیز تبدیل کرد. برای مثال فرض کنید که میخواهیم ایمیل دریافت شده، فقط از یک دومین خاص قابل قبول باشد.
برای این منظور یک کلاس جدید را با ارثبری از PropertyValidator تعریف شدهی در فضای نام FluentValidation.Validators، ایجاد میکنیم. سپس متد IsValid آنرا بازنویسی میکنیم تا برای مثال ایمیلها را صرفا از دومین خاصی بپذیرد.
PropertyValidatorContext امکان دسترسی به نام و مقدار خاصیت در حال اعتبارسنجی را میسر میکند. همچنین مقدار کل model جاری را نیز به صورت یک object در اختیار ما قرار میدهد.
اکنون برای استفادهی از آن میتوان از متد SetValidator استفاده کرد:
و یا حتی میتوان یک متد الحاقی fluent را نیز برای آن طراحی کرد تا SetValidator را به صورت خودکار فراخوانی کند:
سپس تعریف قاعدهی اعتبارسنجی ایمیلها به صورت زیر تغییر میکند:
تعریف قواعد اعتبارسنجی خواص تو در تو و لیستی
فرض کنید به RegisterModel این قسمت، دو خاصیت آدرس و شماره تلفنها نیز اضافه شدهاست که یکی به شیء آدرس و دیگری به مجموعهای از آدرسها اشاره میکند:
در یک چنین حالتی، ابتدا به صورت متداول، قواعد اعتبارسنجی Phone و Address را جداگانه تعریف میکنیم:
سپس برای تعریف اعتبارسنجی دو خاصیت پیچیدهی اضافه شده، میتوان از همان متد SetValidator استفاده کرد که اینبار پارامتر ورودی آن، نمونهای از AbstractValidatorهای هرکدام است. البته برای خاصیت مجموعهای اینبار باید با متد RuleForEach شروع کرد:
در قسمت بعد، روشهای مختلف استفادهی از قواعد اعتبارسنجی تعریف شده را در یک برنامهی ASP.NET Core بررسی میکنیم.
برای مطالعهی بیشتر
- «FluentValidation #1»
نصب کتابخانهی FluentValidation در پروژه
فرض کنید پروژهی ما از سه پوشهی FluentValidationSample.Web، FluentValidationSample.Models و FluentValidationSample.Services تشکیل شدهاست که اولی یک پروژهی MVC است و دو مورد دیگر classlib هستند.
در پروژهی FluentValidationSample.Models، بستهی نیوگت کتابخانهی FluentValidation را به صورت زیر نصب میکنیم:
dotnet add package FluentValidation.AspNetCore
جایگزین کردن سیستم اعتبارسنجی مبتنی بر DataAnnotations با FluentValidation
اکنون فرض کنید در پروژهی Models، مدل ثبتنام زیر را اضافه کردهایم که از همان data annotations توکار و استاندارد ASP.NET Core برای اعتبارسنجی اطلاعات استفاده میکند:
using System.ComponentModel.DataAnnotations; namespace FluentValidationSample.Models { public class RegisterModel { [Required] [Display(Name = "User name")] public string UserName { get; set; } [Required] [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)] [DataType(DataType.Password)] [Display(Name = "Password")] public string Password { get; set; } [DataType(DataType.Password)] [Display(Name = "Confirm password")] [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")] public string ConfirmPassword { get; set; } [DataType(DataType.EmailAddress)] [Display(Name = "Email")] [EmailAddress] public string Email { get; set; } [Range(18, 60)] [Display(Name = "Age")] public int Age { get; set; } } }
using FluentValidation; namespace FluentValidationSample.Models { public class RegisterModelValidator : AbstractValidator<RegisterModel> { public RegisterModelValidator() { RuleFor(x => x.UserName).NotNull(); RuleFor(x => x.Password).NotNull().Length(6, 100); RuleFor(x => x.ConfirmPassword).Equal(x => x.Password); RuleFor(x => x.Email).EmailAddress(); RuleFor(x => x.Age).InclusiveBetween(18, 60); } } }
در اینجا در ابتدا به ازای هر خاصیت کلاس مدل مدنظر، یک RuleFor تعریف میشود که با استفاده از static reflection، امکان تعریف strongly typed آنها وجود دارد. سپس ویژگی Required به متد NotNull تبدیل میشود و ویژگی StringLength توسط متد Length قابل تعریف خواهد بود و یا ویژگی Compare توسط متد Equal به صورت strongly typed به خاصیت دیگری متصل میشود.
پس از این تعاریف، میتوان ویژگیهای اعتبارسنجی اطلاعات را از مدل ثبت نام حذف کرد و تنها ویژگیهای خاص Viewهای MVC را در صورت نیاز باقی گذاشت:
using System.ComponentModel.DataAnnotations; namespace FluentValidationSample.Models { public class RegisterModel { [Display(Name = "User name")] public string UserName { get; set; } [DataType(DataType.Password)] [Display(Name = "Password")] public string Password { get; set; } [DataType(DataType.Password)] [Display(Name = "Confirm password")] public string ConfirmPassword { get; set; } [DataType(DataType.EmailAddress)] [Display(Name = "Email")] public string Email { get; set; } [Display(Name = "Age")] public int Age { get; set; } } }
تعریف پیامهای سفارشی اعتبارسنجی
روش تعریف پیامهای سفارشی شکست اعتبارسنجی اطلاعات را توسط متد WithMessage در ادامه مشاهده میکنید:
using FluentValidation; namespace FluentValidationSample.Models { public class RegisterModelValidator : AbstractValidator<RegisterModel> { public RegisterModelValidator() { RuleFor(x => x.UserName) .NotNull() .WithMessage("Your first name is required.") .MaximumLength(20) .WithMessage("Your first name is too long!") .MinimumLength(3) .WithMessage(registerModel => $"Your first name `{registerModel.UserName}` is too short!"); RuleFor(x => x.Password) .NotNull() .WithMessage("Your password is required.") .Length(6, 100); RuleFor(x => x.ConfirmPassword) .NotNull() .WithMessage("Your confirmation password is required.") .Equal(x => x.Password) .WithMessage("The password and confirmation password do not match."); RuleFor(x => x.Email).EmailAddress(); RuleFor(x => x.Age).InclusiveBetween(18, 60); } } }
روش تعریف اعتبارسنجیهای سفارشی خواص مدل
فرض کنید میخواهیم یک کلمهی عبور وارد شدهی معتبر، حتما از جمع حروف کوچک، بزرگ، اعداد و symbols تشکیل شده باشد. برای این منظور میتوان از متد Must استفاده کرد:
using System.Text.RegularExpressions; using FluentValidation; namespace FluentValidationSample.Models { public class RegisterModelValidator : AbstractValidator<RegisterModel> { public RegisterModelValidator() { RuleFor(x => x.Password) .NotNull() .WithMessage("Your password is required.") .Length(6, 100) .Must(password => hasValidPassword(password)); //... } private static bool hasValidPassword(string password) { var lowercase = new Regex("[a-z]+"); var uppercase = new Regex("[A-Z]+"); var digit = new Regex("(\\d)+"); var symbol = new Regex("(\\W)+"); return lowercase.IsMatch(password) && uppercase.IsMatch(password) && digit.IsMatch(password) && symbol.IsMatch(password); } } }
البته lambda expression نوشته شده را میتوان توسط method groups، به صورت زیر نیز خلاصه نوشت:
RuleFor(x => x.Password) .NotNull() .WithMessage("Your password is required.") .Length(6, 100) .Must(hasValidPassword);
اگر نیاز به استفادهی از متد hasValidPassword در کلاسهای دیگری نیز وجود دارد، میتوان اینگونه اعتبارسنجیهای سفارشی را به کلاسهای مجزایی نیز تبدیل کرد. برای مثال فرض کنید که میخواهیم ایمیل دریافت شده، فقط از یک دومین خاص قابل قبول باشد.
using System; using FluentValidation; using FluentValidation.Validators; namespace FluentValidationSample.Models { public class EmailFromDomainValidator : PropertyValidator { private readonly string _domain; public EmailFromDomainValidator(string domain) : base("Email address {PropertyValue} is not from domain {domain}") { _domain = domain; } protected override bool IsValid(PropertyValidatorContext context) { if (context.PropertyValue == null) return false; var split = context.PropertyValue.ToString().Split('@'); return split.Length == 2 && split[1].Equals(_domain, StringComparison.OrdinalIgnoreCase); } } }
PropertyValidatorContext امکان دسترسی به نام و مقدار خاصیت در حال اعتبارسنجی را میسر میکند. همچنین مقدار کل model جاری را نیز به صورت یک object در اختیار ما قرار میدهد.
اکنون برای استفادهی از آن میتوان از متد SetValidator استفاده کرد:
RuleFor(x => x.Email) .SetValidator(new EmailFromDomainValidator("gmail.com"));
public static class CustomValidatorExtensions { public static IRuleBuilderOptions<T, string> EmailAddressFromDomain<T>( this IRuleBuilder<T, string> ruleBuilder, string domain) { return ruleBuilder.SetValidator(new EmailFromDomainValidator(domain)); } }
RuleFor(x => x.Email).EmailAddressFromDomain("gmail.com");
فرض کنید به RegisterModel این قسمت، دو خاصیت آدرس و شماره تلفنها نیز اضافه شدهاست که یکی به شیء آدرس و دیگری به مجموعهای از آدرسها اشاره میکند:
public class RegisterModel { // ... public Address Address { get; set; } public ICollection<Phone> Phones { get; set; } } public class Phone { public string Number { get; set; } public string Description { get; set; } } public class Address { public string Location { get; set; } public string PostalCode { get; set; } }
public class PhoneValidator : AbstractValidator<Phone> { public PhoneValidator() { RuleFor(x => x.Number).NotNull(); } } public class AddressValidator : AbstractValidator<Address> { public AddressValidator() { RuleFor(x => x.PostalCode).NotNull(); RuleFor(x => x.Location).NotNull(); } }
public class RegisterModelValidator : AbstractValidator<RegisterModel> { public RegisterModelValidator() { // ... RuleFor(x => x.Address).SetValidator(new AddressValidator()); RuleForEach(x => x.Phones).SetValidator(new PhoneValidator()); }
در قسمت بعد، روشهای مختلف استفادهی از قواعد اعتبارسنجی تعریف شده را در یک برنامهی ASP.NET Core بررسی میکنیم.
برای مطالعهی بیشتر
- «FluentValidation #1»
نظرات مطالب
راه اندازی StimulSoft Report در ASP.NET MVC
- کار کردن با T4MVC به سادگی ذیل است (همیشه از پارامتر result آن استفاده کنید):
- این مطلب را هم برای دیباگ مدنظر داشته باشید: «نحوه استفاده از افزونه Firebug برای دیباگ برنامههای ASP.NET مبتنی بر jQuery »
GetReportSnapshot = Url.Action(result: MVC.Report.CustomReportSnapshot()), //...
اشتراکها
پیاده سازی CQRS در .NET
امکان اندازه گیری دقیق حجم ViewState در برنامههای ASP.NET WebForms وجود دارد (+) ، اما خوب، این روش یک ایراد مهم هم دارد. چند نفر حاضرند تمام صفحات خود را ویرایش کرده و ارث بری ذکر شده را پیاده سازی کنند؟
یک روش دیگر اعمال آن به تمام صفحات، استفاده از پوشهی استاندارد App_Browsers و سپس ایجاد فایلی مانند ViewStateManager.browser میباشد:
<!--Applies to all pages-->
<browsers>
<browser refID="Default">
<controlAdapters>
<adapter controlType="System.Web.UI.Page" adapterType="ViewStateManagerCore.SomeClass" />
</controlAdapters>
</browser>
</browsers>
علاوه بر این دو روش (ارث بری دستی و ارث بری خودکار)، افزونهای هم برای فایرفاکس جهت نمایش حجم ViewState صفحات طراحی شده است که از آدرس زیر قابل دریافت میباشد :
این موضوع چه اهمیتی دارد؟
ممکن است کاربران سایت شما گاهی از اوقات در بعضی از صفحات با خطای "Validation of viewstate MAC failed" مواجه و متوقف شوند. عموما حجم بالای ViewState این مشکل را درست میکند. حجم ViewState بالا است (چند صد کیلوبایت ...)، صفحه دیر رندر میشود یا هنوز کامل نشده، شخص صفحه را متوقف میکند. ASP.NET در این حالت اجازهی ارسال اطلاعات از این صفحهی ناقص را به دلایل امنیتی نمیدهد که خوب است (شاید جعل شده باشد؟).
پ.ن.
راه حل پیشنهادی مایکروسافت جهت حل این مشکل (شروع شده از سال 2007)، ارتقاء برنامههای شما به ASP.NET MVC میباشد :)
اشتراکها
معماری تمیز در asp.net core
ASP.NET Core provides better support for clean, testable, maintainable architectures than any of its predecessors. Learn the underlying principles that apply to project/solution organization, how best to arrange your projects to support clean code, and how to refactor existing solutions toward this architecture. Examples will use ASP.NET Core but the principles covered apply to all languages and platforms.
در مقاله پیش رو، سعی شدهاست به شکلی تقریبا عملی، کلیاتی در مورد Authentication در MVC5 توضیح داده شود. هدف روشن شدن ابهامات اولیه در هویت سنجی MVC5 و حل شدن مشکلات اولیه برای ایجاد یک پروژه است.
در MVC 4 برای دسترسی به جداول مرتبط با اعتبار سنجی (مثلا لیست کاربران) مجبور به استفاده از متدهای از پیش تعریف شدهی رفرنسهایی که برای آن نوع اعتبار سنجی وجود داشت، بودیم. راه حلی نیز برای دسترسی بهتر وجود داشت و آن هم ساختن مدلهای مشابه آن جدولها و اضافه کردن چند خط کد به برنامه بود. با اینکار دسترسی ساده به Roles و Users برای تغییر و اضافه کردن محتوای آنها ممکن میشد. در لینک زیر توضیحاتی در مورد روش اینکار وجود دارد.[اینجا]
در MVC5 داستان کمی فرق کرده است. برای درک موضوع پروژه ای بسازید و حالت پیش فرض آن را تغییر ندهید و آن را اجرا کنید و ثبت نام را انجام دهید، بلافاصله تصویر زیر در دیتابیس نمایان خواهد شد.
دقت کنید بعد از ایجاد پروژه در MVC5 دو پکیج بصورت اتوماتیک از طریق Nuget به پروژه شما اضافه میشود:
Microsoft.AspNet.Identity.Core Microsoft.AspNet.Identity.EntityFrameWork
اولین پکیج شامل اینترفیسهای IUser و IRole است که شامل فیلدهای مرتبط با این دو میباشد. همچنین اینترفیسی به نام IUserStore وجود دارد که چندین متد داشته و وظیفه اصلی هر نوع اضافه و حذف کردن یا تغییر در کاربران، بر دوش آن است.
دومین پکیج هم وظیفه پیاده سازی آنچیزی را دارد که در پکیج اول معرفی شده است. کلاسهای موجود در این پکیج ابزارهایی برای ارتباط EntityFramework با دیتابیس هستند.
اما از مقدمات فوق که بگذریم برای درک بهتر رفتار با دیتابیس یک مثال را پیاده سازی خواهیم کرد.
فرض کنید میخواهیم چنین ارتباطی را بین سه جدول در دیتابیس برقرار کنیم، فقط به منظور یادآوری، توجه کنید که جدول ASPNetUsers جدولی است که به شکل اتوماتیک پیش از این تولید شد و ما قرار است به کمک یک جدول واسط (AuthorProduct) آن را به جدول Product مرتبط سازیم تا مشخص شود هر کتاب (به عنوان محصول) به کدام کاربر (به عنوان نویسنده) مرتبط است.
بعد از اینکه مدلهای مربوط به برنامه خود را ساختیم، اولا نیاز به ساخت کلاس کانتکست نداریم چون خود MVC5 کلاس کانتکست را دارد؛ ثانیا نیاز به ایجاد مدل برای جداول اعتبارسنجی نیست، چون کلاسی برای فیلدهای اضافی ما که علاقمندیم به جدول Users اضافه شود، از پیش تعیین گردیده است.
دو کلاسی که با فلش علامت گذاری شده اند، تنها فایلهای موجود در پوشه مدل، بعد از ایجاد یک پروژه هستند.
فایل IdentityModel را به عنوان فایل کانتکست خواهیم شناخت (چون یکی از کلاسهایش Context است). همانطور که پیش از این گفتیم با وجود این فایل نیازی به ایجاد یک کلاس مشتق شده از DbContext نیست.
همانطور که در کد زیر میبینید این فایل دارای دو کلاس است:
namespace MyShop.Models { // You can add profile data for the user by adding more properties to your ApplicationUser class, please visit http://go.microsoft.com/fwlink/?LinkID=317594 to learn more. public class ApplicationUser : IdentityUser { } public class ApplicationDbContext : IdentityDbContext<ApplicationUser> { public ApplicationDbContext() : base("DefaultConnection") { } }
namespace MyShop.Models { // You can add profile data for the user by adding more properties to your ApplicationUser class, please visit http://go.microsoft.com/fwlink/?LinkID=317594 to learn more. public class ApplicationUser : IdentityUser { [Display(Name = "نام انگلیسی")] public string EnglishName { get; set; } [Display(Name = "نام سیستمی")] public string NameInSystem { get; set; } [Display(Name = "نام فارسی")] public string PersianName { get; set; } [Required] [DataType(DataType.EmailAddress)] [Display(Name = "آدرس ایمیل")] public string Email { get; set; } } }
کلاس دوم نیز محل معرفی مدلها به منظور ایجاد در دیتابیس است. به ازای هر مدل یک جدول در دیتابیس خواهیم داشت. مثلا در شکل فوق سه پراپرتی به جدول کاربران اضافه میشود. دقت داشته باشید با اینکه هیچ مدلی برای جدول کاربران نساخته ایم اما کلاس ApplicatioUsers کلاسی است که به ما امکان دسترسی به مقادیر این جدول را میدهد(دسترسی به معنای اضافه و حذف وتغییر مقادیر این جدول است) (در MVC4 به کمک کلاس membership کارهای مشابهی انجام میدادیم)
در ساختن مدل هایمان نیز اگر نیاز به ارتباط با جدول کاربران باشد، از همین کلاس فوق استفاده میکنیم. کلاس واسط(مدل واسط) بین AspNetUsers و Product در کد زیر زیر نشان داده شده است :
namespace MyShop.Models { public class AuthorProduct { [Key] public int AuthorProductId { get; set; } /* public int UserId { get; set; }*/ [Display(Name = "User")] public string ApplicationUserId { get; set; } public int ProductID { get; set; } public virtual Product Product { get; set; } public virtual ApplicationUser ApplicationUser { get; set; } } }
همانطور که مشاهده میکنید، به راحتی ارتباط را برقرار کردیم و برای برقراری این ارتباط از کلاس ApplicationUser استفاده کردیم. پراپرتی ApplicationUserId نیز فیلد ارتباطی ما با جدول کاربران است.
جدول product هم نکته خاصی ندارد و به شکل زیر مدل خواهد شد.
namespace MyShop.Models { [DisplayName("محصول")] [DisplayPluralName("محصولات")] public class Product { [Key] public int ProductID { get; set; } [Display(Name = "گروه محصول")] [Required(ErrorMessage = "لطفا {0} را وارد کنید")] public int ProductGroupID { get; set; } [Display(Name = "مدت زمان")] public string Duration { get; set; } [Display(Name = "نام تهیه کننده")] public string Producer { get; set; } [Display(Name = "عنوان محصول")] [Required(ErrorMessage = "لطفا {0} را وارد کنید")] public string ProductTitle { get; set; } [StringLength(200)] [Display(Name = "کلید واژه")] public string MetaKeyword { get; set; } [StringLength(200)] [Display(Name = "توضیح")] public string MetaDescription { get; set; } [Display(Name = "شرح محصول")] [UIHint("RichText")] [AllowHtml] public string ProductDescription { get; set; } [Display(Name = "قیمت محصول")] [DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:#,0 ریال}")] [UIHint("Integer")] [Required(ErrorMessage = "لطفا {0} را وارد کنید")] public int ProductPrice { get; set; } [Display(Name = "تاریخ ثبت محصول")] public DateTime? RegisterDate { get; set; } } }
به این ترتیب هم ارتباطات را برقرار کردهایم و هم از ساختن یک UserProfile اضافی خلاص شدیم.
برای پر کردن مقادیر اولیه نیز به راحتی از seed موجود در Configuration.cs مربوط به migration استفاده میکنیم. نمونهی اینکار در کد زیر موجود است:
protected override void Seed(MyShop.Models.ApplicationDbContext context) { context.Users.AddOrUpdate(u => u.Id, new ApplicationUser() { Id = "1",EnglishName = "MortezaDalil", PersianName = "مرتضی دلیل", UserDescription = "توضیح در مورد مرتضی", Email = "mm@mm.com", Phone = "2323", Address = "test", NationalCode = "2222222222", ZipCode = "2222222222" }, new ApplicationUser() { Id = "2", EnglishName = "MarhamatZeinali", PersianName = "محسن احمدی", UserDescription = "توضیح در مورد محسن", Email = "mm@mm.com", Phone = "2323", Address = "test", NationalCode = "2222222222", ZipCode = "2222222222" }, new ApplicationUser() { Id = "3", EnglishName = "MahdiMilani", PersianName = "مهدی محمدی", UserDescription = "توضیح در مورد مهدی", Email = "mm@mm.com", Phone = "2323", Address = "test", NationalCode = "2222222222", ZipCode = "2222222222" }, new ApplicationUser() { Id = "4", EnglishName = "Babak", PersianName = "بابک", UserDescription = "کاربر معمولی بدون توضیح", Email = "mm@mm.com", Phone = "2323", Address = "test", NationalCode = "2222222222", ZipCode = "2222222222" } ); context.AuthorProducts.AddOrUpdate(u => u.AuthorProductId, new AuthorProduct() { AuthorProductId = 1, ProductID = 1, ApplicationUserId = "2" }, new AuthorProduct() { AuthorProductId = 2, ProductID = 2, ApplicationUserId = "1" }, new AuthorProduct() { AuthorProductId = 3, ProductID = 3, ApplicationUserId = "3" } );
میتوانیم از کلاسهای خود Identity برای انجام روش فوق استفاده کنیم؛ فرض کنید بخواهیم یک کاربر به نام admin و با نقش admin به سیستم اضافه کنیم.
if (!context.Users.Where(u => u.UserName == "Admin").Any()) { var roleStore = new RoleStore<IdentityRole>(context); var rolemanager = new RoleManager<IdentityRole>(roleStore); var userstore = new UserStore<ApplicationUser>(context); var usermanager = new UserManager<ApplicationUser>(userstore); var user = new ApplicationUser {UserName = "Admin"}; usermanager.Create(user, "121212"); rolemanager.Create(new IdentityRole {Name = "admin"}); usermanager.AddToRole(user.Id, "admin"); }
در عبارت شرطی موجود کد فوق، ابتدا چک کردیم که چنین یوزری در دیتابیس نباشد، سپس از کلاس RoleStore که پیاده سازی شدهی اینترفیس IRoleStore است استفاده کردیم. سازنده این کلاس به کانتکست نیاز دارد؛ پس به آن context را به عنوان ورودی میدهیم. در خط بعد، کلاس rolemanager را داریم که بخشی از پکیج Core است و پیش از این درباره اش توضیح دادیم ( یکی از دو رفرنسی که خوبخود به پروژه اضافه میشوند) و از ویژگیهای Identity است. به آن آبجکتی که از RoleStore ساختیم را پاس میدهیم و خود کلاس میداند چه چیز را کجا ذخیره کند.
برای ایجاد کاربر نیز همین روند را انجام میدهیم. سپس یک آبجکت به نام user را از روی کلاس ApplicationUser میسازیم. برای آن پسورد 121212 سِت میکنیم و نقش ادمین را به آن نسبت میدهیم. این روش قابل تسری به تمامی بخشهای برنامه شماست. میتوانید عملیات کنترل و مدیریت اکانت را نیز به همین شکل انجام دهید. ساخت کاربر و لاگین کردن یا مدیریت پسورد نیز به همین شکل قابل انجام است.
بعد از آپدیت دیتابیس تغییرات را مشاهده خواهیم کرد.