.NET Tips | React 16x - قسمت 26 - احراز هویت و اعتبارسنجی کاربران - بخش 1

React 16x - قسمت 26 - احراز هویت و اعتبارسنجی کاربران - بخش 1 - ثبت نام و ورود به سیستم

اندازه‌ی قلم متن

تخمین مدت زمان مطالعه‌ی مطلب: یازده دقیقه

می‌خواهیم به برنامه‌ی لیست فیلم‌هایی که تا این قسمت تکمیل کردیم، امکانات جدیدی را مانند ورود به سیستم، خروج از آن، کار با JWT، فراخوانی منابع محافظت شده‌ی سمت سرور، نمایش و یا مخفی کردن المان‌های صفحه بر اساس سطوح دسترسی کاربر و همچنین محافظت از مسیرهای مختلف تعریف شده‌ی در برنامه، اضافه کنیم.
برای قسمت backend، از همان برنامه‌ی تکمیل شده‌ی قسمت قبل استفاده می‌کنیم که به آن تولید مقدماتی JWTها نیز اضافه شده‌است. البته این سری، مستقل از قسمت سمت سرور آن تهیه خواهد شد و صرفا در حد دریافت توکن از سرور و یا ارسال مشخصات کاربر جهت لاگین، نیاز بیشتری به قسمت سمت سرور آن ندارد و تاکید آن بر روی مباحث سمت کلاینت React است. بنابراین اینکه چگونه این توکن را تولید می‌کنید، در اینجا اهمیتی ندارد و کلیات آن با تمام روش‌های پیاده سازی سمت سرور سازگار است (و مختص به فناوری خاصی نیست). پیشنیاز درک کدهای سمت سرور قسمت JWT آن، مطالب زیر هستند:

ثبت یک کاربر جدید

فرم ثبت نام کاربران را در قسمت 21 این سری، در فایل src\components\registerForm.jsx، ایجاد و تکمیل کردیم. البته این فرم هنوز به backend server متصل نیست. برای کار با آن هم نیاز است شیءای را با ساختار زیر که ذکر سه خاصیت اول آن اجباری است، به endpoint ای با آدرس https://localhost:5001/api/Users به صورت یک HTTP Post ارسال کنیم:

{
  "name": "string",
  "email": "string",
  "password": "string",
  "isAdmin": true,
  "id": 0
}

در سمت سرور هم در Services\UsersDataSource.cs که در انتهای بحث می‌توانید پروژه‌ی کامل آن‌را دریافت کنید، منحصربفرد بودن ایمیل وارد شده بررسی می‌شود و اگر یک رکورد دو بار ثبت شود، یک BadRequest را به همراه پیام خطایی، بازگشت می‌دهد.

اکنون نوبت به اتصال کامپوننت registerForm.jsx، به سرویس backend است. تا اینجا دو سرویس src\services\genreService.js و src\services\movieService.js را در قسمت قبل، به برنامه جهت کار کردن با endpoint‌های backend server، اضافه کردیم. شبیه به همین روش را برای کار با سرویس سمت سرور api/Users نیز در پیش می‌گیریم. بنابراین فایل جدید src\services\userService.js را با محتوای زیر، به برنامه‌ی frontend اضافه می‌کنیم:

import http from "./httpService";
import { apiUrl } from "../config.json";

const apiEndpoint = apiUrl + "/users";

export function register(user) {
  return http.post(apiEndpoint, {
    email: user.username,
    password: user.password,
    name: user.name
  });
}

توسط متد register این سرویس می‌توانیم شیء user را با سه خاصیت مشخص شده، از طریق HTTP Post، به آدرس api/Users ارسال کنیم. خروجی این متد نیز یک Promise است. در این سرویس، تمام متدهایی که قرار است با این endpoint سمت سرور کار کنند، مانند ثبت، حذف، دریافت اطلاعات و غیره، تعریف خواهند شد.
اطلاعات شیء user ای که در اینجا دریافت می‌شود، از خاصیت data کامپوننت RegisterForm تامین می‌گردد:

