راهنمای CDN.com.tr

سرآیندهای CORS روی لبه

Q: آیا لبه خودش به درخواستهای preflight پاسخ میدهد؟

لبه درخواستهای OPTIONS را به مبدأ شما میفرستد و هرگز آنها را کش نمیکند، پس مبدأ شما باید با 200 یا 204 به preflight پاسخ دهد. سرآیندهای پاسخ قانون به آن پاسخ اضافه میشوند: سرآیندهای CORS میتوانند از قانون بیایند و مبدأ شما فقط باید OPTIONS را بپذیرد. استثنا: در قانونی با حفاظت با گذرواژه یا فهرست مجاز IP، لبه خودش به preflightی که از آن عبور نمیدهد با 401 یا 403 پاسخ میدهد.

Q: آیا یک قانون میتواند به چند سایت اجازه دهد؟

یک قانون مقدار یکسانی به هر پاسخ اضافه میکند: * یا یک origin مانند https://app.example.com. برای مجاز کردن چند origin، بگذارید برنامهٔ شما origin منطبق را همراه با Vary: Origin بفرستد، و Access-Control-Allow-Origin را در قانون نگذارید. درخواستهایی که کوکی یا اعتبارنامههای دیگر دارند به یک origin مشخص نیاز دارند، نه *.

Q: API من از PUT، PATCH یا DELETE استفاده میکند. چه چیزی را تغییر دهم؟

تا وقتی WAF سطح سایت روشن است، صفحهٔ Security را باز کنید، متدها را زیر متدهای HTTP مجاز علامت بزنید و روی Save بزنید؛ تغییر ظرف 1-2 دقیقه منتشر میشود. متدهای درخواست مجاز در تب امنیت قوانین تحویل همان کارت را باز میکند. OPTIONS را علامتخورده نگه دارید: مرورگرها آن را برای preflight میفرستند.

Access-Control-Allow-Origin و دیگر سرآیندهای CORS را به پاسخ‌های یک قانون تحویل اضافه کنید، بگذارید مبدأ شما به درخواست‌های preflight از نوع OPTIONS پاسخ دهد، و متدهایی را که API شما استفاده می‌کند در WAF مجاز کنید.

کش، امنیت، WAF و پاک‌سازی

سرآیندهای CORS روی لبه

راهنماهای مرتبط

CORS در مرورگر چگونه کار می‌کند، چگونه درخواستی را که لبه رد کرده بخوانید، و مبدأ شما دیگر چه چیزهایی از لبه دریافت می‌کند.

پیش‌زمینه

CORS چیست؟ قاعدهٔ مرورگر پشت هر خطای cross-origin

درخواست‌های ساده، preflight و اعتبارنامه‌ها، با آزمون‌های curl.

خواندن راهنما

یک 403 از لبه

خواندن لاگ‌های WAF

یک درخواست ردشده را بر اساس زمان یا Reference ID پیدا کنید و ببینید کدام قاعده آن را مسدود کرده است.

باز کردن موضوع

مبدأ شما

اتصال به مبدأ: IP واقعی بازدیدکننده، قفل کردن مبدأ، WebSocket و مهلت‌ها

سرآیندهایی که به مبدأ شما فرستاده می‌شوند، و متدهای WAF که یک API لازم دارد.

باز کردن موضوع

مسیر در پنل

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

پیش‌نیازها

یک قانون تحویل که مسیرهای درخواستی سایت دیگر را ارائه می‌دهد.
origin دقیق سایت درخواست‌کننده، مانند https://app.example.com، یا * برای فایل‌هایی که هر کسی می‌تواند بارگذاری کند.
برای فراخوانی‌های API که preflight می‌فرستند: مبدأ شما در آن مسیرها با 200 یا 204 به OPTIONS پاسخ می‌دهد.
نقش مالک یا ویرایشگر: بیننده‌ها می‌توانند قوانین را ببینند اما نمی‌توانند آن‌ها را تغییر دهند.

مدل تصمیم‌گیری

فایل‌های عمومی یا یک API؟

آنچه مرورگر می‌فرستد تعیین می‌کند کار کجا انجام شود.

