عندما ينجح request في curl أو Postman ثم يفشل من صفحة ويب، أول اشتباه عادة يكون CORS. السبب أن CORS ليست حماية على الخادم من استقبال الطلبات؛ هي سياسة يطبقها المتصفح على JavaScript عندما تتعامل مع origin مختلفة. الخادم قد يستقبل الطلب ويرد 200، لكن المتصفح يمنع الكود من قراءة الاستجابة إذا لم تسمح headers المناسبة. فهم هذه النقطة يحل كثيرًا من التشخيص الخاطئ.
Same-Origin Policy هي القاعدة الأساسية
ال ـorigin تتكون عادة من scheme و host و port. JavaScript في صفحة لا تستطيع قراءة موارد cross-origin بحرية. CORS آلية تسمح للخادم بإعلان origins و methods و headers التي يسمح لل Browser code باستخدامها.
متى يحدث Preflight؟
بعض requests البسيطة تُرسل مباشرة، بينما requests تحتوي methods أو headers معينة قد تبدأ بطلب OPTIONS. الخادم يجب أن يرد على preflight بطريقة صحيحة قبل إرسال الطلب الفعلي. فشل OPTIONS يظهر أحيانًا للمطور كأن endpoint الأصلية لا تعمل.
خطوات عملية
- افتح Network panel.
- ابحث عن OPTIONS.
- راجع Origin المرسلة.
- راجع Access-Control-Allow-Origin.
- راجع Allow-Methods و Allow-Headers.
- تحقق من credentials policy.
لا تعكس Origin بلا تحقق
قراءة Origin من request ثم إعادتها تلقائيًا في Access-Control-Allow-Origin بدون allowlist تجعل السياسة واسعة جدًا. إذا كانت API خاصة بلوحات محددة، استخدم قائمة origins موثوقة أو منطقًا محدودًا ومراجعًا.
Credentials تحتاج سياسة صريحة
عند إرسال Cookies cross-origin باستخدام credentials، يجب أن يسمح الخادم بها صراحة، ولا يمكن استخدام '*' ك ـAllow-Origin في هذا السياق. كما تتداخل SameSite cookies مع النتيجة، لذلك نجاح CORS وحده لا يعني أن Cookie ستُرسل.
Proxy محلية لا تصلح السبب الحقيقي
استخدام dev proxy قد يخفي CORS أثناء التطوير لأنه يجعل الطلب يبدو same-origin. هذا مفيد للتطوير، لكنه لا يغني عن ضبط production origins. اختبر البيئة النهائية بنطاقاتها الحقيقية.
كيف تشخص بسرعة؟
قارن الطلب الناجح في curl مع Network request من المتصفح: method، headers، Origin، cookies، و status لل ـOPTIONS. ثم أصلح policy على الخادم بدل تعطيل حماية المتصفح أو تركيب extensions تلغي CORS.
Cache لل ـPreflight يحتاج ضبطًا صحيحًا
المتصفح قد يخزن نتيجة OPTIONS لفترة يحددها Access-Control-Max-Age ضمن حدود يطبقها كل Browser. هذا يقلل عدد preflight requests لكنه يعني أن تغيير السياسة على الخادم قد لا يظهر فورًا لكل client. اختبر التغيير بعد انتهاء cache أو في جلسة نظيفة، ولا تجعل max-age طويلة أثناء تطوير سياسة ما زالت تتغير.
انتبه إلى Vary: Origin
إذا كنت تعيد Access-Control-Allow-Origin بقيم مختلفة حسب Origin، يجب أن تتأكد أن طبقات CDN أو reverse proxy لا تعيد response مخصصة لموقع A إلى موقع B. استخدام Vary: Origin عند الحاجة يساعد cache على فصل النسخ. الخطأ هنا قد يبدو ك ـCORS عشوائية بينما السبب الحقيقي cache مشتركة لا تعرف أن Origin جزء من المفتاح.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…