class RegisterForm extends Form {
  state = {
    data: { username: "", password: "", name: "" },
    errors: {}
  };

البته اگر دقت کرده باشید، در شیء منتسب به خاصیت data، خاصیتی به نام username تعریف شده‌است، اما در سمت سرور، نیاز است خاصیتی با نام Name را دریافت کنیم. یک چنین نگاشتی در داخل متد register سرویس کاربر، قابل مشاهده‌‌است. در غیراینصورت می‌شد در متد http.post، کل شیء user را به عنوان پارامتر دوم، درنظر گرفت و ارسال کرد.

پس از تعریف userService.js، به registerForm.jsx بازگشته و ابتدا امکانات آن‌را import می‌کنیم:

import * as userService from "../services/userService";

می‌شد این سطر را به صورت زیر نیز نوشت، تا تنها یک متد از ماژول userService را دریافت کنیم:

import { register } userService from "../services/userService";

اما روش as userService * به معنای import تمام متدهای این ماژول است. به این ترتیب نام ذکر شده‌ی پس از as، به عنوان شیءای که می‌توان توسط آن به این متدها دسترسی یافت، قابل استفاده می‌شود؛ مانند فراخوانی متد userService.register. اکنون می‌توان متد doSubmit این فرم را به سرور متصل کرد:

  doSubmit = async () => {
    try {
      await userService.register(this.state.data);
    } catch (ex) {
      if (ex.response && ex.response.status === 400) {
        const errors = { ...this.state.errors }; // clone an object
        errors.username = ex.response.data;
        this.setState({ errors });
      }
    }
  };

مدیریت و نمایش خطاهای دریافتی از سمت سرور

در این حالت برای ارسال اطلاعات یک کاربر، در بار اول، یک چنین خروجی را از سمت سرور می‌توان شاهد بود که id جدیدی را به این رکورد نسبت داده‌است:

اگر مجددا همین رکورد را به سمت سرور ارسال کنیم، اینبار خطای زیر را دریافت خواهیم کرد:

که از نوع 400 یا همان BadRequest است:

بنابراین نیاز است بدنه‌ی response را در یک چنین مواردی که خطایی از سمت سرور صادر می‌شود، دریافت کرده و با به روز رسانی خاصیت errors در state فرم (همان قسمت بدنه‌ی catch کدهای فوق)، سبب درج و نمایش خودکار این خطا شویم:

پیشتر در قسمت بررسی «کار با فرم‌ها» آموختیم که برای مدیریت خطاهای پیش بینی شده‌ی دریافتی از سمت سرور، نیاز است قطعه کدهای مرتبط با سرویس http را در بدنه‌ی try/catch‌ها محصور کنیم. برای مثال در اینجا اگر ایمیل شخصی تکراری وارد شود، سرویس یک return BadRequest("Can't create the requested record.") را بازگشت می‌دهد که در اینجا status code معادل BadRequest، همان 400 است. بنابراین انتظار داریم که خطای 400 را از سمت سرور، تحت شرایط خاصی دریافت کنیم. به همین دلیل است که در اینجا تنها مدیریت status code=400 را در بدنه‌ی catch نوشته شده ملاحظه می‌کنید.
سپس برای نمایش آن، نیاز است خاصیت متناظری را که این خطا به آن مرتبط می‌شود، با پیام دریافت شده‌ی از سمت سرور، مقدار دهی کنیم که در اینجا می‌دانیم مرتبط با username است. به همین جهت سطر errors.username = ex.response.data، کار انتساب بدنه‌ی response را به خاصیت جدید errors.username انجام می‌دهد. در این حالت اگر به کمک متد setState، کار به روز رسانی خاصیت errors موجود در state را انجام دهیم، رندر مجدد فرم، در صف انجام قرار گرفته و در رندر بعدی آن، پیام موجود در errors.username، نمایش داده می‌شود.

پیاده سازی ورود به سیستم

فرم ورود به سیستم را در قسمت 18 این سری، در فایل src\components\loginForm.jsx، ایجاد و تکمیل کردیم که این فرم نیز هنوز به backend server متصل نیست. برای کار با آن نیاز است شیءای را با ساختار زیر که ذکر هر دو خاصیت آن اجباری است، به endpoint ای با آدرس https://localhost:5001/api/Auth/Login به صورت یک HTTP Post ارسال کنیم:

{
  "email": "string",
  "password": "string"
}

با ارسال این اطلاعات به سمت سرور، درخواست Login انجام می‌شود. سرور نیز در صورت تعیین اعتبار موفقیت آمیز کاربر، به صورت زیر، یک JSON Web token را بازگشت می‌دهد:

var jwt = _tokenFactoryService.CreateAccessToken(user);
return Ok(new { access_token = jwt });

یعنی بدنه‌ی response رسیده‌ی از سمت سرور، دارای یک شیء JSON خواهد بود که خاصیت access_token آن، حاوی JSON Web token متعلق به کاربر جاری لاگین شده‌است. در آینده اگر این کاربر نیاز به دسترسی به یک api endpoint محافظت شده‌ای را در سمت سرور داشته باشد، باید این token را نیز به همراه درخواست خود ارسال کند تا پس از تعیین اعتبار آن توسط سرور، مجوز دسترسی به منبع درخواستی برای او صادر شود.

در ادامه برای تعامل با منبع api/Auth/Login سمت سرور، ابتدا یک سرویس مختص آن‌را در فایل جدید src\services\authService.js، با محتوای زیر ایجاد می‌کنیم:

import { apiUrl } from "../config.json";
import http from "./httpService";

const apiEndpoint = apiUrl + "/auth";

export function login(email, password) {
  return http.post(apiEndpoint + "/login", { email, password });
}

متد login، کار ارسال ایمیل و کلمه‌ی عبور کاربر را به اکشن متد Login کنترلر Auth، انجام می‌دهد و خروجی آن یک Promise است. برای استفاده‌ی از آن به کامپوننت src\components\loginForm.jsx بازگشته و متد doSubmit آن‌را به صورت زیر تکمیل می‌کنیم:

import * as auth from "../services/authService";

class LoginForm extends Form {
  state = {
    data: { username: "", password: "" },
    errors: {}
  };

