برنامه نویسی

DDD: احراز هویت و مجوز، چگونه می توان به آن دست یافت؟

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

بسیاری از اوقات ما از کوچک شروع می کنیم و یک برنامه ساده مانند MVC CRUD با استفاده از چارچوبی برای آزمایشی و انتشار سریع ایجاد می کنیم تا به اعتبار سنجی بازار برویم.

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

بنابراین اساسا نقش هایی مانند، کاربران، مدیر، خرده فروش، مشتری، نقش های مدیر داخلی و غیره.
سپس مجوز: C، R، U، D
ماژول‌ها، ویژگی‌ها: اینها عمدتاً نام کنترل‌کننده‌ها هستند، همانطور که در بسیاری از برنامه‌ها می‌بینم.

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

با این حال این برای پروژه های کوچک ساده خوب است، برای یادگیری برخی چارچوب ها یا پروژه هایی که برای استفاده داخلی یا شخصی استفاده می شوند خوب است.

وقتی می‌خواهیم یک مدل دامنه غنی ایجاد کنیم، چیزها باید با جزئیات بیشتری در مورد استفاده و دانش همه‌جای دامنه مورد بحث قرار گیرند.

من اخیراً در مسیر یادگیری DDD بوده‌ام، بنابراین ممکن است برخی چیزها از کار بیفتند.

بیایید یک سناریو در خرده فروشی بگیریم:

بیان مسأله:

** دامنه اصلی: **
یک خرده‌فروش می‌تواند صورت‌حساب‌هایی ایجاد کند و صورت‌حساب‌ها را با مشتریان خود (کسی که محصول را از مغازه خریداری می‌کند) به اشتراک بگذارد. یک خرده‌فروش همچنین می‌تواند کارکنانی را برای ایجاد صورت‌حساب از این طرف تعیین کند.
….
…. موارد استفاده دیگر

** پشتیبانی از دامنه **
پشتیبانی مشتری:
اعضای پشتیبانی مشتری با مشتریان ارتباط برقرار می کنند (در اینجا مشتریان تیم پشتیبانی مشتری خرده فروشان هستند)، آنها می توانند درخواست خرده فروشان را بپذیرند و پشتیبانی تماس تلفنی لازم را ارائه دهند.

…. موارد استفاده دیگر

** دامنه عمومی **
IAM: زیر دامنه کاربر می تواند برای احراز هویت و مجوز استفاده شود.

مورد استفاده: 1
یک خرده‌فروش فقط می‌تواند صورت‌حساب/فاکتور خود را ویرایش کند یا می‌تواند به کارکنان منتخب خود اجازه ویرایش صورت‌حساب/فاکتور را بدهد. مدیر همچنین می تواند صورتحساب ها/فاکتورها را برای خرده فروشان ویرایش کند.

دامنه کاربر:
همه نقش های ممکن چیست؟
خرده فروش، کارکنان، مدیر، عضو پشتیبانی مشتری

چند سوال وجود دارد:

  1. حالا مشتری کیه؟:
    مشتری (کاربر نهایی که محصول را خریداری می کند) در دامنه اصلی.
    یا
    یک خرده فروش در حوزه پشتیبانی مشتری.

  2. چگونه این نقش را تعریف کنیم؟

  3. *سطوح مجوز چیست؟ * این دقیقاً مانند CRUD است، مانند یک برنامه کوچک یا مجوزهای دقیق تر؟

  4. این مجوزها کجا اعمال می شود؟

  5. *آیا باید این مجوزها را در لایه کنترلر، سرویس یا دامنه بنویسیم؟
    هر کدام مزایا و معایب خاص خود را دارند.
    *

  6. چگونه بعداً از یکپارچه و مقیاس مدولار شروع کنیم.

راه حل من:

ما می توانیم یک فایل پیکربندی بر اساس زیر دامنه یا BC که تصمیم گرفتیم داشته باشیم.

بنابراین ما می توانیم نقش هایی مانند:
iam.billing.retailer
iam.billing.customer
iam.billing.admin
iam.billing.staff
iam.customer-support.customer
iam.customer-support.customer-support-member

بنابراین در اینجا iam.billing.retailer و iam.customer-support.customer می توانند دو نقش متفاوت به یک نهاد اختصاص داده شوند.

ما می‌توانیم مجوزهایی را برای دامنه/bc تعریف کنیم که طبق مورد استفاده،

پسندیدن "generateInvoice", "viewInvoice", "changeInvoice".

ما می‌توانیم این مجوزها را به نقش‌های مختلف از خارج اختصاص دهیم و این باعث می‌شود تغییرات بیشتر قابل تنظیم باشد و حتی در آینده به سرویس‌های خارجی یا LDAP دیگر منتقل شود.

سپس ما می توانیم تماس بگیرید authorisationCheck("{activity_name or permission}") در هر مورد استفاده در عوض در روتر یا کنترلر.
همانطور که می‌توانیم این لایه‌های برنامه کاربردی را از مشترکین رویدادهای مختلف با عبور کنترلر که بیشتر بر اساس نگرانی‌های HTTP است، نام ببریم.

برای موارد دقیق‌تر که در آن به اطلاعاتی از تداوم دامنه خاص نیاز داریم، می‌توانیم از آن بخش در دامنه استفاده کنیم زیرا این موارد به منطق تجاری نزدیک‌تر هستند.
در دامنه می‌توانیم کدهای تکراری را که در موارد استفاده متعددی انجام می‌شود که BL یکسانی استفاده می‌شود، ذخیره کنیم.

*لینک های مرجع: *

مجوز بر اساس فعالیت به جای مطابقت نقش-مجوز:

کنترل دسترسی در طراحی دامنه محور:

نوشته های مشابه

دیدگاهتان را بنویسید

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

دکمه بازگشت به بالا