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 कनेक्ट नहीं हुआ था, तो फिर से कनेक्ट करें।