  // ...

  doSubmit = async () => {
    try {
      const { data } = this.state;
      const {
        data: { access_token }
      } = await auth.login(data.username, data.password);
      console.log("JWT", access_token);
      localStorage.setItem("token", access_token);
      this.props.history.push("/");
    } catch (ex) {
      if (ex.response && ex.response.status === 400) {
        const errors = { ...this.state.errors };
        errors.username = ex.response.data;
        this.setState({ errors });
      }
    }
  };

توضیحات:
- ابتدا تمام خروجی‌های ماژول authService را با نام شیء auth دریافت کرده‌ایم.
- سپس در متد doSubmit، اطلاعات خاصیت data موجود در state را که معادل فیلدهای فرم لاگین هستند، به متد auth.login برای انجام لاگین سمت سرور، ارسال کرده‌ایم. این متد چون یک Promise را باز می‌گرداند، باید await شود و پس از آن متد جاری نیز باید به صورت async معرفی گردد.
- همانطور که عنوان شد، خروجی نهایی متد auth.login، یک شیء JSON دارای خاصیت access_token است که در اینجا از خاصیت data خروجی نهایی دریافت شده‌است.
- سپس نیاز است برای استفاده‌های آتی، این token دریافتی از سرور را در جایی ذخیره کرد. یکی از مکان‌های متداول اینکار، local storage مرورگرها است (اطلاعات بیشتر).
- در آخر کاربر را توسط شیء history سیستم مسیریابی برنامه، به صفحه‌ی اصلی آن هدایت می‌کنیم.
- در اینجا قسمت catch نیز ذکر شده‌است تا خطاهای حاصل از return BadRequestهای دریافتی از سمت سرور را بتوان ذیل فیلد نام کاربری نمایش داد. روش کار آن، دقیقا همانند روشی است که برای فرم ثبت یک کاربر جدید استفاده کردیم.

اکنون اگر برنامه را ذخیره کرده و اجرا کنیم، توکن دریافتی، در کنسول توسعه دهندگان مرورگر لاگ شده و سپس کاربر به صفحه‌ی اصلی برنامه هدایت می‌شود. همچنین این token ذخیره شده را می‌توان در ذیل قسمت application->storage آن نیز مشاهده کرد:

لاگین خودکار کاربر، پس از ثبت نام در سایت

پس از ثبت نام یک کاربر در سایت، بدنه‌ی response بازگشت داده شده‌ی از سمت سرور، همان شیء user است که اکنون Id او مشخص شده‌است. بنابراین اینبار جهت ارائه‌ی token از سمت سرور، بجای response body، از یک هدر سفارشی در فایل Controllers\UsersController.cs استفاده می‌کنیم (کدهای کامل آن در انتهای بحث پیوست شده‌است):

var jwt = _tokenFactoryService.CreateAccessToken(user);
this.Response.Headers.Add("x-auth-token", jwt);

در ادامه در کدهای سمت کلاینت src\components\registerForm.jsx، برای استخراج این هدر سفارشی، اگر شیء response دریافتی از سرور را لاگ کنیم:

const response = await userService.register(this.state.data);
console.log(response);

یک چنین خروجی را به همراه دارد که در آن، هدر سفارشی ما درج نشده‌است و فقط هدر content-type در آن مشخص است:

برای اینکه در کدهای سمت کلاینت بتوان این هدر سفارشی را خواند، نیاز است هدر مخصوص access-control-expose-headers را نیز به response اضافه کرد:

var jwt = _tokenFactoryService.CreateAccessToken(data);
this.Response.Headers.Add("x-auth-token", jwt);
this.Response.Headers.Add("access-control-expose-headers", "x-auth-token");

به این ترتیب وب سرور برنامه، هدر سفارشی را که قرار است برنامه‌ی کلاینت به آن دسترسی پیدا کند، مجاز اعلام می‌کند. اینبار اگر خروجی دریافتی از Axios را لاگ کنیم، در لیست هدرهای آن، هدر سفارشی x-auth-token نیز ظاهر می‌شود:

اکنون می‌توان این هدر سفارشی را در متد doSubmit کامپوننت RegisterForm، از طریق شیء response.headers خواند و در localStorage ذخیره کرد. سپس کاربر را توسط شیء history سیستم مسیریابی، به ریشه‌ی سایت هدایت نمود:

class RegisterForm extends Form {
  // ...