فونت‌ها، تصاویر و JSON عمومی که با یک GET ساده بارگذاری می‌شوند: preflight ندارند و Access-Control-Allow-Origin در قانون تنها چیزی است که لازم دارند. تا وقتی بهینه‌سازی تصویر در سطح حساب روشن است، فایل‌های .jpg، .jpeg و .png سرآیندهای پاسخ قدیمی‌ترین قانون دامنه را می‌گیرند، نه قانونِ مسیرشان را.
فراخوانی‌های API با بدنهٔ JSON، سرآیندهای سفارشی یا PUT، PATCH، DELETE: مرورگر اول یک preflight می‌فرستد؛ مبدأ شما به آن پاسخ می‌دهد و قانون می‌تواند سرآیندهای CORS را به آن پاسخ اضافه کند.
درخواست‌هایی با کوکی یا اعتبارنامه‌های دیگر: یک origin مشخص، نه *، به‌علاوهٔ Access-Control-Allow-Credentials true.

هر سرآیند از لبه یا از مبدأ شما؟

برای هر سرآیند یک منبع انتخاب کنید.

لبه (قانون): یک مقدار ثابت روی هر پاسخ 2xx و 3xx، از جمله پاسخ‌هایی که از کش داده می‌شوند، و اگر خط با always تمام شود، روی پاسخ‌های 4xx و 5xx مبدأ شما هم.
مبدأ: مقداری که به سایت درخواست‌کننده بستگی دارد و با Vary: Origin فرستاده می‌شود.
ارسال‌شده از هر دو: آن را زیر حذف سرآیندها علامت بزنید تا فقط مقدار قانون ارسال شود.

راهنمای گام‌به‌گام

سرآیندها را به قانون اضافه کنید

نمونه‌ای برای یک API زیر /api/ که یک وب‌اپلیکیشن آن را فراخوانی می‌کند. هر سطر یک سرآیند بنویسید؛ مقداری که فاصله دارد داخل گیومهٔ دوتایی نوشته می‌شود.

قوانین تحویل ← قوانین را باز کنید و روی ویرایش در قانون /api/ بزنید.
زیر آنگاه ← سرآیندها، در افزودن سرآیند به پاسخ هر کدام را در یک سطر جداگانه بنویسید: Access-Control-Allow-Origin https://app.example.com، Access-Control-Allow-Methods "GET, POST, PUT, OPTIONS"، Access-Control-Allow-Headers "Content-Type, Authorization" و Access-Control-Max-Age 600.
زیر حذف سرآیندها، هر کدام از این نام‌ها را که مبدأ شما هم می‌فرستد علامت بزنید.
روی ذخیرهٔ قانون بزنید.

نتیجه مورد انتظار: قانون برچسبی مانند +4 هدر پاسخ نشان می‌دهد و وقتی لبه آن را ارائه کند، صفحه منتشرشده را نشان می‌دهد.

متدهای API را در WAF مجاز کنید

تا وقتی WAF سطح سایت روشن است و API از متدهایی فراتر از GET، HEAD، POST و OPTIONS استفاده می‌کند لازم است.

در نوار کناری، WAF Logs را زیر Protection باز کنید.
زیر متدهای HTTP مجاز، PUT، PATCH یا DELETE را بسته به نیاز API خود علامت بزنید، OPTIONS را علامت‌خورده نگه دارید و روی Save بزنید.

نتیجه مورد انتظار: پنل ذخیره را تأیید می‌کند و تغییر ظرف 1-2 دقیقه منتشر می‌شود.

یک درخواست ساده و یک preflight را بررسی کنید

curl قواعد CORS را اعمال نمی‌کند، پس دقیقاً همان چیزی را نشان می‌دهد که لبه پاسخ می‌دهد.

نقطهٔ پایانی را با یک سرآیند Origin درخواست دهید.
همان preflightی را بفرستید که مرورگر می‌فرستد: OPTIONS با Origin، Access-Control-Request-Method و Access-Control-Request-Headers.

نتیجه مورد انتظار: درخواست ساده یک access-control-allow-origin دارد. preflight با 200 یا 204 همراه با origin، متدها و سرآیندهای مجاز پاسخ می‌دهد.

معادل cdnctl

