اشتراک منابع متقاطع (CORS)

اشتراک منابع متقاطع (CORS) یک مکانیسم مبتنی بر HTTP-Header است که به یک سرور اجازه می دهد تا منشاء (دامنه ، طرح یا پورت) را غیر از خود نشان دهد که از آن یک مرورگر باید منابع بارگیری را مجاز کند. CORS همچنین به مکانیسمی متکی است که توسط آن مرورگرها درخواست "Preflight" را به سرور میزبان منابع متقاطع متقاطع می دهند تا بررسی کنند که سرور درخواست واقعی را فراهم می کند. در آن پیش نمایش ، مرورگر هدرهایی را ارسال می کند که روش HTTP و هدرهایی را که در درخواست واقعی استفاده می شود ، نشان می دهد.

نمونه ای از درخواست متقاطع: کد JavaScript Front-end که از https://domain-a. com استفاده می شود از XMLHTTPREQUEST استفاده می کند تا درخواست https://domain-b. com/data. json را ارائه دهد.

به دلایل امنیتی ، مرورگرها درخواست های HTTP متقاطع را که از اسکریپت ها آغاز شده اند ، محدود می کنند. به عنوان مثال ، XMLHTTPREQUEST و API FETCH از سیاست همان منشی پیروی می کنند. این بدان معنی است که یک برنامه وب با استفاده از آن API ها فقط می تواند منابع را از همان مبدأ درخواست کند که برنامه از آن بارگیری شده است ، مگر اینکه پاسخ از سایر منشاء شامل هدرهای CORS مناسب باشد.

مکانیسم CORS از درخواست های بین المللی امن و انتقال داده ها بین مرورگرها و سرورها پشتیبانی می کند. مرورگرهای مدرن از COR در API هایی مانند XMLHTTPRequest یا واکشی برای کاهش خطرات درخواست HTTP متقاطع استفاده می کنند.

چه درخواست هایی از COR استفاده می کنند؟

این استاندارد به اشتراک گذاری متقاطع می تواند درخواست های HTTP متقاطع را برای:

• همانطور که در بالا مورد بحث قرار گرفت ، دعوت از API های XMLHTTPREQUEST یا FETCH.
• فونت های وب (برای استفاده از قلم متقابل در فونت در CSS) ، به طوری که سرورها می توانند فونت های TrueType را مستقر کنند که فقط می توانند با استفاده از آن توسط وب سایت هایی که مجاز به انجام این کار هستند ، بارگیری شوند. واد
• تصاویر/قاب های ویدیویی با استفاده از نقاشی () به یک بوم کشیده شده است.

این یک مقاله کلی در مورد به اشتراک گذاری منابع متقاطع است و شامل بحث در مورد هدرهای HTTP لازم است.

نمای کلی

استاندارد به اشتراک گذاری منابع متقاطع با اضافه کردن هدرهای جدید HTTP که به سرورها اجازه می دهد توصیف کنند که منشاء آن مجاز به خواندن آن اطلاعات از یک مرورگر وب است. علاوه بر این ، برای روش های درخواست HTTP که می تواند باعث ایجاد عوارض جانبی در داده های سرور شود (به ویژه ، روش های HTTP به غیر از دریافت ، یا ارسال با انواع خاص MIME) ، مشخصات مشخصاتی که مرورگرها را "PREFLIGHT" درخواست ، درخواست روش های پشتیبانی شده از سروربا استفاده از روش درخواست HTTP گزینه ها ، و سپس ، پس از "تأیید" از سرور ، ارسال درخواست واقعی. سرورها همچنین می توانند به مشتریان اطلاع دهند که آیا "اعتبار" (مانند کوکی ها و تأیید هویت HTTP) باید با درخواست ارسال شود.

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

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

نمونه هایی از سناریوهای کنترل دسترسی

ما سه سناریو ارائه می دهیم که نشان می دهد چگونه به اشتراک گذاری منابع متقاطع کار می کند. همه این مثالها از XMLHTTPRequest استفاده می کنند ، که می تواند درخواست های متقاطع را در هر مرورگر پشتیبانی ایجاد کند.

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

برخی از درخواست ها باعث نمی شوند که یک پیش نمایش CORS ایجاد شود. این درخواست های ساده از مشخصات CORS منسوخ نامیده می شود ، اگرچه مشخصات Fetch (که اکنون CORS را تعریف می کند) از این اصطلاح استفاده نمی کند.

