‫۶ سال و ۴ ماه قبل، پنجشنبه ۱۳ اردیبهشت ۱۳۹۷، ساعت ۱۳:۲۴
یک نکته‌ی تکمیلی: روش ارسال form-urlencoded به سرور، بجای JSON

doRefreshToken(refreshToken: string): Observable<any> {
  const body = new HttpParams()
    .set('grant_type', "refresh_token")
    .set('refresh_token', refreshToken);

  return this.http.post('/login',
    body.toString(),
    {
      headers: new HttpHeaders()
        .set('Content-Type', 'application/x-www-form-urlencoded')
    }
  );
}
‫۶ سال و ۴ ماه قبل، پنجشنبه ۱۳ اردیبهشت ۱۳۹۷، ساعت ۱۳:۱۸
معادل قطعه کد jQuery Ajax زیر
 $.ajax({
          url: "/login", // web.config --> appConfiguration -> tokenPath
          data: {
                   grant_type: "refresh_token",
                   refresh_token: refreshToken
                },
                type: 'POST', // POST `form encoded` data
                contentType: 'application/x-www-form-urlencoded'
            })
در برنامه‌های Angular و HttpClient آن به صورت زیر است:
doRefreshToken(refreshToken: string): Observable<any> {
  const body = new HttpParams()
    .set('grant_type', "refresh_token")
    .set('refresh_token', refreshToken);

  return this.http.post('/login',
    body.toString(),
    {
      headers: new HttpHeaders()
        .set('Content-Type', 'application/x-www-form-urlencoded')
    }
  );
}
‫۶ سال و ۴ ماه قبل، پنجشنبه ۱۳ اردیبهشت ۱۳۹۷، ساعت ۰۴:۳۰
هیچکدام. کمی بالاتر توضیح دادم که لایه نمایشی محل اتصال مستقیم به بانک اطلاعاتی نیست.
از اینجا شروع کنید:
- بازسازی کد (Refactoring)  
- Bad Code Smell ها 
- آشنایی با Refactoring  
- بررسی مفاهیم معکوس سازی وابستگی‌ها و ابزارهای مرتبط با آن
‫۶ سال و ۴ ماه قبل، پنجشنبه ۱۳ اردیبهشت ۱۳۹۷، ساعت ۰۲:۰۷
همان قسمت «چگونه به اطلاعات User Claims در سرویس‌های برنامه دسترسی پیدا کنیم؟ » مطلب جاری است:
IHttpContextAccessor را باید در لایه سرویس تزریق کنید: «بررسی روش دسترسی به HttpContext در ASP.NET Core»  
‫۶ سال و ۴ ماه قبل، چهارشنبه ۱۲ اردیبهشت ۱۳۹۷، ساعت ۱۹:۳۰
- کاربر شناسایی نمی‌شود یعنی هنوز توکن قبلی منقضی شده را به سمت سرور ارسال می‌کنید. توکن جدید دریافت شده را با توکن قبلی جایگزین کنید.
- به مثال این مطلب نمایش محتویات توکن دریافتی از سرور هم اضافه شده‌است. یکبار اجرایش کنید تا ریز محتویات توکن دریافتی از سرور را به همراه تمام Claims سفارشی آن بتوانید بررسی کنید. در نهایت این جزئیات هستند که به سمت سرور ارسال می‌شوند و دسترسی‌ها را ایجاد می‌کنند.
‫۶ سال و ۴ ماه قبل، سه‌شنبه ۱۱ اردیبهشت ۱۳۹۷، ساعت ۰۰:۲۲
- طول عمر کوکی یا توکن را هیچگاه به بیشتر از یک ماه تنظیم نکنید چون مشکل امنیتی ایجاد می‌کند.
- این خطای «IDX10223: Lifetime validation failed. The token is expired» به این معنا است که توکن واقعا منقضی شده‌است یا به معنای تنظیم نبودن تاریخ و ساعت سمت سرور است. سعی کنید این مورد را با اینترنت هماهنگ کنید.
- همچنین مقدار ClockSkew به معنای حد تحمل این عدم هماهنگی هست (بین ساعت و زمان صادر کننده‌ی تولید توکن و مصرف کننده‌ی آن). در اینجا به صفر تنظیم شده‌است. این‌را هم می‌توانید تا 5 دقیقه درنظر بگیرید.
- خطای «PII is hidden by default» با تنظیم «IdentityModelEventSource.ShowPII = true» نمایش داده می‌شود.
‫۶ سال و ۴ ماه قبل، دوشنبه ۱۰ اردیبهشت ۱۳۹۷، ساعت ۱۸:۰۲
« ... حالا بعد از اعمال روش ارائه شده در این مطلب (ذخیره‌سازی token و refresh token در دیتابیس) چطور می‌توانیم کاربرانی که از توکن قبلی استفاده می‌کنند را مجبور به Sign out کنیم؟  ...»
همان قسمت «تهیه یک اعتبارسنج توکن سفارشی» مطلب جاری هست که از نتیجه‌ی «پیاده سازی Logout» استفاده می‌کند. یا حتی می‌توانید در قسمت logout یک SerialNumber را هم تغییر دهید که به صورت یک Claim سفارشی در توکن قبلی وجود داشته باشد. عدم انطباق این مقادیر را در این اعتبارسنج سفارشی بررسی کنید.