curl -s -o /dev/null -D - -H 'Origin: https://app.example.com' https://www.example.com/api/items | grep -iE '^(HTTP|access-control)'
curl -s -o /dev/null -D - -X OPTIONS -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: PUT' -H 'Access-Control-Request-Headers: content-type' https://www.example.com/api/items | grep -iE '^(HTTP|access-control|x-mt-blocked-by)'

راستی‌آزمایی

curl -s -o /dev/null -D - -H 'Origin: https://app.example.com' https://www.example.com/api/items | grep -iE '^(HTTP|access-control)' → 2xx و دقیقاً یک access-control-allow-origin: https://app.example.com
curl -s -o /dev/null -D - -X OPTIONS -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: PUT' -H 'Access-Control-Request-Headers: content-type' https://www.example.com/api/items | grep -iE '^(HTTP|access-control|x-mt-blocked-by)' → 200 یا 204 با access-control-allow-origin، access-control-allow-methods و access-control-allow-headers
یک 403 با x-mt-blocked-by: cdn-edge-security روی یک درخواست → لبه آن را رد کرده است (WAF، یا مسدودسازی IP، کشور، شبکه یا hotlink)؛ متدهای HTTP مجاز و لاگ‌های WAF را بررسی کنید

موارد کاربرد

یک وب‌اپلیکیشن روی app.example.com فونت، JSON یا پاسخ‌های API را از www.example.com بارگذاری می‌کند و مرورگر آن‌ها را با خطای CORS مسدود می‌کند.

جریان کاری سریع

قوانین تحویل را باز کنید، به تب قوانین بروید و روی ویرایش در قانونی بزنید که مسیرهای درخواستی سایت دیگر را ارائه می‌دهد، یا برای یک مسیر جدید روی افزودن قانون.
زیر آنگاه، سرآیندها را باز کنید و در افزودن سرآیند به پاسخ هر سطر یک سرآیند به‌صورت Header-Name value، بدون دونقطه، بنویسید، مثلاً Access-Control-Allow-Origin https://app.example.com. مقداری که فاصله دارد داخل گیومهٔ دوتایی نوشته می‌شود.
اگر مبدأ شما برای این مسیرها از قبل یک سرآیند Access-Control-* می‌فرستد، همان نام را زیر حذف سرآیندها علامت بزنید تا مرورگر یک مقدار واحد دریافت کند.
روی ذخیرهٔ قانون (برای قانون جدید ساختن قانون) بزنید و صبر کنید تا صفحه منتشرشده را نشان دهد.
اگر API شما از PUT، PATCH یا DELETE استفاده می‌کند و WAF سطح سایت روشن است، آن‌ها را زیر متدهای HTTP مجاز در صفحهٔ Security علامت بزنید.
یک درخواست ساده و یک preflight را با curl بررسی کنید.

بررسی‌ها

سرآیندهای قانون از لحظهٔ انتشار قانون به پاسخ‌های موفق و تغییر مسیر (2xx و 3xx)، از جمله پاسخ‌هایی که از کش داده می‌شوند، اضافه می‌شوند. خطی که با always تمام می‌شود به پاسخ‌های 4xx و 5xx مبدأ شما هم اضافه می‌شود.
درخواست‌های preflight از نوع OPTIONS به مبدأ شما می‌روند و هرگز کش نمی‌شوند. وقتی مبدأ شما با 200 یا 204 به یک preflight پاسخ می‌دهد، سرآیندهای قانون به آن پاسخ اضافه می‌شوند؛ preflightی که با 401، 404 یا 405 پاسخ داده شود بدون آن‌ها به مرورگر می‌رسد، مگر اینکه خط با always تمام شود. در قانونی با حفاظت با گذرواژه یا فهرست مجاز IP، لبه خودش به preflightی که از آن عبور نمی‌دهد با 401 یا 403 پاسخ می‌دهد.
دقیقاً یک Access-Control-Allow-Origin به مرورگر می‌رسد: با دو مقدار، مرورگر پاسخ را رد می‌کند.
اگر مبدأ شما Access-Control-Allow-Origin را بسته به سایت درخواست‌کننده تغییر می‌دهد، باید Vary: Origin را هم بفرستد. لبه این نسخه‌ها را تا وقتی نگه داشتن یک نسخهٔ کش، صرف‌نظر از سرآیند Vary در قانون خاموش است، از هم جدا نگه می‌دارد.
Access-Control-Request-Method و Access-Control-Request-Headers را زیر حذف سرآیندها بدون علامت بگذارید: نام‌هایی که آنجا علامت می‌خورند از درخواست‌های ارسالی به مبدأ شما هم حذف می‌شوند، و مبدأ شما برای پاسخ به یک preflight این دو را می‌خواند.
با روشن بودن WAF سطح سایت، GET، HEAD، POST و OPTIONS به‌طور پیش‌فرض مجازند. درخواستی با متدی که در فهرست نیست یک 403 بدون سرآیندهای CORS و با X-MT-Blocked-By: cdn-edge-security می‌گیرد که مرورگر آن را خطای CORS گزارش می‌کند.
تا وقتی بهینه‌سازی تصویر در سطح حساب روشن است، فایل‌های .jpg، .jpeg و .png سرآیندهای پاسخ قدیمی‌ترین قانون دامنه را می‌گیرند، نه قانونِ مسیرشان را: سرآیند CORS این تصاویر را در همان قانون بگذارید، با یک Access-Control-Allow-Origin ثابت. وقتی آن قدیمی‌ترین قانون، قانون بررسی گواهی باشد، هیچ سرآیندی از قوانین نمی‌گیرند.

