‫۶ سال و ۱۱ ماه قبل، دوشنبه ۲۴ مهر ۱۳۹۶، ساعت ۱۵:۵۸
- این مورد انتخاب شخصی است بیشتر. اگر می‌خواهید یکی را با VSCode کار کنید و دیگری را با VS کامل، شاید جدا باشند بهتر باشد. یا اینکه هر دو را هم می‌توان با VSCode کار کرد (اگر NET Core. کار می‌کنید).
- بستگی به توزیع نهایی برنامه دارد. آیا قرار است برنامه‌ی Angular بر روی یک پورت دیگر و یا یک دومین دیگر به صورت مجزایی ارائه شود؟ بله. در این‌حالت باید CORS فعال شود (یک مثال فعالسازی آن). در غیراینصورت اگر فایل‌های نهایی Angular در پوشه‌ی wwwroot برنامه‌ی وب کپی می‌شوند، نیازی به تغییر اضافه‌تری نیست.
‫۶ سال و ۱۱ ماه قبل، یکشنبه ۲۳ مهر ۱۳۹۶، ساعت ۱۵:۱۴
CopyToPublishDirectory سه مقدار زیر را می‌تواند داشته باشد:
Always: همیشه همه چیز را به پوشه‌ی Publish کپی می‌کند.
PreserveNewest: فقط جدیدترین‌ها را به پوشه‌ی Publish کپی می‌کند.
Never: چیزی را کپی نمی‌کند.
‫۶ سال و ۱۱ ماه قبل، یکشنبه ۲۳ مهر ۱۳۹۶، ساعت ۱۱:۰۷
یک نکته‌ی تکمیلی: روش ارسال کوکی‌ها بین دومین‌های مختلف
به صورت پیش فرض HttpClient کوکی‌ها را بین یک برنامه‌ی Angular که در آدرس متفاوتی نسبت به برنامه‌ی سمت سرور وب قرار داشته باشد، ارسال نمی‌کند. برای فعالسازی ارسال کوکی‌ها در حالت CORS تنها کافی است در تنظیمات آن withCredentials به true تنظیم شود:
@Injectable()
export class FormPosterService {
  private baseUrl = "http://localhost:5000/api/Ngx";

  constructor(private http: HttpClient) { }

  postUserForm(form: LoginForm): Observable<LoginForm> {
    const headers = new HttpHeaders({ "Content-Type": "application/json" });
    return this.http
      .post<LoginForm>(`${this.baseUrl}/login`, form, { headers: headers, withCredentials: true /* For CORS */ });
  }
}
فلسفه‌ی وجودی «اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 » و همچنین «اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 » فراهم آوردن زیر ساختی برای طراحی یک سیستم مستقل اعتبارسنجی، شبیه به ASP.NET Core Identity هست. چون سیستم Identity به صورت پیش‌فرض از همین زیرساخت مبتنی بر کوکی‌ها استفاده می‌کند. برای مثال اگر می‌خواهید با JWT کار کنید و مدیریت کاربران را توسط Idnetity انجام دهید، اینکار برای مثال توسط متد signInManager.PasswordSignInAsync آن قابل انجام نیست؛ چون پس از پایان کار لاگین، یک کوکی را تنظیم می‌کند و نه یک توکن‌را.
‫۶ سال و ۱۱ ماه قبل، چهارشنبه ۱۹ مهر ۱۳۹۶، ساعت ۱۳:۱۰
اگر به تنظیمات cfg.Events دقت کنید، تمام خطاهای اعتبارسنجی را لاگ می‌کند. یعنی اگر این موارد را بررسی کنید، مشکل را متوجه خواهید شد. در پروژه DNT Identity یک سرویس لاگر سفارشی تهیه شده‌است:
- سرویس لاگر سفارشی مبتنی بر EF Core
- کنترلر نمایش اطلاعات آن
- View مرتبط
- ثبت آن در سیستم: ^ و ^
- کنترلری که خطاهای سیستم را لاگ می‌کند و هدایت خطاها به این کنترلر

نیاز به یک چنین قسمتی در برنامه دارید تا بتوانید از خطاهای لاگ شده گزارش بگیرید و آن‌ها را بررسی کنید.
‫۶ سال و ۱۱ ماه قبل، سه‌شنبه ۱۸ مهر ۱۳۹۶، ساعت ۱۸:۳۵
- اگر بر روی سرور machine key تنظیم نشده باشد، IIS هربار که ری‌استارت می‌شود، یک machine key جدید را تولید خواهد کرد و محل نگهداری آن حافظه‌ی سرور است. بنابراین اگر زیاد مشکل لاگین دارید و اطلاعات قابل رمزگشایی نیست و نال بازگشت داده می‌شود، یعنی برنامه‌ی شما بر روی سرور زیاد ری‌استارت می‌شود (متد Application_Start فایل gloal.asax را لاگ کنید تا این مساله مشخص شود).
- امکان تنظیم machine key به صورت دستی در فایل web.config برنامه وجود دارد:
  <system.web>
    <machineKey decryptionKey="Enter decryption Key here" 
                validation="SHA1" 
                validationKey="Enter validation Key here" />
  </system.web>

IIS امکان تولید این کلیدها و به روز رسانی خودکار فایل web.config برنامه را دارد:


روش دوم تولید آن با کدنویسی است:
    protected static string GenerateKey(int length)
    {
        RNGCryptoServiceProvider rngCsp = new RNGCryptoServiceProvider();
        byte[] buff = new byte[length];
        rngCsp.GetBytes(buff);
        StringBuilder sb = new StringBuilder(buff.Length * 2);
        for (int i = 0; i < buff.Length; i++)
            sb.Append(string.Format("{0:X2}", buff[i]));
        return sb.ToString();
    }

    string validationKey = GenerateKey(64);
    string  decryptionKey = GenerateKey(32);
‫۶ سال و ۱۱ ماه قبل، یکشنبه ۱۶ مهر ۱۳۹۶، ساعت ۲۲:۵۶
در کل باید token ایی به سمت سرور ارسال شود (کاربر اطلاعات ویژه‌ای را به سمت سرور ارسال کند) تا مشخص شود که درخواست رسیده معتبر هست یا خیر؛ در غیراینصورت یک درخواست معمولی است که حاوی اطلاعات کاربر ارسال کننده‌ی آن نیست. البته الزامی به ارسال این توکن صرفا توسط هدر درخواست‌های Ajax ایی نیست. این مورد (نحوه‌ی تغییر محل ارسال توکن) در قسمت «.... OnMessageReceived برای حالتی است که توکن دریافتی، توسط هدر مخصوص Bearer به سمت سرور ارسال نمی‌شود...» در متن توضیح داده شده‌است.