انگیزه این است که عنصر HTML 4. 0 (که پیش از سایت XMLHTTPREQUEST و FETCH را پیش می برد) می تواند درخواست های ساده ای را به هر مبدأ ارسال کند ، بنابراین هرکسی که یک سرور را می نویسد باید از قبل در برابر جعل درخواست متقاطع (CSRF) محافظت کند. براساس این فرض ، سرور مجبور نیست برای دریافت هر درخواستی که به نظر می رسد مانند ارسال فرم باشد ، از انتخاب خودداری کند ، زیرا تهدید CSRF بدتر از ارسال فرم نیست. با این حال ، سرور هنوز هم باید با استفاده از دسترسی به کنترل-کلسیم-منشور برای به اشتراک گذاشتن پاسخ با اسکریپت انتخاب شود.

یک درخواست ساده موضوعی است که تمام شرایط زیر را برآورده می کند:

• یکی از روشهای مجاز:

توجه: Firefox هنوز دامنه را به عنوان یک درخواست کننده SAFELISTED به کار نگرفته است. به اشکال 1733981 مراجعه کنید.

• تنها ترکیبات نوع/زیرگروه مجاز برای نوع رسانه مشخص شده در هدر نوع محتوا عبارتند از:
  • برنامه/X-www-form-urlencoded
  • چند بخش/فرم
  • متن/ساده

  توجه: پیش نمایش فناوری Nightly و Safari WebKit محدودیت های اضافی را در مقادیر مجاز در هدرهای پذیرش ، پذیرش و محتوا به زبان قرار دهید. اگر هر یک از این هدرها دارای مقادیر "غیر استاندارد" باشند ، WebKit/Safari این درخواست را "درخواست ساده" نمی داند. چه ارزشهای WebKit/Safari "غیر استاندارد" را در نظر می گیرند ، مستند نیست ، مگر در اشکالات WebKit زیر:

  هیچ مرورگرهای دیگری این محدودیت های اضافی را اجرا نمی کنند زیرا آنها جزئی از مشخصات نیستند.

  به عنوان مثال ، فرض کنید محتوای وب در https: //foo. example آرزو می کند محتوا را در دامنه https: //bar. other فراخوانی کند. کد این نوع ممکن است در JavaScript مستقر در foo. example استفاده شود.

  این عمل یک مبادله ساده بین مشتری و سرور انجام می دهد ، با استفاده از هدر CORS برای رسیدگی به امتیازات:

  

  بیایید ببینیم که مرورگر در این مورد چه چیزی را به سرور ارسال می کند:

  هدر درخواست یادداشت Origin است که نشان می دهد دعوت از https: //foo. example می آید.

  حال بیایید ببینیم که سرور چگونه پاسخ می دهد:

  در پاسخ ، سرور یک هدر دسترسی-کنترل-صدور را با دسترسی به کنترل- all-orligin باز می گرداند: * ، به این معنی که به هر منشاء می توان به این منبع دسترسی پیدا کرد.

  این الگوی از هدرهای مبدأ و کنترل-کنترل-ایلوژین ساده ترین استفاده از پروتکل کنترل دسترسی است. اگر صاحبان منابع در https: //bar. other مایل به محدود کردن دسترسی به منبع فقط از https: //foo. example باشند (یعنی ، هیچ دامنه ای غیر از https: //foo. example می تواند به منبع دسترسی داشته باشدبه روش متقاطع) ، آنها ارسال می کنند:

  توجه: هنگام پاسخ به درخواست درخواست های معتبر ، سرور باید به جای مشخص کردن کارت وحشی " *" ، منشأ را در مقدار هدر دسترسی-کنترل-میلی لیتر مشخص کند.

  درخواست های پیش از پرواز

  بر خلاف درخواست های ساده ، برای درخواست های "preflighted" مرورگر ابتدا درخواست HTTP را با استفاده از روش گزینه ها به منبع در منشاء دیگر ارسال می کند تا مشخص شود که آیا درخواست واقعی برای ارسال ایمن است یا خیر. چنین درخواستهای متقاطع از آنجا که ممکن است پیامدهایی برای داده های کاربر داشته باشد ، از قبل پرواز می شوند.

  در زیر نمونه ای از درخواستی است که از قبل پرواز خواهد شد:

  مثال بالا یک بدنه XML برای ارسال با درخواست پست ایجاد می کند. همچنین ، یک هدر درخواست HTTP X-PingOther بدون استاندارد تنظیم شده است. چنین هدرها جزئی از HTTP/1. 1 نیستند ، اما به طور کلی برای برنامه های وب مفید هستند. از آنجا که درخواست از نوع محتوا از متن/XML استفاده می کند ، و از آنجا که یک هدر سفارشی تنظیم شده است ، این درخواست از قبل پرواز می شود.

  

  توجه: همانطور که در زیر توضیح داده شده است ، درخواست پست واقعی شامل هدرهای Access-Control-Request-* نیست. آنها فقط برای درخواست گزینه ها مورد نیاز هستند.

  بیایید به تبادل کامل بین مشتری و سرور نگاه کنیم. اولین مبادله درخواست/پاسخ Preflight است:

  خطوط 1 - 10 در بالا نشان دهنده درخواست Preflight با روش گزینه ها است. مرورگر تعیین می کند که نیاز به ارسال این مطلب بر اساس پارامترهای درخواست که قطعه کد JavaScript در بالا از آن استفاده می کرد ، به گونه ای که سرور بتواند پاسخ دهد که آیا ارسال درخواست با پارامترهای درخواست واقعی قابل قبول است یا خیر. گزینه ها یک روش HTTP/1. 1 است که برای تعیین اطلاعات بیشتر از سرورها استفاده می شود و یک روش ایمن است ، به این معنی که نمی توان از آن برای تغییر منبع استفاده کرد. توجه داشته باشید که همراه با درخواست گزینه ها ، دو عنوان درخواست دیگر ارسال می شوند (به ترتیب خطوط 9 و 10):

  عنوان Access-Control-Request-Method به سرور به عنوان بخشی از درخواست Preflight اطلاع می دهد که هنگام ارسال درخواست واقعی ، این کار را با یک روش درخواست ارسال انجام می دهد. هدر Access-Control-Request-Headers به سرور اطلاع می دهد که وقتی درخواست واقعی ارسال می شود ، این کار را با هدرهای سفارشی X-Pingother و از نوع محتوا انجام می دهد. اکنون سرور فرصتی برای تعیین اینکه آیا می تواند درخواست را تحت این شرایط بپذیرد ، تعیین کند.

  خطوط 12 - 21 در بالا پاسخی است که سرور باز می گردد ، که نشان می دهد روش درخواست (POST) و عنوان های درخواست ( X-PingOther) قابل قبول هستند. بیایید نگاهی دقیق تر به خطوط 15-18 داشته باشیم:

  سرور با دسترسی به کنترل-اورژین پاسخ می دهد: https: //foo. example ، دسترسی فقط به دامنه مبدا درخواست کننده را محدود می کند. همچنین با روشهای کنترل کنترل پاسخ پاسخ می دهد ، که می گوید پست و دریافت روشهای معتبری برای پرس و جو از منابع مورد نظر هستند (این هدر مشابه هدر پاسخ مجاز است ، اما به شدت در چارچوب کنترل دسترسی استفاده می شود).

  این سرور همچنین با ارزش "X-Pingother ، نوع محتوا" ، رهبران کنترل دسترسی را ارسال می کند و تأیید می کند که این موارد مجاز هستند که با درخواست واقعی استفاده شوند. مانند روشهای دسترسی به کنترل ، دسترسی به کنترل-کنترل-همه یک لیست جدا از کاما از هدرهای قابل قبول است.

  در نهایت، Access-Control-Max-Age مقداری را در چند ثانیه نشان می دهد که چه مدت پاسخ به درخواست قبل از پرواز بدون ارسال درخواست قبل از پرواز دیگر در حافظه پنهان ذخیره می شود. مقدار پیش فرض 5 ثانیه است. در مورد حاضر، حداکثر سن 86400 ثانیه (= 24 ساعت) است. توجه داشته باشید که هر مرورگر دارای حداکثر مقدار داخلی است که وقتی Access-Control-Max-Age از آن بیشتر شود اولویت دارد.

  پس از تکمیل درخواست پیش از پرواز، درخواست واقعی ارسال می شود:

  درخواست‌ها و تغییر مسیرهای از پیش پرواز

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

  این درخواست به "https://example. com/foo" هدایت شد، که برای درخواست‌های متقاطع که نیاز به پرواز اولیه دارند، مجاز نیست. درخواست نیاز به قبل از پرواز دارد، که به دنبال تغییر مسیرهای متقاطع مجاز نیست.

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

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

  • رفتار سمت سرور را تغییر دهید تا از قبل از پرواز و/یا برای جلوگیری از تغییر مسیر جلوگیری کنید
  • درخواست را طوری تغییر دهید که یک درخواست ساده باشد که باعث پیش پرواز نشود

  اگر این امکان پذیر نیست، راه دیگری این است که:

  1. یک درخواست ساده (با استفاده از Response. url برای Fetch API، یا XMLHttpRequest. responseURL) برای تعیین اینکه درخواست پیش پرواز واقعی به کدام URL ختم می شود، ارسال کنید.
  2. با استفاده از آدرس اینترنتی که از Response. url یا XMLHttpRequest. responseURL در مرحله اول دریافت کردید، درخواست دیگری (درخواست واقعی) بدهید.

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

  درخواست هایی با اعتبار

  توجه: هنگام ارسال درخواست‌های اعتبارسنجی به دامنه دیگری، سیاست‌های کوکی شخص ثالث همچنان اعمال می‌شود. این خط مشی همیشه بدون در نظر گرفتن هرگونه تنظیماتی در سرور و کلاینت همانطور که در این فصل توضیح داده شده اجرا می شود.

  جالب ترین قابلیت در معرض هر دو XMLHTTPREQUEST یا FETCH و COR ، امکان تهیه درخواست های "اعتبار" است که از کوکی های HTTP و اطلاعات تأیید هویت HTTP آگاه هستند. به طور پیش فرض ، مرورگرها در Origin Xmlhttprequest یا Fetch Invocations ، اعتبار خود را ارسال نمی کنند. یک پرچم خاص باید در هنگام فراخوانی روی شیء XMLHTTPRequest یا سازنده درخواست تنظیم شود.

  در این مثال ، محتوایی که در ابتدا از https بارگذاری شده است: //foo. example یک درخواست ساده به یک منبع در https: //bar. other که کوکی ها را تنظیم می کند ، درخواست می کند. محتوای foo. example ممکن است حاوی جاوا اسکریپت مانند این باشد:

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

  

  در اینجا یک نمونه تبادل بین مشتری و سرور وجود دارد:

  اگرچه خط 10 حاوی کوکی است که برای مطالب موجود در https: //bar. other قرار دارد ، اگر BAR. Other با یک معتبر دسترسی-کنترل-آمریکایی پاسخ نداد: درست (خط 16) ، پاسخ نادیده گرفته می شود و ساخته نمی شوددر دسترس محتوای وب.

  درخواست ها و اعتبار های پیش از پرواز

  درخواست های CORS-PREFLIGHT هرگز نباید شامل اعتبارنامه باشد. پاسخ به یک درخواست Preflight باید معتبر دسترسی-کنترل-همه را مشخص کند: درست است که نشان می دهد درخواست واقعی با اعتبار می تواند انجام شود.

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

  Firefox 87 اجازه می دهد تا این رفتار غیر سازگار با تنظیم اولویت فعال شود: network. cors_preflight. owlow_client_cert to true (اشکال 1511151). مرورگرهای مبتنی بر Chromium در حال حاضر همیشه گواهینامه های مشتری TLS را در درخواست های Preflight CORS ارسال می کنند (Chrome Bug 775438).

  درخواست های معتبر و کارتهای وحشی

  هنگام پاسخ به یک درخواست معتبر:

  • سرور نباید Wildcard " *" را برای مقدار پاسخ-کنترل-یا همهژنهای دسترسی-کنترل کننده-کنترل کننده مشخص کند ، بلکه باید در عوض منشأ صریح را مشخص کند. به عنوان مثال: Access-control-allow-origin: https://example. com
  • سرور نباید Wildcard " *" را برای ارزش پاسخ-کنترل-کنترل-سرپرست-سرپرست مشخص کند ، بلکه در عوض باید لیست صریح نام هدر را مشخص کند. به عنوان مثال ، دسترسی به کنترل-هلرها: X-PingOther ، نوع محتوا
  • سرور نباید Wildcard " *" را برای مقدار پاسخ-کنترل-روشهای کنترل-روشهای کنترل مشخص کند ، بلکه باید در عوض لیست صریح نام های روش را مشخص کند. به عنوان مثال ، روشهای کنترل-کنترل-آلمات: ارسال ، دریافت کنید

  اگر یک درخواست شامل یک اعتبارنامه (معمولاً یک هدر کوکی) باشد و پاسخ شامل یک کنترل دسترسی-آمیز-منشور است: * هدر (یعنی با کارت وحشی) ، مرورگر دسترسی به پاسخ را مسدود می کند و گزارش CORS را گزارش می کند. خطا در کنسول DevTools.

  اما اگر یک درخواست شامل یک اعتبار (مانند هدر کوکی) باشد و پاسخ شامل یک منشأ واقعی به جای کارت وحشی (مانند ، به عنوان مثال ، Access-Control-owlow-origin: https://example. com) است ، سپسمرورگر امکان دسترسی به پاسخ از منشاء مشخص شده را فراهم می کند.

  همچنین توجه داشته باشید که هر عنوان پاسخ به مجموعه در یک پاسخ ، اگر مقدار دسترسی-کنترل-میلی لیتر در آن پاسخ ، کارت وحشی " *" و نه منشأ واقعی باشد ، کوکی را تنظیم نمی کند.

  کوکی های شخص ثالث

  توجه داشته باشید که کوکی هایی که در پاسخ های CORS تنظیم شده اند ، مشمول سیاست های کوکی شخص ثالث هستند. در مثال بالا ، صفحه از Foo. example بارگیری می شود اما کوکی در خط 19 توسط نوار ارسال می شود.

  کوکی در درخواست (خط 10) همچنین ممکن است در سیاست های کوکی شخص ثالث معمولی سرکوب شود. بنابراین ، سیاست اجباری کوکی ممکن است توانایی شرح داده شده در این فصل را باطل کند ، و به طور مؤثر مانع از ایجاد درخواست های معتبر شود.

  خط مشی کوکی در اطراف ویژگی Samesite اعمال می شود.

  هدرهای پاسخ HTTP

  در این بخش عنوان های پاسخ HTTP که سرورها برای درخواست های کنترل دسترسی مطابق با مشخصات اشتراک منابع متقاطع تعریف شده اند ، نشان می دهد. بخش قبلی مروری بر این موارد در عمل ارائه می دهد.

  دسترسی به کنترل-ایلوژین

  یک منبع برگشتی ممکن است یک هدر دسترسی-اجباری با نحو زیر داشته باشد:

  Access-Control-all-Origin یا منشاء واحد را مشخص می کند که به مرورگرها می گوید که این منشأ اجازه دسترسی به منبع را می دهد. یا در غیر این صورت - برای درخواست های بدون اعتبار - Wildcard " *" به مرورگرها می گوید که به هر منشاء اجازه دسترسی به منبع را بدهند.

  به عنوان مثال، برای اجازه دادن به کد از مبدا https://mozilla. org برای دسترسی به منبع، می توانید مشخص کنید:

  اگر سرور یک مبدأ واحد را مشخص کند (که ممکن است به صورت پویا بر اساس مبدأ درخواست به عنوان بخشی از لیست مجاز تغییر کند) به جای علامت عام " * "، سرور باید مبدا را نیز در سربرگ پاسخ Vary قرار دهد تا به مشتریان نشان دهد که سرور پاسخ می دهد. بر اساس مقدار سرصفحه درخواست Origin متفاوت خواهد بود.

  Access-Control-Expose-Headers

  هدر Access-Control-Expose-Headers هدرهای مشخص شده را به لیست مجاز اضافه می کند که جاوا اسکریپت (مانند getResponseHeader()) در مرورگرها مجاز به دسترسی به آن هستند.

  به عنوان مثال موارد زیر:

  ... به هدرهای X-My-Custom-Header و X-Another-Custom-Header اجازه می دهد تا در معرض مرورگر قرار گیرند.

  Access-Control-Max-Age

  هدر Access-Control-Max-Age نشان می دهد که نتایج یک درخواست قبل از پرواز چه مدت می تواند ذخیره شود. برای نمونه ای از درخواست قبل از پرواز، به نمونه های بالا مراجعه کنید.

  پارامتر delta-seconds تعداد ثانیه هایی را که می توان نتایج را در حافظه پنهان کرد، نشان می دهد.

  Access-Control-Allow-Credentials

  هدر Access-Control-Allow-Credentials نشان می دهد که آیا پاسخ به درخواست می تواند در زمانی که پرچم اعتبارنامه درست است آشکار شود یا خیر. هنگامی که به عنوان بخشی از پاسخ به درخواست پیش از پرواز استفاده می شود، نشان می دهد که آیا می توان درخواست واقعی را با استفاده از اعتبارنامه ها انجام داد یا خیر. توجه داشته باشید که درخواست‌های ساده GET از قبل پرواز نمی‌شوند و بنابراین اگر درخواستی برای منبعی با اعتبارنامه ارسال شود، اگر این هدر همراه با منبع برگردانده نشود، پاسخ توسط مرورگر نادیده گرفته می‌شود و به محتوای وب بازگردانده نمی‌شود.

  Access-Control-Allow-Methods

  هدر Access-Control-Allow-Methods روش یا روش های مجاز را هنگام دسترسی به منبع مشخص می کند. این در پاسخ به درخواست قبل از پرواز استفاده می شود. شرایطی که تحت آن یک درخواست پیش پرواز می شود در بالا مورد بحث قرار گرفته است.

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

  Access-Control-Allow-Headers

  هدر Access-Control-Allow-Headers در پاسخ به یک درخواست قبل از پرواز استفاده می شود تا نشان دهد که از کدام سرصفحه های HTTP می توان هنگام درخواست واقعی استفاده کرد. این هدر پاسخ سمت سرور به هدر Access-Control-Request-Headers مرورگر است.

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

  در این بخش عنوان هایی که مشتری ها هنگام صدور درخواست HTTP از آنها استفاده می کنند ، به منظور استفاده از ویژگی اشتراک گذاری متقاطع استفاده می شود. توجه داشته باشید که این هدرها هنگام دعوت از سرورها برای شما تنظیم شده اند. توسعه دهندگان با استفاده از قابلیت های متقاطع XMLHTTPREQUEST ، نیازی به تنظیم هیچ هدرهای درخواست اشتراک گذاری متقاطع به صورت برنامه ای ندارند.

  اصل و نسب

  هدر مبدا نشانگر منشأ درخواست دسترسی متقاطع یا درخواست قبل از پرواز است.

  منشأ URL است که نشان دهنده سرور است که از آن درخواست شروع می شود. این شامل اطلاعات مربوط به مسیر نیست ، فقط نام سرور است.

  توجه: مقدار مبدا می تواند تهی باشد.

  توجه داشته باشید که در هر درخواست کنترل دسترسی ، هدر Origin همیشه ارسال می شود.

  دسترسی-کنترل-روش

  روش دسترسی-کنترل-متداول هنگام صدور درخواست Preflight استفاده می شود تا به سرور اطلاع دهد که هنگام درخواست واقعی از روش HTTP استفاده می شود.

  نمونه هایی از این استفاده را می توان در بالا یافت.

  دسترسی به کنترل-کنترل

  هدر دسترسی-کنترل-کنترل در هنگام صدور درخواست پیش از پرواز استفاده می شود تا به سرور اطلاع دهد که از هدرهای HTTP هنگام درخواست واقعی استفاده می شود (مانند SetRequestHeader (). این هدر سمت مرورگر توسط عنوان سرور مکمل سرور مکمل از رهبران دسترسی-کنترل-همه پاسخ داده می شود.

  نمونه هایی از این استفاده را می توان در بالا یافت.

  مشخصات فنی

  مشخصات
  استاندارد واکشی# http- دسترسی-کنترل-صدور اورژین

  سازگاری مرورگر

  جداول BCD فقط در مرورگر بارگیری می شود

  همچنین ببینید

  • چگونه می توان از قبل از پرواز COR جلوگیری کرد
  • نحوه استفاده از پروکسی CORS برای دستیابی
  • نحوه رفع "هدر دسترسی-کنترل-صدور-منشور نباید Wildcard باشد"

  مشکلی در این صفحه پیدا کرده اید؟

  آخرین اصلاح شده: 5 دسامبر 2022 ، توسط همکاران MDN

  طرح شما برای اینترنت بهتر.

  حمایت کردن

  جوامع ما

  توسعه دهنده

  به والدین غیر انتفاعی شرکت موزیلا ، بنیاد موزیلا مراجعه کنید. بخش هایی از این محتوا © 1998 - 2022 توسط مشارکت کنندگان mozilla. org است. محتوای موجود تحت مجوز Creative Commons.