پرسش‌های متداول

آیا لبه خودش به درخواست‌های preflight پاسخ می‌دهد؟

لبه درخواست‌های OPTIONS را به مبدأ شما می‌فرستد و هرگز آن‌ها را کش نمی‌کند، پس مبدأ شما باید با 200 یا 204 به preflight پاسخ دهد. سرآیندهای پاسخ قانون به آن پاسخ اضافه می‌شوند: سرآیندهای CORS می‌توانند از قانون بیایند و مبدأ شما فقط باید OPTIONS را بپذیرد. استثنا: در قانونی با حفاظت با گذرواژه یا فهرست مجاز IP، لبه خودش به preflightی که از آن عبور نمی‌دهد با 401 یا 403 پاسخ می‌دهد.

آیا یک قانون می‌تواند به چند سایت اجازه دهد؟

یک قانون مقدار یکسانی به هر پاسخ اضافه می‌کند: * یا یک origin مانند https://app.example.com. برای مجاز کردن چند origin، بگذارید برنامهٔ شما origin منطبق را همراه با Vary: Origin بفرستد، و Access-Control-Allow-Origin را در قانون نگذارید. درخواست‌هایی که کوکی یا اعتبارنامه‌های دیگر دارند به یک origin مشخص نیاز دارند، نه *.

مرورگر هنوز خطای CORS گزارش می‌کند. چه چیزی را بررسی کنم؟

از وضعیت درخواست ناموفق در پنل شبکهٔ مرورگر شروع کنید. یک 403 با X-MT-Blocked-By: cdn-edge-security از لبه می‌آید: آن را در لاگ‌های WAF پیدا کنید و اگر متد آن در فهرست نیست، آن را زیر متدهای HTTP مجاز اضافه کنید. هر 4xx یا 5xx دیگری به‌طور پیش‌فرض بدون سرآیندهای قانون می‌رسد، پس اول آن پاسخ را درست کنید. خطی که با always تمام می‌شود، مانند Access-Control-Allow-Origin https://app.example.com always، به پاسخ‌های 4xx و 5xx مبدأ شما هم اضافه می‌شود. سپس بررسی کنید که دقیقاً یک Access-Control-Allow-Origin می‌رسد و با سایت درخواست‌کننده، از جمله scheme، مطابقت دارد.

API من از PUT، PATCH یا DELETE استفاده می‌کند. چه چیزی را تغییر دهم؟

تا وقتی WAF سطح سایت روشن است، صفحهٔ Security را باز کنید، متدها را زیر متدهای HTTP مجاز علامت بزنید و روی Save بزنید؛ تغییر ظرف 1-2 دقیقه منتشر می‌شود. متدهای درخواست مجاز در تب امنیت قوانین تحویل همان کارت را باز می‌کند. OPTIONS را علامت‌خورده نگه دارید: مرورگرها آن را برای preflight می‌فرستند.