  doSubmit = async () => {
    try {
      const response = await userService.register(this.state.data);
      console.log(response);
      localStorage.setItem("token", response.headers["x-auth-token"]);
      this.props.history.push("/");
    } catch (ex) {
      if (ex.response && ex.response.status === 400) {
        const errors = { ...this.state.errors }; // clone an object
        errors.username = ex.response.data;
        this.setState({ errors });
      }
    }
  };

کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید: sample-26-backend.zip و sample-26-frontend.zip

‫۴ سال و ۸ ماه قبل، یکشنبه ۲۴ آذر ۱۳۹۸، ساعت ۱۳:۳۵

۶۰۲۳

JavaScript Security JSON Web Token ASP.NET Core React

مطالب مشابه

مطالب React 16x - قسمت 27 - احراز هویت و اعتبارسنجی کاربران - بخش 2 - استخراج و نمایش اطلاعات JWT و خروج از سیستم

مطالب احراز هویت و اعتبارسنجی کاربران در برنامه‌های Angular - قسمت دوم - سرویس اعتبارسنجی

مطالب آزمایش Web APIs توسط Postman - قسمت ششم - اعتبارسنجی مبتنی بر JWT

مطالب React 16x - قسمت 19 - کار با فرم‌ها - بخش 2 - اعتبارسنجی ورودی‌های کاربران

مطالب React 16x - قسمت 28 - احراز هویت و اعتبارسنجی کاربران - بخش 3 - فراخوانی منابع محافظت شده و مخفی کردن عناصر صفحه

مطالب احراز هویت و اعتبارسنجی کاربران در برنامه‌های Angular - قسمت ششم - کار با منابع محافظت شده‌ی سمت سرور

مطالب پیاده سازی JSON Web Token با ASP.NET Web API 2.x

مطالب React 16x - قسمت 20 - کار با فرم‌ها - بخش 3 - بهبود کیفیت کدهای فرم لاگین

مطالب احراز هویت و اعتبارسنجی کاربران در برنامه‌های Angular - قسمت چهارم - به روز رسانی خودکار توکن‌ها

مطالب احراز هویت و اعتبارسنجی کاربران در برنامه‌های Angular - قسمت پنجم - محافظت از مسیرها

#

میثم سلی

‫۴ سال و ۴ ماه قبل، سه‌شنبه ۲۶ فروردین ۱۳۹۹، ساعت ۱۳:۵۶
آیا زمان ثبت نام در سمت سرور نباید هم access_token و هم refresh_token رو تولید و به سمت کلاینت ارسال کرد؟
با بررسی کدهای مربوط به backend این سری و مبحث مربوط به اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity عملیات ثبت نام رو به صورت زیر پیاده سازی کردم.

//do register action and send sms message to client //then call activateRegisterCode action from client to server //In the following run operation authentication for user

[AllowAnonymous] [HttpPost("[action]")] [IgnoreAntiforgeryToken] public async Task<IActionResult> ActivateRegisterCode([FromBody] ActiveCodeModel model) { if (model == null) { return BadRequest("درخواست نامعتبر"); } var user = await _userService.FindUserByKeyCodeAsync(model.Keycode); if (user == null) { return BadRequest("کد امنیتی معتبر نیست لطفا مجددا درخواست کد امنیتی کنید"); } user.IsActive = true; var userUpdated = await _userService.UpdateAsync(user, CancellationToken.None); var jwt = await _tokenFactoryService.CreateJwtTokensAsync(userUpdated); this.Response.Headers.Add("x-auth-token", jwt.AccessToken); this.Response.Headers.Add("access-control-expose-headers", "x-auth-token"); _antiforgery.RegeneratedAntiForgeryCookie(jwt.Claims); return Ok(); }

در ادامه پیاده سازی action logout برای حذف توکن‌ها از دیتابیس

[AllowAnonymous] [HttpGet("[action]"), HttpPost("[action]")] public async Task<bool> Logout(string refreshtoken) { var claimsIdentity = this.User.Identity as ClaimsIdentity; var userIdValue = claimsIdentity.FindFirst(ClaimTypes.UserData)?.Value; if (!string.IsNullOrWhiteSpace(userIdValue) && Guid.TryParse(userIdValue, out Guid userId)) { await _tokenStoreService.InvalidateUserTokensAsync(userId).ConfigureAwait(false); } await _tokenStoreService.DeleteExpiredTokensAsync().ConfigureAwait(false); await _uow.SaveChangesAsync().ConfigureAwait(false); _antiforgery.DeleteAntiForgeryCookie(); return true; }

مشکلی که هست تو اکشن logout شی userIdValue خالیه و بنظر میرسه که کوکی مقدار نداره!

آیا باید زمان فراخوانی این اکشن refreshtoken رو هم بهش ارسال کنیم؟

تو اکشن لاگین هم کوکی‌ها مقدار نمیگیره یا اینکه اصلا با کوکی‌ها کار نداریم و بر اساس refreshtoken باید مقادیر claim‌های داخلش رو decode و بررسی کرد و سپس بر اساس اون در بانک اطلاعاتی عملیات خذف توکن‌های صادر شده در زمان ثبت نام و یا لاگین رو انجام داد.
- #
  
