وحید نصیری وحید نصیری
اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
‫۶ سال و ۵ ماه قبل، چهارشنبه ۲۹ فروردین ۱۳۹۷، ساعت ۰۲:۱۱
مبحث AddPolicy که در مطلب « سفارشی سازی ASP.NET Core Identity - قسمت پنجم - سیاست‌های دسترسی پویا » توضیح داده شده، وابستگی به ASP.NET Core Identity ندارد و مستقل از آن، مرتبط به جزء Security مجموعه ASP.NET Core است که قسمتی از آن در مطلب جاری استفاده شده‌است. بنابراین نکات آن‌را به همراه یک جدول اضافه‌تر RoleClaims، اینجا هم اضافه کنید، کار می‌کند و هیچ تفاوتی ندارد.
وحید نصیری وحید نصیری
ASP.NET MVC و Identity 2.0 : مفاهیم پایه
‫۶ سال و ۵ ماه قبل، جمعه ۲۴ فروردین ۱۳۹۷، ساعت ۲۳:۲۸
- جدول UserRoles جهت شبیه سازی رابطه‌ی many-to-many در اینجا تعریف شده‌است و در اصل در اینجا دو رابطه‌ی many-to-one و one-to-many وجود دارند. از این جهت که در EF Code First امکان دسترسی به این جدول (junction table) به صورت متداول و استاندارد آن وجود ندارد. بنابراین اکنون که این جدول را در اختیار شما قرار داده‌اند و با EF می‌توان آن‌را کوئری گرفت، امکان استفاده و سفارشی سازی آن را هم دارید. روابط بر اساس کلیدهای خارجی که در اینجا تعریف شده‌اند شکل می‌گیرند و نه فیلدهای اضافی آن.
- فیلد تاریخ انقضاء یک نقش بهتر است به جدول Role اضافه شود و نه این جدول واسط.
- بعد از اضافه کردن این فیلد، کوئری گرفتن از آن توسط سرویس RoleManger انجام می‌شود.
- همچنین فیلتر Authorize استاندارد، درکی از این فیلد جدید ندارد. به همین جهت باید آن‌را هم سفارشی سازی کنید. یک نمونه‌ی آن در پروژه‌ی Decision وجود دارد. این فیلتر با Claims کار می‌کند و مزیت آن عدم مراجعه‌ی مکرر به بانک اطلاعاتی است. این Claims هم پس از لاگین شخص در کوکی او ذخیره می‌شوند. برای نوشتن Claims سفارشی می‌توانید از متد GenerateUserIdentityAsync استفاده کنید و سپس آن‌را در فیلتر Authorize سفارشی سازی شده، بخوانید. در ASP.NET Core Identity یک جدول جدید به نام Role Claims برای همین کاربردها به صورت استاندارد پیش بینی شده‌است و مدیریت کوکی‌های آن خودکار است. به علاوه در آنجا نیازی به سفارشی سازی خود فیلتر Authorize نیست و مفهوم جامعی را به نام Policies، برای سفارشی سازی دسترسی‌ها و فیلتر Authorize معرفی کرده‌اند.
برای دیباگ این موضوع متد DefaultClaimUidExtractor.GetUniqueIdentifierParameters(this.User.Identities) را مستقلا روی لیست Claims جدید فراخوانی کنید. اگر محتوای آن با قبلی تفاوت داشت، همان پیام خطای «این antiforgery توکن، متعلق به کاربر دیگری است» را دریافت خواهید کرد.
وحید نصیری وحید نصیری
ASP.NET MVC و Identity 2.0 : مفاهیم پایه
‫۶ سال و ۵ ماه قبل، جمعه ۲۴ فروردین ۱۳۹۷، ساعت ۰۰:۰۷
مطلب «اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity» را پیگیری کنید. پس از آن دسترسی خواهید داشت به کلاس‌های موجودیت‌های برنامه جهت سفارشی سازی آن‌ها. همچنین نحوه‌ی دسترسی به این کلاس‌ها در لایه سرویس برنامه ارائه شده‌است.
وحید نصیری وحید نصیری
امکان تعریف قالب‌ها در Angular با دایرکتیو ng-template
‫۶ سال و ۵ ماه قبل، چهارشنبه ۲۲ فروردین ۱۳۹۷، ساعت ۱۹:۲۰
یک نکته‌ی تکمیلی: ترکیب ngIf و ngFor بر روی یک المان

فرض کنید می‌خواهید در همان حالیکه عنصری را در طی یک حلقه نمایش می‌دهید،  از همان آیتم جاری برای تشخیص یکی از خاصیت‌های آن نیز استفاده کنید: 
<td *ngFor="let item of headerItems" *ngIf="item.visible">{{ item?.name }}</td>
یک چنین ترکیبی در Angular مجاز نیست و راه حل پیشنهاد شده‌ی آن استفاده از ng-container است:
<ng-container *ngFor="let item of headerItems">
 <td *ngIf="item.visible">{{ item?.name }}</td>
</ng-container>
مزیت مهم آن عدم درج ng-container در DOM است. برای مثال قصد نداریم یک div اضافی را داخل تعاریف یک جدول قرار دهیم و آن‌را از شکل استاندارد خارج کنیم.