موقعك يشتغل عندك، وبعد النشر نص الصفحة فاضي: البيانات ما تنعرض، أو تسجيل الدخول ما يرد. تفتح F12 وتلقى في Console سطر أحمر يبدأ بـ Mixed Content: The page at ... was loaded over HTTPS, but requested an insecure ... (بعدها resource أو XMLHttpRequest endpoint حسب نوع الطلب)، وفيه This request has been blocked; the content must be served over HTTPS. المعنى: صفحتك آمنة، لكنها طلبت شيء من رابط غير آمن، والمتصفح رفض.
إيش يعني بالضبط
موقعك المنشور يفتح على https://، يعني الاتصال بين الزائر وموقعك مشفّر. لو الصفحة طلبت بيانات من رابط يبدأ بـ http://، هالطلب يمشي بدون تشفير، وأي أحد في نص الطريق، مثل شبكة واي فاي عامة، يقدر يقرأه أو يغيّره. عشان كذا المتصفحات تمنع هالطلبات تلقائيًا لما تكون الصفحة نفسها على HTTPS.
الصور والصوت والفيديو يحاول المتصفح يحوّلها لـ https بنفسه، فإذا ما اشتغلت تطلع مكسورة. لكن لو الرابط عنوان IP، أو الصورة داخل srcset أو <picture>، تنمنع مباشرة. أما طلبات البيانات (fetch) فتنمنع دايم.
ليش يظهر بعد النشر بالذات
على جهازك كل شيء على http://localhost، فما فيه خلط. الخلط يبدأ لما الواجهة تنتقل لـ https وشيء ثاني يبقى على http:
- رابط السيرفر مكتوب ثابت: الذكاء الاصطناعي كتب
http://قدام عنوان السيرفر داخل الكود، أو في متغير إعدادات. أماhttp://localhost:3000فالمتصفح ما يعتبره Mixed Content، لكنه يفشل عند الزائر بخطأ اتصال، لأن السيرفر مو على جهازه. شوف درس متغيرات البيئة اللي تطلع undefined. - سيرفر على عنوان IP: الواجهة على Vercel أو Netlify، والسيرفر الخلفي على VPS عنوانه رقم مثل
http://203.0.113.10:8000بدون شهادة. - روابط محفوظة في قاعدة البيانات: صور أو ملفات انحفظت روابطها بـ
http://وقت التجربة، وتنعرض كذا للأبد. - سكربتات أو خطوط خارجية مضافة بروابط قديمة تبدأ بـ
http://.
كيف تتأكد بنفسك
- افتح الصفحة المنشورة، و F12، وتبويب Console. كل رسالة Mixed Content فيها الرابط اللي انمنع بالضبط.
- انسخ الجزء الثابت من الرابط، مثل اسم السيرفر، وابحث عنه في الكود وفي إعدادات النشر (Environment Variables).
- لو الرابط صورة أو ملف، ابحث عنه في جداول قاعدة البيانات اللي تحفظ الروابط.
- جرّب تفتح نفس الرابط بعد ما تغيّر
httpإلىhttps. لو فتح، الحل سهل. لو ما فتح، السيرفر نفسه ما عنده شهادة، وهذا لازم ينحل أول.
الحل الصح
- كل شيء على HTTPS: السيرفر الخلفي لازم يكون له اسم نطاق، مثل
api.example.com، وشهادة SSL. أغلب منصات الاستضافة تعطيك هذا تلقائيًا، وعلى VPS تقدر تضيفه بشهادة مجانية مثل Let's Encrypt أو عن طريق Cloudflare. - رابط السيرفر في الإعدادات: الواجهة تاخذ رابط السيرفر من متغير إعدادات يختلف بين جهازك والنشر، مو مكتوب داخل الكود. وإذا الواجهة والسيرفر على نفس النطاق، الأفضل روابط نسبية مثل
/api/orders. - روابط قاعدة البيانات: تتحدّث مرة وحدة لـ
https، والكود اللي يحفظ روابط جديدة يتأكد إنهاhttps. - بعد التصليح أعد النشر، لأن متغيرات الواجهة تنكتب داخل الملفات وقت البناء.
الحل اللي لا تسويه
بعض الاقتراحات اللي تشوفها: تقول للمستخدمين يسمحون بالمحتوى غير الآمن من إعدادات المتصفح، أو تنشر الموقع كله على http عشان «يختفي الخطأ». الاثنين يعني إن كلمات السر وبيانات الدفع تمشي بدون تشفير.
وفيه اقتراح ثالث: تضيف upgrade-insecure-requests وتعتبرها خلصت. هذي تخلّي المتصفح يطلب نفس الرابط على https، فإذا السيرفر ما عنده شهادة، الطلب يفشل بخطأ ثاني بدل ما ينحل.
كيف تمنع إنه يرجع
الخطأ هذا يرجع مع أول ميزة جديدة يكتبها الذكاء الاصطناعي، لأنه يكتب الروابط اللي يشوفها على جهازك. ثلاث عادات بسيطة تكفي:
- قبل كل نشر، ابحث في الكود عن
http://. أي نتيجة خارج ملفات الإعدادات وملفات الاختبار تستاهل نظرة. - لما تطلب من أداة الذكاء الاصطناعي ميزة تكلّم السيرفر، قل لها صراحة إن رابط السيرفر يجي من متغير الإعدادات، مو مكتوب في الكود.
- بعد كل نشر، افتح الموقع المنشور مرة وحدة و F12 مفتوح. السطر الأحمر يبان في ثواني، قبل ما يشوفه عميل.
إذا تبي أحد يشوفه معك
إذا السيرفر الخلفي محتاج نطاق وشهادة وما تدري من وين تبدأ، احجز مكالمة استشارية ونرتّبها معك على المكالمة. ولو النشر نفسه فيه أكثر من مشكلة، اقرأ يشتغل عندك ثم يتعطّل بعد النشر؟