  وحید نصیری
  
  ‫۴ سال و ۴ ماه قبل، سه‌شنبه ۲۶ فروردین ۱۳۹۹، ساعت ۱۴:۲۹
  
  - باید؟ خیر. در اینجا فقط access token ارسال شده. قسمت refresh token پیاده سازی نشده. این مورد اختیاری هست و کار آن پیاده سازی sliding expiration هست. خیلی‌ها چنین قابلیتی را پیاده سازی نمی‌کنند و فقط به همان absolute expiration ارائه شده توسط access token اکتفا می‌کنند.
  
  - زمانیکه با JWT کار می‌کنید، کوکی تولید نمی‌شود. اطلاعات بیشتر
  
  در آن مطلب، کوکی برای پیاده سازی anti forgery token بوده که در اینجا پیاده سازی نشده.
  
  - سایر سؤالات شما در قسمت‌های بعدی «احراز هویت و اعتبارسنجی کاربران» این سری بررسی شده‌اند که شامل ارسال خودکار access token به سمت سرور هم هست. بدون آن this.User.Identity وجود نخواهد داشت.
  
  پیاده سازی این سری مستقل هست از ماخذ دومی که ذکر شده و بر اساس آن نیست و فقط نکات اساسی و مهم ذکر شده‌اند. کدهای کامل و مرتبط با این سری، ذیل هر قسمت پیوست شده.
  - #
    
