Javascript Disabled!

Please Enable Javascript if you disabled it, or use another browser we preferred Google Chrome.
Please Refresh Page After Enable

Powered By UnCopy Plugin.

CORS Nginx


«اشتراک‌گذاری منابع متقاطع با نام اختصاری CORS شناخته می‌شود. هنگامی که شخصی در دامنه دیگری کار می کند، سرور از این روش برای کنترل دسترسی به خدمات خود استفاده می کند. در وسط سرور و مرورگر اتفاق می افتد. با کمک هدرهای HTTP Access-Control-Request-*، مرورگر برخی از داده ها را منتقل می کند. بر اساس هدرهای دریافتی، سرور تصمیم می گیرد چه چیزی را به عنوان هدر Access-Control-Allow-* ارسال کند. مرورگر اکنون از توانایی یا ناتوانی خود در دسترسی به منابع سرور آگاه است. مرورگر ممکن است گهگاه قبل از درخواست واقعی، یک پیش پرواز انجام دهد که یک اعتبارسنجی است. هدرها را نمی توان با کد جلویی در مرورگر تغییر داد. هدرها را می توان با کد سمت سرور تغییر داد. با این حال، باید توسط یک سرویس پایین دستی که برنامه نمی تواند آن را ببیند، مانند یک دروازه API یا سرور HTTP انجام شود.

جستجوهای HTTP با مبدا متقابل ساخته شده توسط اسکریپت ها توسط مرورگرها برای نگرانی های امنیتی محدود می شوند. به عنوان مثال، اصل همان مبدأ هم به Fetch API و هم به XMLHttpRequest پایبند است. این بدان معناست که یک برنامه وب که از آن APIها استفاده می‌کند، فقط می‌تواند درخواست‌هایی برای منابع از مبدأی که ​​از آنجا بارگذاری شده است، ارائه دهد، مگر اینکه پاسخ سایر منابع دارای هدرهای CORS مناسب باشد.

محرک ها و انواع Tigger یک درخواست CORS

از آنجایی که منابع اغلب در همان منبع برنامه وب میزبانی می شوند، همه درخواست ها منجر به درخواست CORS نمی شوند. اگر متفاوت باشد CORS فعال می شود. درخواست های ساده و درخواست های پیش از پرواز CORS دو شکل متفاوت از درخواست های CORS هستند.

Cors درخواستی ساده

هنگامی که کاربر یک درخواست ساده را آغاز می کند، مرورگر وب آن درخواست را به سرور ارسال می کند. سپس سرور منبع درخواست را بررسی می کند، آن را با قوانین خود تجزیه و تحلیل می کند و در صورت مطابقت، منبع درخواستی را ارائه می دهد. این نوع درخواست از سرصفحه های ORIGIN و ACCESS-CONTROL-ALLOW-ORIGIN استفاده می کند تا تصمیم بگیرد که آیا منبع باید ارائه شود. تنها انواع درخواستی که منجر به یک درخواست ساده می شود عبارتند از GET، HEAD، و POST و همچنین سربرگ هایی مانند Accept-Language، DPR، Downlink، Save-Data، Content-Type، Content-Language، Viewport-Width و عرض حتی هنوز، همه انواع محتوا به یک درخواست ساده منجر نمی شوند. در اینجا، فقط اشکال خاصی از رمزگذاری فرم باعث یک درخواست ساده می شود.

Cors قبل از پرواز

درخواست های پیش از پرواز تا حدودی متفاوت هستند زیرا در دور اولیه اتصال فوری به خدمات وجود ندارد. یک درخواست از پیش پرواز زمانی آغاز می شود که شرایط به نحوی تغییر کند، به عنوان مثال، با استفاده از یک هدر درخواست اصلاح شده یا یک نوع محتوای جایگزین. در درخواست‌های از پیش پرواز، موتور جستجو ابتدا تأیید می‌کند که می‌تواند با مکاتبه با مرورگر وب به منبع دسترسی پیدا کند، و هنگامی که مرورگر وب با یک پاسخ خوب (HTTP 200) پاسخ می‌دهد، سپس درخواست دیگری برای دریافت منبع ارسال می‌کند. ابتدا با استفاده از روش HTTP OPTIONS درخواست می دهد و سپس منابع را با استفاده از انواع درخواست مشابه روش های GET و POST دانلود می کند.

