لا يوجد رأس 'Access-Control-Allow-Origin' على الرغم من تعيين DISCOURSE_ENABLE_CORS: true

لقد أضفت العبارات التالية في ملف app.yml الخاص بنا:

  DISCOURSE_ENABLE_CORS: true
  DISCOURSE_CORS_ORIGIN: '*'

تم تعيين ‘*’ مؤقتًا لإزالة المتغيرات أثناء الاختبار. كما حاولت تعيين عناوين URL بشكل صريح دون جدوى.

ومع ذلك، وعلى الرغم من ذلك، لا يزال لدينا

Blockquote

رأس ‘Access-Control-Allow-Origin’ غير موجود في المورد المطلوب.

السياق: لدينا عميل iOS مبني على Unity يتفاعل مع بعض واجهات برمجة تطبيقات Discourse، ونستخدم WebGL للاختبار. ونواجه هذه المشكلة عند الاختبار على متصفحاتنا التي تعمل بـ WebGL تحديدًا.

ألاحظ أيضًا من اختبارات Postman أن جميع الطلبات تحتوي على سياسة مرجعية ‘strict-origin-when-cross-origin’ في رؤوس الاستجابة.

أي مساعدة مُقدَّرة. شكرًا لك!

إعجاب واحد (1)

يتم التحكم في إعداد cors origins في admin > settings > security

كل ما تحتاجه هو DISCOURSE_ENABLE_CORS: في ملف app.yml الخاص بك

إعجاب واحد (1)

لقد حاولت واختبرت هذا أيضًا

وبالنسبة لإعداد الموقع الواحد، فإن تعيين الأصل في ملف .yml مقارنةً بواجهة المسؤول يجب أن يكون له نفس التأثير وفقًا لـ: What is the purpose of Settings -> Security -> CORS origins vs similar environment setting?

إعجاب واحد (1)

لست متأكدًا مما إذا كنا ندعم الحرف البدلي هنا. هل يمكنك تجربته باستخدام نطاق حقيقي؟ نحن نستخدم إعدادات CORS في عدة مواقع مع نطاقات مُعدّة، ويبدو أنها تعمل بشكل جيد.

إعجاب واحد (1)

لديها مفعلة أيضًا على أحد مواقع الويب الخاصة بي، وهي تعمل.

إعجاب واحد (1)

حاولت باستخدام نطاق، لكن دون جدوى. هل توجد طريقة للتأكد من أن متغيرات البيئة مُعَدة بشكل صحيح؟ (أو أن إعادة تشغيل التطبيق قد ضبطت إعدادات CORS دون إعادة إرسال الطلبات، فقط أحاول التفكير في طرق للتصحيح).

أعتقد أن هذا هو الجزء من الكود الذي يتعامل مع إعدادات CORS، في حال كان مفيدًا.

إعجاب واحد (1)

ضمن سجلات الوصول في nginx، ألاحظ أن استدعاء OPTIONS يُرجع خطأ 404 (ويسبق الخطأ في استدعاء GET).

إعجاب واحد (1)