لدي مشكلة في تضمين فيديو يوتيوب
ما هي المشكلة التي تواجهها؟
هل هناك أي حل لهذه المشكلة، هل هناك أي إعدادات يجب أن تكون مرتبطة مباشرة بهذا
هل يحدث في الوضع الآمن؟ هل هناك أي أخطاء في المتصفح؟ شكرا.
لقد جربت كل شيء ولا شيء يعمل
جميع مقاطع فيديو يوتيوب لا تعمل على موقعي وتعطيني هذا الخطأ
@hameedacpa، لم تفعل… للتوضيح، يبدو أن هذا قد تم حله في مكان آخر:
هل جربت بالفعل أي حلول عبر الإنترنت؟
لا أعتقد أن الأمر ذي صلة بحالتي
@hameedacpa، لماذا؟ إنه نفس رمز الخطأ.
للأسف، لقد جربت الحل الموصى به ولكنه لا يعمل، أعتقد أن هناك مشكلة داخلية
لست متأكدًا مما إذا كان هذا مرتبطًا، ولكني أرى الكثير من ملفات تعريف الارتباط التي يتم حظرها.
أيضًا، لا توجد أخطاء في وحدة التحكم ولا يزال يحدث في الوضع الآمن…
@hameedacpa ماذا عن إضافة https://youtube.com/ إلى إعداد allowed_iframes؟ لست متأكدًا مما إذا كان ذلك سيساعد.
آمل أن يساعد هذا في تعزيز شكوى OP. بدون أي تغييرات (أنا على الفرع المستقر)، لدي نفس الخطأ حتى عند النقر على تشغيل فيديو موجود كان يعمل سابقًا:
لقد حاولت، عبر الهاتف المحمول، تجاوز جدار حماية المكتب، وتعطيل Cloudflare. لا يوجد حل حتى الآن.
الاختبار هنا مختلط بخطأ في المحرر ولكنه يعرض في المنتدى:
تحديث:
وجدت هذه المقالة التي تقول إن يوتيوب شدد سياساته مؤخرًا بحيث تتضمن رموز التضمين الجديدة referrerpolicy="strict-origin-when-cross-origin" بالإضافة إلى سمات allow المحدثة:
بدون هذه، يرفض يوتيوب طلبات التكوين من الإطار iframe وترى الخطأ 153.
تمكنت من إصلاح هذا باستخدام Cloudflare حتى يتم إصلاحه رسميًا.
بالنسبة لأي شخص يواجه نفس المشكلة، فإن السبب هو أن YouTube يرفض الآن طلبات التضمين التي تفتقر إلى رأس سياسة إحالة صالح.
لقد أضفت رأس Referrer-Policy من خلال قواعد التحويل في Cloudflare (لا حاجة إلى Workers).
إليك ما فعلته:
-
في Cloudflare، انتقل إلى القواعد → قواعد التحويل → تعديل رأس استجابة HTTP.
-
أنشئ قاعدة جديدة، واختر جميع الطلبات الواردة، وأضف رأسًا ثابتًا:
اسم الرأس: Referrer-Policy القيمة: strict-origin-when-cross-origin -
انشر القاعدة.
سأقوم بإزالة هذا بمجرد إصلاحه.
شكرا جزيلا لكم جميعا
لقد وجدت أن المشكلة كانت في التغيير التالي الذي يجب إجراؤه في ملف vhost
ما يلي قادم من ChatGPT
هممم ![]()
وفقًا لفهمي، فإن الطريقة التي يعمل بها Discourse هي أن تغيير Nginx الذي أجريته للتو داخل هذا الحاوية سيتم مسحه عند تشغيل ./launcher rebuild app التالي أو عبر ترقية واجهة المستخدم.
إذا كنت تريد أن يستمر هذا التغيير، فلا يجب عليك التعديل داخل حاوية Discourse قيد التشغيل. ولكن بدلاً من ذلك، قم بإجراء التغيير في /var/discourse/containers/app.yml حتى يستمر عبر عمليات إعادة البناء والتحديثات.
بمجرد الإضافة، يمكنك إعادة البناء:
./launcher rebuild app
لا يستخدم الجميع Cloudflare، ولكن هذا هو السبب في أنني اخترت Cloudflare لهذا الإصلاح. لم أضطر إلى إعادة البناء وكان مجرد حل مؤقت.
نظرًا لأن رؤوس الأمان تعمل بحيث يكون الأخير الذي تم استلامه هو ما يحترمه المتصفح، فقد نجح الأمر.
لقد كانت الطريقة الأسرع والأقل تدخلاً لجعل الأمور تعمل. ولكن إذا كنت تقوم بذلك داخل الحاوية، فضع في اعتبارك أنك ستحتاج إلى إعادة القيام بذلك في كل مرة تقوم فيها بإعادة بناء Discourse أو تحديثه. ![]()
كانت لدينا نفس المشكلة قبل أشهر ولكن لـ 3 مستخدمين فقط. كان مسؤول الاستضافة لدينا بعيدًا ولم يكن لدى أحد إمكانية الوصول إلى إعدادات الاستضافة وابتكرنا هذا:
تحرير السمة وإضافة هذا إلى <HEAD>
<meta name="referrer" content="strict-origin-when-cross-origin">
الحل الخاص بك يعمل مع هذه العلامة الوصفية
<meta name="referrer" content="strict-origin-when-cross-origin">






