HOST151: कैश साझा रीप्ले
इसका क्या अर्थ है
आपके होस्ट का कैश एक व्यक्ति को मिला स्टोर का डेटा दूसरे व्यक्ति को दिखा सकता है।
इस डिवाइस का कोई डेटा नहीं खोता। अपने होस्ट से कहें कि वह स्टोर के API को कैश करना बंद करे (दोनों /wp-json/ और ?rest_route= पते)। यदि WCPOS कनेक्ट नहीं हुआ, तो बाद में फिर से कनेक्ट करें।
कैशिंग लेयर, यह जाँचे बिना कि अनुरोध कौन कर रहा है, सहेजे गए REST API प्रतिसाद दे रही है: ऐप ने अलग-अलग प्रमाणीकरण वाले दो प्रोब भेजे और दोनों बार पहले प्रोब का जवाब मिला। चालू स्टोर पर इसका मतलब है कि एक कैशियर दूसरे का डेटा देख सकता है। यह होस्टिंग लेयर की समस्या है—WordPress हमेशा हर उपयोगकर्ता को उसके अपने डेटा के अनुसार जवाब देता है।
ऐसा होने पर ऐप हर अनुरोध के साथ एक अद्वितीय कैश कुंजी का उपयोग करके फिर से प्रयास करता है। यदि इससे साबित हो जाए कि कुंजी कैश को पार कर सकती है, तो WCPOS कनेक्ट हो जाता है और कुंजी भेजता रहता है—इस स्थिति में यह प्रविष्टि चेतावनी है कि कैश की समस्या अब भी ठीक करनी है। यदि सुरक्षित कनेक्शन साबित न हो सके, तो कैश ठीक होने तक WCPOS कनेक्ट नहीं होता।
आपका डेटा
इस डिवाइस का कोई डेटा नहीं खोता। यदि WCPOS सुरक्षित कनेक्शन साबित नहीं कर सका, तो एक व्यक्ति का डेटा दूसरे को दिखाने का जोखिम लेने के बजाय वह कनेक्ट नहीं होता; डिवाइस पर पहले से मौजूद डेटा वहीं रहता है और कनेक्ट होने पर भेजा जाता है।
समस्या निवारण
आपके होस्ट या साइट व्यवस्थापक के लिए—होस्ट पर कैश ठीक करना आवश्यक है, भले ही WCPOS ने वैकल्पिक तरीके से कनेक्ट कर लिया हो:
- स्टोर के REST API पथ (/wp-json/ और /?rest_route=) को पेज कैशिंग से बाहर रखें—LiteSpeed पर REST कैशिंग बंद करें या no-cache नियम जोड़ें; WP Engine पर WooCommerce अपवाद को /wp-json/wcpos और ?rest_route= रूप तक बढ़ाएँ; Sucuri पर कैशिंग स्तर को Cache-Control का पालन करने के लिए सेट करें।
- स्टोर का API पहले से ही Cache-Control: no-store और Vary: Authorization भेजता है — कैश परत उन्हें अनदेखा कर रही है; होस्ट को उन हेडरों की ओर इंगित करें।
- कैश सेटिंग बदलने के बाद कैश साफ़ करें। यदि WCPOS कनेक्ट नहीं हुआ था, तो फिर से कनेक्ट करें।