احراز هویت مبتنی بر نقش با روتر ری اکت و تایپ اسکریپت – راهنمای کاربردی

۲۰۰ بازدید
آخرین به‌روزرسانی: ۴ مهر ۱۴۰۲
زمان مطالعه: ۶ دقیقه
دانلود PDF مقاله
احراز هویت مبتنی بر نقش با روتر ری اکت و تایپ اسکریپت – راهنمای کاربردیاحراز هویت مبتنی بر نقش با روتر ری اکت و تایپ اسکریپت – راهنمای کاربردی

در این مقاله یک کامپوننت منفرد و با نوع‌بندی قوی برای مدیریت ناوبری مبتنی بر نقش با مدیریت احراز هویت و اعطای دسترسی طراحی می‌کنیم. به این ترتیب با روش احراز هویت مبتنی بر نقش با روتر ری‌اکت و تایپ اسکریپت آشنا خواهیم شد.

997696

احراز هویت و اعطای دسترسی، بخشی یکپارچه از اپلیکیشن‌های مدرن است، اما برخی توسعه‌دهندگان ری‌اکت در پیاده‌سازی این موارد با مشکلاتی مواجه هستند. از این رو در این مطلب یک طراحی مبتنی بر نقش را با استفاده از روتر ری‌اکت و تایپ اسکریپت عرضه می‌کنیم. توجه داشته باشید که این مقاله مقدمه‌ای برای این فناوری‌ها محسوب نمی‌شود. به بیان دیگر در مثال‌هایی که ارائه شده‌اند، فرض شده است که شما درکی مقدماتی از طرز کار آن‌ها دارید و صرفاً روی حل مسئله احراز هویت مبتنی بر نقش تمرکز کرده‌ایم.

پیش از آن که به کدنویسی بپردازیم، یک نکته دیگر را نیز متذکر می‌شویم. این سیستم قطعاً نهایی نیست و برای احراز هویت در اپلیکیشن‌های سطح پروداکشن باید به روش مؤثرتری عمل کنید. ما در این مثال از هیچ راه‌حل مدیریت حالت از قبیل ریداکس و غیره استفاده نکرده‌ایم و قطعاً همه جوانب موضوع را نیز مورد بررسی قرار نداده‌ایم. هدف ما ارائه یک مبنا برای ساخت سیستم احراز هویت است.

نکته: به منظور حفظ سادگی، کد نمونه از حافظه لوکال برای مدیریت توکن استفاده می‌کند. این رویکرد برای اپلیکیشن‌های پروداکشن توصیه نمی‌شود.

فرض کنید یک ابزار مدیریت انبار دارید که کاربران در آن احراز هویت می‌شوند و کاربرانی در سطوح super-admin ،admin و non-admin دارد. که هر یک دسترسی‌های نوشتن/خواندن متفاوتی به بخش‌های مختلف اپلیکیشن دارند.

نقش‌های نوع‌دار

یک enum نقش تعیین می‌کنیم و سپس از آن در یک آرایه userRoles استفاده می‌کنیم.

کدهای مربوطه در ادامه آورده شده است.

ممکن است تعجب کنید که چرا مقادیر enum را به رشته‌هایی در شیء userRoles تبدیل کردیم! دلیل این امر آن است که می‌خواهیم امکان بررسی این که کاربر مفروض در یک آرایه از نقش‌های لازم قرار دارد یا نه را نیز داشته باشیم. با استفاده از یک آرایه از رشته‌های با نوع امن (type-safe) این کار به سهولت انجام می‌شود. البته شاید این بهترین رویه نباشد، اما در هر صورت کار می‌کند.

تنظیم روتر

کد فوق برای روتر ری‌اکت باید کاملاً سرراست باشد. این یک طراحی ناوبری استاندارد است. با این حل، فعلاً هیچ منطق احراز هویت در این ناوبری استفاده نشده است و روتر نیز در مورد نقش کاربر برای احراز هویت در زمان ناوبری در اپلیکیشن اهمیتی نمی‌دهد و اطلاعی از آن ندارد.

فرض کنید سرور ما هم اینک مشغول به کار است. بنابراین باید دست به کار شویم و توکن‌های احراز هویت را در بک‌اند طراحی کنیم. اکنون می‌خواهیم مطمئن شویم که کاربر پیش از دیدن محتوای اپلیکیشن، وارد حساب خود شده است. به این منظور چند کار را باید انجام دهیم:

  • تعریف کردن enum-ها برای احراز هویت و مسیرهای غیر احراز شده (که ضروری نیست، اما آن را به ارسال رشته‌ها به اطراف ترجیح می‌دهیم).
  • تعریف کردن یک کامپوننت مجزا برای مدیریت منطق ریدایرکت برای دسترسی کاربران غیر احراز شده به مسیرهای نیازمند احراز هویت.

