HOST151: إعادة تشغيل مشتركة من التخزين المؤقت
ماذا يعني هذا
قد تعرض ذاكرة التخزين المؤقت لدى مضيفك بيانات متجر شخص لآخر.
لم يُفقد أي شيء على هذا الجهاز. اطلب من مزود الاستضافة إيقاف تخزين API الخاص بالمتجر مؤقتًا (/wp-json/ وعناوين ?rest_route=). إذا لم يتصل WCPOS، فأعد الاتصال بعد ذلك.
تقدّم طبقة التخزين المؤقت استجابات REST API المخزنة دون التحقّق من هوية مقدم الطلب: أرسل التطبيق طلبَي تحقق بهويتين مختلفتين، لكنه تلقى إجابة الطلب الأول في المرتين. في متجر فعلي، يعني ذلك أن أمين صندوق قد يرى بيانات شخص آخر. هذه مشكلة في طبقة الاستضافة؛ أما WordPress نفسه فيقدّم دائمًا إجابة خاصة بكل مستخدم.
عند حدوث ذلك، يعيد التطبيق المحاولة باستخدام مفتاح تخزين مؤقت فريد لكل طلب. إذا أثبت ذلك أن المفتاح يتجاوز ذاكرة التخزين المؤقت، فسيتصل WCPOS ويواصل إرسال المفتاح؛ ويكون هذا الإدخال حينها تحذيرًا بأن ذاكرة التخزين المؤقت ما زالت بحاجة إلى إصلاح. وإذا تعذّر إثبات إمكانية الاتصال بأمان، فلن يتصل WCPOS حتى تُصلح ذاكرة التخزين المؤقت.
بياناتك
لن يُفقد أي شيء على هذا الجهاز. إذا لم يتمكن WCPOS من إثبات أمان الاتصال، فلن يتصل بدلًا من المخاطرة بعرض بيانات شخص لآخر؛ وستبقى أي بيانات موجودة على هذا الجهاز وتُرسل عند اتصاله.
استكشاف الأخطاء وإصلاحها
لمضيفك أو مسؤول الموقع — يجب إصلاح ذاكرة التخزين المؤقت على المضيف، حتى لو اتصل WCPOS بعد تجاوز المشكلة:
- استثنِ مسارات REST API الخاصة بالمتجر (/wp-json/ و/?rest_route=) من التخزين المؤقت للصفحات — في LiteSpeed عطّل التخزين المؤقت لاستجابات REST أو أضف قاعدة تمنع التخزين؛ وفي WP Engine وسّع استثناء WooCommerce ليشمل /wp-json/wcpos وصيغة ?rest_route=؛ وفي Sucuri اضبط مستوى التخزين المؤقت ليحترم Cache-Control.
- ترسل واجهة API الخاصة بالمتجر بالفعل Cache-Control: no-store وVary: Authorization — لكن طبقة التخزين المؤقت تتجاهلهما؛ فوجّه المضيف إلى هاتين الترويستين.
- بعد تغيير إعدادات التخزين المؤقت، أفرغ ذاكرته. إذا لم يتصل WCPOS، فأعِد الاتصال.