پیش نیاز CORS در Nginx

در وهله اول، پاسخ های 4xx با دستورالعمل استاندارد افزودن هدر Nginx ناسازگار هستند. دستور بیشتر تنظیم سرصفحه ها، که با پاسخ های 4xx نیز کار می کند، ممکن است برای اضافه کردن هدرهای سفارشی به آنها استفاده شود، اما برای انجام این کار، ابتدا باید ماژول هدر Nginx را نصب کنیم.

بسته Nginx-extras را می‌توان به راحتی نصب کرد اگر از توزیع دبیان استفاده می‌کنید، علی‌رغم توصیه مستندات مبنی بر ساخت Nginx از منبع با استفاده از ماژول:

اهمیت فعال کردن CORS در Nginx

اجرای جاوا اسکریپت در مرورگر مشتری معمولاً نیازی به دسترسی به خدمات خارج از دامنه خود ندارد. در نتیجه، خاموش کردن CORS ممکن است یک اقدام امنیتی عاقلانه باشد.

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

نحوه فعال کردن CORS در Nginx در اوبونتو 20.04

بریم سر قسمت اصلی ویرایشگر ترجیحی، vim را باز کنید، سپس به پیکربندی Nginx بروید:

ورودی بعدی را در بلوک سرور پیکربندی Nginx خود وارد کنید.

پس از آن Nginx را مجددا راه اندازی کنید و سپس فایل پیکربندی را ذخیره کنید.

CORS را می توان با استفاده از دستور CURL برای تأیید فعال کرد. خروجی زیر باید از این حاصل شود:

چگونه با خطاهای CORS در یک Sever مقابله کنیم

سمت سرور جایی است که CORS پیاده سازی می شود. سمت مشتری نمی تواند نحوه کار آن را تغییر دهد. با استفاده از رفتار CORS که اغلب به عنوان خطای CORS شناخته می شود، می توان از استفاده کاربران از منابع مشترک جلوگیری کرد. این یک خطا نیست، بلکه یک مکانیسم امنیتی برای محافظت از شما یا وب سایتی است که از آن بازدید می کنید در برابر نقض احتمالی امنیت. اجرای هدرهای HTTP در سمت سرویس گیرنده که ناکافی یا نادرست هستند ممکن است منجر به این مشکل شود (به عنوان مثال، از دست دادن کلیدهای API و سایر اطلاعات مجوز). ما چند راه حل منحصر به فرد برای این خطاها داریم.

  • درخواست های متقاطع را می توان با کمک یک پروکسی CORS انجام داد. درخواست شما از طریق لایه پروکسی که مبدأ آن کور است، ارسال می شود. در نتیجه، حتی اگر درخواست از یک مبدأ ناشناس نشات می گیرد، پروکسی CORS آن را به گونه ای ارائه می کند که گویی از یک مکان مجاز می آید.
  • استفاده از عملکرد بدون سرور راه حل محبوب تری است. این یک رویکرد متفاوت برای پراکسی کردن درخواست‌های شما است، اما علی‌رغم رویکردی که در بالا توضیح داده شد، می‌توانید زیرساخت میکرو خود را برای دسترسی به یک وب سرویس و انتقال داده‌ها به نقطه پایانی API ایجاد کنید.

نتیجه

هدف اصلی CORS ایمن‌تر کردن برنامه‌های کاربردی آنلاین برای جلوگیری از حملات انسان در میان است. CORS هنوز هم می تواند سودمند باشد. از آنجایی که به طور پیش فرض فعال نیست، CORS باید در آن موقعیت فعال شود. با استفاده از دستورات ORIGIN و ACCESS-CONTROL-ALLOW-ORIGIN، که تنها انواع درخواست مورد استفاده توسط نوع درخواست اصلی CORS هستند، Nginx می تواند اجازه دسترسی به منبع درخواستی را بر اساس مبدا به مرورگر وب ارائه دهد. CORS یک ابزار عالی است که باید در هر دو مورد با دقت مورد استفاده قرار گیرد.


به این مطلب امتیاز دهید

جهت ارسال نظر اینجا کلیک کنید.