فایل AuthRoute.tsx

اکنون باید کامپوننت AuthRoute را بنویسیم. همچنین یک نمای Unauthorized بعداً اضافه می‌کنیم که در صورت تلاش کاربر برای دسترسی به موارد غیرمجاز برایش نمایش پیدا خواهد کرد.

به طور معمول منطق مسیریابی باید کاربر را حتی از ارسال چنین درخواست نامجازی بازدارد، اما فعلاً به همین مقدار بسنده می‌کنیم.

این کامپوننت را کمی توضیح می‌دهیم. اگر با آن آشنا نیستید، کامپوننت Route از react-router-dom یک prop به نام render (+) دارد. این prop به ما امکان می‌دهد تابعی را ارسال کنیم که در نهایت زمانی که مکان مورد نظر با مسیرهای path تطبیق پیدا کند، یک کامپوننت ری‌اکت بازگشت می‌دهد. این مکان برای بررسی این که کاربر برای دیدن صفحه مورد نظر در اپلیکیشن مجاز است یا نه، مکان مناسبی محسوب می‌شود. این تابع در صورتی که با prop به نام component استاندارد رندر شود، به همه prop-های مسیر که کامپوننت باید دسترسی داشته باشد، دسترسی خواهد یافت. پس از آن که تأیید کردیم یک کاربر احراز هویت شده است، باید این prop-ها را به کامپوننتی که رندر شده است ارسال کنیم.

احراز هویت مبتنی بر نقش

کامپوننت Redirect یک prop دارد که صرفاً برای ارسال رشته‌ها نیست و می‌توانید یک شیء با مشخصه‌ها نیز ارسال کنید که دو مورد از آن‌ها را در کامپوننت AuthRoute مورد استفاده قرار می‌دهیم. Pathname نسبتاً سرراست است، اما می‌توانیم بخش‌هایی از حالت را نیز به کامپوننت مقصد ارسال کنیم. این حالت در مواردی مفید خواهد بود که بخواهید کاربر به آن view که قبلاً تلاش کرده دسترسی یابد، بازگردد. مثالی از این وضعیت می‌تواند در موارد منطق لاگین باشد که کاربر را پس از ورود به حساب خود به یک ویوی مفروض می‌برد:

استفاده از AuthRoute در روتر

اکنون که کامپوننت AuthRoute به طور کامل تنظیم شده است، می‌توانیم از آن در روتر خود استفاده کنیم:

اکنون اگر کاربری تلاش کند بدون احراز هویت به این نماها دسترسی یابد، روتر ما او را به صفحه لاگین بازمی‌گرداند. همچنین در صورتی که کاربر به سراغ محتوایی که مجاز به دیدنش نیست برود، یک نمای Unauthorized نمایش می‌یابد؛ اما در مورد نقش کاربر چه می‌توان کرد؟ فرض کنید اپلیکیشن‎مان یک رشته userRole در Context ذخیره می‌کند. این منطق را در کامپوننت AuthRoute خود استفاده می‌کنیم تا بررسی نقش را پیش از مسیریابی کاربر به نمای مفروض اجرا کند:

بنابراین اکنون کامپوننت یک آرایه requiredRoles می‌گیرد که شامل نقش‌هایی است که کاربر باید داشته باشد تا یک صفحه مفروض را ببیند. سپس می‌توانیم نقش‌های مورد نیاز برای هر کامپوننت را ارسال کنیم:

بدین ترتیب ما نه تنها کارهایی که برای اطمینان یافتن از احراز هویت کاربر می‌خواستیم انجام دادیم بلکه مطمئن می‌شویم که با دسترسی‌های صحیحی یک صفحه را تماشا می‌کند. دقت کنید که مقصد کامپوننت Redirect نیز بسته به این که کاربر دارای نقش مورد نیاز است یا نه تعیین می‌شود.

سخن پایانی

بدین ترتیب به پایان این راهنما می‌رسیم. امیدواریم از مطالعه این مطلب بهره آموزشی لازم را برده باشید.

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

==

بر اساس رای ۰ نفر
آیا این مطلب برای شما مفید بود؟
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.
منابع:
levelup.gitconnected.
دانلود PDF مقاله
نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *