https://virgool.ir/feed/@mehdi.mahammadifa2026-11-12 20:11:14https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@mehdi.mahammadihttps://virgool.ir/@mehdi.mahammadi/احراز-هویت-لاراول-laravel-authenticate-bqalbajow2yoهر سه راه حل 1.sanctum 2.passport 3. jwt-auth امکانات کاملی برای احراز هویت لاراولی در اختیار ما میگذارد. با این حال من نیاز داشتم به یک احراز هویتی که توامان با یکی از این سه روش و یا به تنهای بتوانم بر اساس نیاز خودم احراز هویت انجام بدهم.نحوه کار احراز هویت لاراول از میدولر Authenticate شروع میشود.پس از صدا شدن میدلور، متد authenticate همین کلاس صدا زده میشود. بررسی میکند که ایا محافظی(guard) اختصاص داده شده است یا خیر. اگر محافضی اعمال شده باشد اولین محافظی که میتواند کاربر برگرداند بررسی میشودپراپرتی this->auth اشاره به کلاس AuthManager دارد که اینترفیس Illuminate\Contracts\Auth\Factory را پیاده سازی کرده است.در داخل کلاس authManager متد guard نمونه ای از محافظ اعمال شده را resolve میکند.اگر هیچ گاردی برای متد داده نشود درایور گارد پیش فرض را از فایل config/auth.php میگیرد.موقع resolve بررسی میکند که ایا گاردی با این مشخصات داخل بخش guards فایل config/auth.php وجود دارد یا نه.بعد از یافتن گارد، نمونه ای از گارد را با نمونه برنامه و نام گارد و کانفیق های ذخیره شده را فراخوانی میکند.حالا ما نمونه ای از گارد اعمال شده را داریم که فرایند احراز هویت را انجام میدهد در داخل میدلور Authenticate داخل حلقه شرط اعمال شده است به این صورت$this->auth->guard($guard)->check()به این معنی است که باید همه گاردها متد check را باید پیاده سازی کنند. this->auth->guard($guard) نمونه ای از گارد است که resolve شده است و برای ساختن گاردهای سفارشی نیز، پیاده سازی میشود. خود لاراول trait در فضای نام Illuminate\Auth به اسم GuardHelpers.php قرارداده است که در ساختن گاردهای سفارشی کافی است use شود و متد های مورد نیاز را پیاده سازی کرده است.$this->auth->guard($guard)->check()بررسی میکند که ایا کاربر تعریف شده اجازه استفاده از این گارد را دارد و بعد از ان$this->auth->shouldUse($guard)درایور را فراخوانی کرده و کاربر احراز هویت شده را برمیگرداندهمه پکیج های احراز هویت لاراولی مطابق با منطق پیاده سازی خود به نوعی فرایند تعیین احراز هویت را از این فرایند طی میکنند.در نوشته قبلی در مورد نحوه ایجاد یک گرانت جدید مطابق با نیاز خود برای لاراول پاسپورت و ساختن گرانت توضیح دادم [link] که پاسپورت به چه صورت کاربران را متناسب با اطلاعات ارسال شده در هدر درخواست شناسایی میکند و سیاستهای oauth 2.0 متناسب را بر روی موجودیتِ مورد احراز هویت اعمال (و یا بررسی) میکند.بنابرین من برای ساختن یک احراز هویت متناسب با نیاز خودم ابتدا نیاز سنجی که انجام دادم و به این نتایج رسیدماولا. نیاز به ایجاد یک UserProvider اختصاصی که Illuminate\Contracts\Auth\UserProvider را پیاده سازی کند نداشته باشم و از امکانات خود لاراول استفاده کنم.دوما. از jwt استفاده کنم ولی حداقل دپندنسی ها را داشته باشد و نیاز به کتابخانه های مختلفی نداشته باشد.سوما حداقل دو الگوریتم رمز گذاری HS256 و RS256 را داشته باشد.الگوریتم HS256 از یک کلید رمزنگاری برای امضا jwt استفاده میکندالگوریتم RS256 از یک کلید عمومی و یک کلید خصوصی برای امضا jwt استفاده میکندمن از کتابخانه https://github.com/firebase/php-jwt استفاده کرده ام که انواع مختلف دیگری از الگوریتمهای رمزنگاری را پشتیبانی میکندچهارما. تمام تنظیمات مورد نیاز من در فایل auth.php در زیر قسمت گاردها و زیر بخش گارد شخصی سازی شده خودم قابل اعمال باشد و نیاز به ایجاد کلاسهای تنظیمات مختلف در جاهای دیگر نداشته باشم.همانطور که در نوشته مربوط به گرانت پاسپورت گفتم لاراول خود دارای سه نوع گارد داخلی RequestGuard و SessionGuard و TokenGuardهست که Illuminate\Contracts\Auth\Guard را پیاده سازی کرده اند.که برای احراز هویت بخشهای مختلف درخواست، مثل هدر یا بدنه درخواست یا کویری استرینگ و یا کوکی و یا ترکیبی از این بخشها را مورد بررسی قرار میدهند.من در گارد شخصی سازی خودم لازم داشتم که بر اساس نوع تنظیمات خودم فقط یک بخش از درخواست را که در فایل auth.php تنظیم میکنم بررسی کند و همچنین بجای استفاده از کلمه Authorization و پرفیکس Bearer متناسب با نیاز خودم هدر را بررسی کند.به این علت که قصد داشتم علاوه بر استفاده از بسته های احراز هویت لاراول به صورت توامان از احراز هویت خودم استفاده کنم و چون هدر Authorization برای بسته های دیگر مورد استفاده قرار میگیرد بایستی هدر خود را بتوانم تفکیک کنم از هدرهای بسته های لاراولی و همچنین قصد داشتم چندین احراز هویت را بر یک درخواست اعمال کنم که نیاز به تفکیک هر کدام بود.سناریوی که من در گیر بودم به این صورت بود که بدون استفاده از سرور oauth و در یک سیستم منولوتیک با استفاده از توکن های stateless , stateful متفاوت بتوان نوع درخواست را تشخیص دهم کهابتدا.. این درخواست از طریق کدام کلاینت(کلاینتها اپ های موبایلی یکتا و منحصر به یک موجودیت هستند که امکانات متفاوت از دیگر اپ ها را ارایه میکنند و هر اپ به منابع مختص به خود، صلاحیت دسترسی دارد) ارسال شده است. بنابراین ابتدا هر کلاینت باید اطلاعات احراز هویتی خود را در مثلا هدر درخواست قرار دهد تا شناسایی شود.و سپس.. کدام اکانت کاربر (هر اکانت نیز به نوبه خود نیاز به احراز هویت خود داشتند) در کدام اپ موبایلی ارسال کننده درخواست هست. که طبیعتا باید اطلاعات اکانتی خود را در درخواست ارسال کند تا بتوان مورد احراز هویت قرار داد.و بعد از ان.. کدام کاربر با استفاده از کدام اکانتش از طریق کدام اپ موبایلی ارسال کننده درخواست هست تا مورد احراز هویت قرار گیرد.برای تفکیک هر کدام از این موجودیتها مثلا نیاز به ارسال کد jwt مختص خود در هدر درخواست بود که متناسب با هر کدام سیاستهای دسترسی به روتهای لارولی اعمال شود، یعنی ممکن بود هر درخواست شامل چندین کد احراز هویتهای متفاوت رو با هم داشته باشد، تا در مرحله بعد متناسب با محدوده موجودیتهای احراز هویت شده روت لاراول، منابع بر اساس پلیسی ها و گیت ها و پرمیژن های هر کدام در اختیارشان قرار بگیرد. که طبیعتا برای استفاده از اعمال سیاستهای مربوط به سطح دسترسی از بسته laravel-permission استفاده کردن بهترین گزینه هست.در واقع فرض کنید یک سامانه فروشگاه سازی باید پیاده سازی کنیم که هر فروشگاه اپ فروش و اپ مدیریت خود را دارد مشتری که اپ فروشگاه یک را باز کرده است نمیتواند که محصولات فروشگاه دو را ببیند و یا ثبت سفارش از فروشگاه دو کند، و یا سفارشات خود را در فروشگاه دو را پیگیری کند ابتدا باید شما تشخیص دهید این اپ موبایل کدوم یکی هست و مثلا اطلاعات محصولات این فروشگاه رو برای این اپ بفرستید تا نمایش دهد و سپس تشخیص دهید که ایا کاربری که در حال استفاده از این اپ موبایلی است در این فروشگاه اکانت دارد یا خیر و بعد از تشخیص آن، اکانت کاربر را شناسایی کنید، بنابرین برای تفکیک پذیری هر کدوم از این موجودیتها سامانه احرازهویت جداگانه ای که در لاراول به صورت گارد ارایه میشود را میتوانیم اعمال کنیم که من از این امکانات لاراول استفاده کردم و با تشابهی که این مثال فرضی با سامانه مورد نیازم دارد سیستم احرازهویت متناسب را پیاده سازی کردم.توضیحات اضافه این کهپس طبق این سناریو برای یک روت مثلا ارتیکلها در ابتدا ایا "اپ" درخواست کننده صلاحیت کافی برای فراخوانی این روت دارد و اگر بعله ایا "اکانتی که از اون اپ" درخواست داده هست صلاحیت فراخوانی این روت را دارد واگر بعله ایا "کاربر صاحب اون اکانت، از طریق اون اپ" صلاحیت فراخوانی این روت را دارد و اگر بعله (تفکیک بر اساس گاردها تا این قسمت انجام بگیرد و از این قسمت به بعد) سیاستهای سطح دسترسی به موجودیتی که توسط این روت ارایه میشود توسط پلیسی ها اعمال گردد که در رابطه با روتهای ایندکس که لیست از موجودیت را برمیگردانند همچنان علاوه بر پلیسی نیاز به اعمال سیاستهای سطح دسترسی به هر موجودیت نیز ممکن است براساس اینکه صاحب اون رکورد چه کسی است نیز وجود داشته باشد.api.php به اشتباه ادرس دیگری در قسمت کامنت نوشته شده است فایلنحوه استفاده همزمان از passport , sanctum رو در یک مدل هم این زیر اضافه کنمpassport + sanctum باهمسازوکار لاراول پاسپورت به این صورت هست که کاربر از طریق کلاینت درخواستی را برای سرور احراز هویت authorization server میفرستد،کاربری که قبلا در سرور احراز هویت اطلاعات خود را وارد کرده است،کلاینتی که قبلا به روشهای مختلف احراز هویت شده است و متناسب با روش احراز هویت (گرانت) اطلاعات را در هدر درخواست به سمت سرور ارسال میکند،تا بتواند به منابعی که در سرور منابع resource server قراردارد دسترسی داشته باشد.بعد از ان کاربر به سرور احراز هویت هدایت میشود تا تایید کند،و بعد از برگشت کلاینت توکن صادر شده برای کاربر را در هدر درخواستهای ارسالی به سمت سرور منابع resource server قرار میدهد که اجازه دسترسی به منابع را دارد،سرور منابع بعد از دریافت درخواست توکن را به سرور احراز هویت ارسال میکند تا صلاحیت کاربر را تایید کند و بعد از ان منابع را برای کلاینت میفرستد.کلاینت منابع را در اختیار کابر قرار میدهد.لاراول پاسپورت امکان ادغام و ترکیب یا تفکیک، تمام این مراحل در یک یا چند برنامه مبتنی بر نیاز خودتان را به توسعه دهندگان میدهد تا همه سامانه ها را در یک برنامه پیاده سازی کنید و یا هر بخشی را به صورت جداگانه و یا ترکیبی از این فرایند در سامانه های مختلف داشته باشید.برای کلاینت هایی که امکان نگهداری اطلاعات احراز هویت شده(کلاینت) خودشان را ندارند گرانت ها و راهکارهای متفاوتی وجود دارد.با این حال نیاز من به تفکیک کردن احراز هویت در سطوح مختلفی از انتزاع سازی خدمات، و بدست اوردن کنترل کامل هنگام تعریف گاردها در فایل auth.php بدون نیاز به توسعه های پیچیده تر باعث شد که این نحوه احراز هویت را ایجاد کنم.امکان تعریف نحوه احراز هویت بر روی درخواست را مطابق با منطق مورد نیاز خودم داشته باشماز چه طریقی ولیدیشن کنم درخواست را، به صورت پیش فرض پکیجهای احراز هویت از هدر Authorization و پرفکس Bearer برای احراز هویت استفاده میکنند، نیاز داشتم که خودم سیاست احراز هویت را تعیین کنم، و از انجایی که به صورت های مختلف، گاردهای متفاوتی ممکن بود تعریف کنم و برای هر کدام از روشها یا کلیدهای کد گذاری متفاوتی استفاده کنمبدون درگیر شدن در توسعه کد و فقط با استفاده از تنظیمات کانفیق سیاستهای مورد نظر را اعمال کنمو همچنین فرایند احراز هویت را نیز بتوانم تعیین کنم به این صورت که برای مثالتعیین کنم که ایا توکن stateless هست یا stateful یعنی اینکه ایا توکن را ذخیره میکنم و یا به صورت self-contained هست و نیازی به ذخیره توکن نیست و یا اگر نیاز به ذخیره هست چه قسمتها و بخشهایی از داده ها ذخیره شود و یا ارجاعات توکن به دیگر موجودیت ها به چه صورتی باشد.به عنوان مثال ایا لازم است claim خاصی که در داخل توکن موجود است با یک مقداری از 'هدر درخواست' یا 'بدنه درخواست' یا 'داخل کوکی' و یا 'داخل کویری استرینگ'، فرستاده میشود بررسی شود !!! که نیاز نیست هیچ وقت، چون اطلاعات payload توکن غیر قابل دسترس نبوده و بدون داشتن کلید هم قابل خواندن است.و یا به عنوان مثال ایا لازم هست claim های خاص موجود در توکن با مقداری در دیتابیس مثلا ای دی مدلی که جداول خود را دارد، بررسی شود.بنابراین برای ایجاد یک سازوکار مختص به خود اقدام به توسعه این روش احراز هویت کرده ام،با این تصور که از این روش برای تعریف گاردهای زیادی در فایل auth.php لاراول خواهم کرد قطعا استفاده از بسته های احراز هویت های معرفی شده توسط لاراول بهینه تر هستند.مهدی محمدیمهدی محمدیWed, 29 May 2024 15:58:48 +0330