    میثم سلی
    
    ‫۴ سال و ۴ ماه قبل، سه‌شنبه ۲۶ فروردین ۱۳۹۹، ساعت ۱۶:۰۳
    
    سپاس فراوان از توضیحات خوبتون. فقط دو تا نکته اینکه نیاز به پیاده سازی antiforgery token تو این سناریو هست؟ واینکه درصورت استفاده از refreshtoken در زمان logout باید به سرور بفرستیم یا accesstoken رو. هرچند توضیح دادین که استفاده از refreshtoken برای پیاده سازی sliding expersion هست. به خاطر این میپرسم چون تو یکی از کدهاتون دیدم که refreshtoken رو هنگام logout ارسال میکنید.
    - #
      
      وحید نصیری
      
      ‫۴ سال و ۴ ماه قبل، سه‌شنبه ۲۶ فروردین ۱۳۹۹، ساعت ۱۶:۳۱
      
      - خیر. اختیاری هست.
      
      - access token هست.
#

گیلانی

‫۴ سال و ۴ ماه قبل، چهارشنبه ۳ اردیبهشت ۱۳۹۹، ساعت ۰۹:۲۳

با تشکر؛
- آیا در در حالت Token based سرویس RoleServices ما برای مثال میتواند از RoleManager و یا RoleStore ارث بری کنه مثل Identity؟
- برای مدیریت Role و یا User در حالت Token based مخزن خاصی داریم برای کار احراز هویت در حالت Token based مثل حالت Cookie based که کار را راحتتر کنه؟ یا اینکه باید خودمون همه رو بنویسیم؟(چون در پروژه DNT گویا همه رو داشتیم).
- #
  
  وحید نصیری
  
  ‫۴ سال و ۴ ماه قبل، چهارشنبه ۳ اردیبهشت ۱۳۹۹، ساعت ۱۱:۳۹
  
  دومین پیشنیاز معرفی شده‌ی در ابتدای بحث را دنبال کنید.
#

پرهام دستغیب

‫۳ سال و ۶ ماه قبل، سه‌شنبه ۱۹ اسفند ۱۳۹۹، ساعت ۰۰:۰۲

آیا روشی اصولی و استاندارد برای پیاده‌سازی antiforgery token در این سناریو وجود دارد؟ تصور میکردم باید به عنوان یک اصل همیشه پیاده سازی شود، اما در جواب یکی از سوالات گفتید که اختیاری است. بخصوص برای فرم‌‌های ثبت‌نام و ورود که هنوز از سمت سرور توکن ارسال نشده، یا در پروژه‌ای که در حال انجام هستم کاربر‌ها میتوانند بدون نیاز به حساب کاربری، سفارشی را ارسال کنند. آیا در پروژه‌‌های API - SPA که در آدرسهای مختلف قرار دارند پیاده‌سازی نکردن antiforgery token باعث آسیب‌پذیری نیست؟

متشکرم
- #
  
  وحید نصیری
  
  ‫۳ سال و ۶ ماه قبل، سه‌شنبه ۱۹ اسفند ۱۳۹۹، ساعت ۰۰:۱۰
  
  - در سال 2021 نیازی به پیاده سازی anti-forgery token نیست .
  
  - بحث anti-forgery token مربوط به برنامه‌هایی هست که از کوکی استفاده می‌کنند و نه از JWT. تا زمانیکه JWT را به صورت دستی به هدر درخواست اضافه می‌کنید (مانند مثال این سری) و به صورت خودکار از طریق کوکی‌ها ارسال نمی‌شود، اساسا CSRF attacks در مورد آن‌ها بی‌معنا است.

React 16x - قسمت 26 - احراز هویت و اعتبارسنجی کاربران - بخش 1 - ثبت نام و ورود به سیستم

مطالب مشابه

#

#

#

#

#

#

#

#