وحید نصیری وحید نصیری
روش‌هایی برای بهبود تجربه‌ی کاربری صفحات لاگین و ثبت نام
‫۲ سال قبل، سه‌شنبه ۲۲ شهریور ۱۴۰۱، ساعت ۱۹:۰۴
وجود ندارد به معنای عدم امکان افزودن آن‌ها نیست. تمام کامپوننت‌های استاندارد Blazor به همراه خاصیت زیر هم هستند:
[Parameter(CaptureUnmatchedValues = true)] 
public IReadOnlyDictionary<string, object>? AdditionalAttributes { get; set; }
با تعریف پارامتر از نوع CaptureUnmatchedValues = true، تمام ویژگی‌های اضافه شده که به صورت پارامتر عمومی کامپوننت نیستند، به عنوان Unmatched Values تفسیر شده و مورد استفاده قرار می‌گیرند. یعنی همینقدر که ویژگی "autocomplete="new-password را به تعریف کامپوننت اضافه کردید (و هر مورد مشابه دیگری را)، یک Unmatched Value است و به صورت خودکار در حین رندر نهایی، در المان اضافه شده‌ی به صفحه، ظاهر می‌شود.
وحید نصیری وحید نصیری
Blazor 5x - قسمت 18 - کار با فرم‌ها - بخش 6 - حذف اطلاعات
‫۲ سال قبل، شنبه ۱۹ شهریور ۱۴۰۱، ساعت ۲۰:۰۸
این سری را کامل مطالعه کنید؛ خصوصا قسمت بعدی را چون اگر طول عمر سرویس‌ها را به نحو عنوان شده مدیریت نکنید، یا اطلاعات حذف نمی‌شوند و یا اطلاعات به اشتباه کش شده‌ای را مجددا دریافت خواهید کرد.
در یک پروژه nullable ref types فعال است و در دیگری خیر:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <Nullable>enable</Nullable>
  </PropertyGroup>
اگر می‌خواهید هر دو مثل هم عمل کنند، باید به اخطارهای کامپایلر دقت کنید و Name را nullable تعریف کنید:
public class Person
{
     public string? Name { get; set; }
     public string? Family { get; set; }
مثال انتهای بحث را دریافت و بررسی کردید (یک مثال کامل قابل اجرا و بررسی)؟ چون هیچکدام از مدل‌ها و تنظیمات و غیره آن داخل پروژه‌ی web نیست. همچنین نکات به روز رسانی به نگارش‌های جدیدتر را هم مدنظر داشته باشید.
وحید نصیری وحید نصیری
نحوه‌ی محاسبه‌ی هش کلمات عبور کاربران در ASP.NET Identity
‫۲ سال قبل، شنبه ۱۲ شهریور ۱۴۰۱، ساعت ۱۵:۰۹
روش تغییر «تعداد بار تکرار» الگوریتم هش کردن اطلاعات در ASP.NET Core Identity

کلیات مطلب عنوان شده‌ی در اینجا در ASP.NET Core Identity هم صادق است؛ اما به همراه امکانات تنظیمی بیشتر، مانند امکان تنظیم تعداد بار تکرار الگوریتم هش کردن کلمات عبور:
public void ConfigureServices(IServiceCollection services)
{
    services.Configure<PasswordHasherOptions>(options => options.IterationCount = 100_000);
که البته مقدار پیش‌فرض آن همان 100 هزار بار است که هرچقدر مقدار آن بیشتر باشد، کار brute force آن مشکل‌تر می‌شود.

نکته 1: تغییر این مقدار، مشکلی را برای کاربران فعلی ایجاد نمی‌کند؛ از این جهت که این تعداد بار نیز جزو اطلاعاتی است که به همراه هش نهایی در بانک اطلاعاتی ذخیره می‌شود و اگر مقدار آن‌را تغییر دادید، صرفا به کاربران جدید و یا کاربرانی که کلمه‌ی عبور خود را تغییر می‌دهند، اعمال خواهد شد.
نکته 2: این تغییر، زمانی مؤثر واقع خواهد شد که مقدار تعداد تکرار جدید، بیشتر از مقدار قبلی باشد. یعنی اگر مقدار جدیدی را مساوی 200 هزار اعمال کردید و بر اساس آن هش کلمات عبور تغییر یافت و سپس این مقدار را به 100 هزار تغییر دادید، چون عدد جدید کمتر است از عدد قبلی، ندید گرفته می‌شود.
نکته 3: بهتر است این عدد را بیش از اندازه بزرگ انتخاب نکنید؛ چون کار سرور را بیشتر کرده و همچنین پروسه‌ی لاگین را کند می‌کنید. زمان پیشنهادی برای اینکار، 1 ثانیه به ازای هر کلمه‌ی عبور است. یعنی عددی را انتخاب کنید که پس از انجام تمام تکرارها برای محاسبه‌ی هش، بیش از 1 ثانیه طول نکشد و بر این اساس، عدد 500 هزار تکرار، شاید انتخاب بهتری باشد.
- از بین می‌رود. باید آن‌را در local storage ذخیره کنید.
- بله. نمونه اینکار در پروژه‌ی «پیاده سازی سیاست‌های دسترسی پویای سمت سرور و کلاینت در برنامه‌های Blazor WASM» پس از لاگین انجام شده.
- خیر؛ نیازی نیست. توکن‌ها به همراه امضای دیجیتال هستند و همچنین کلید رمزنگاری خصوصی آن بر روی سرور ذخیره می‌شود. کسی که توانسته در سمت کلاینت توکنی را تغییر دهد و آن‌را از مرحله‌ی اعتبارسنجی خودکار سمت سرور رد کند (یعنی امضای دیجیتال تغییرات انجام شده را مجددا محاسبه و به توکن اعمال کرده)، به سرور شما و کلیدهای رمزنگاری خصوصی آن دسترسی دارد؛ یک چنین شخصی نیازی به دستکاری توکنی را ندارد، چون هم اکنون دسترسی او به سرور شما کامل است! محتوای یک JWT، هرچند قابل مشاهده و مطالعه است، اما امضاء شده‌است. یک چنین محتوای امضاء شده‌ای، در جاهای حساس دیگری هم کاربرد واقعی دارد: «تهیه XML امضاء شده جهت تولید مجوز استفاده از برنامه»