VPN आपके डेवलपर प्रीव्यू को साझा करने के लिए सुरक्षित क्यों नहीं बनाता
VPN परीक्षकों को आपके प्रोटोटाइप तक एक मार्ग देता है; यह प्रीव्यू को सुरक्षित नहीं बनाता। साझा करने से पहले दर्शक, रनटाइम, डेटा और दुष्प्रभाव तय करें।
प्रोटोटाइप को VPN के पीछे रखना निजी लगता है, इसलिए बचा हुआ एकमात्र सवाल यह लगता है कि प्रोफ़ाइल किसे मिलेगी। यह अनुमान एक ख़ास तरीक़े से विफल होता है: सुरंग नियंत्रित करती है कि कौन होस्ट तक पहुँच सकता है, यह नहीं कि वहाँ पहुँचने के बाद होस्ट क्या उजागर करता है। प्रीव्यू अब भी रनटाइम चलाता है, डेटा रखता है और ऐसे इंटीग्रेशन कॉल करता है जो असली ईमेल भेज सकते हैं या असली डेटाबेस में लिख सकते हैं। VPN को सामने का दरवाज़ा मानें और फिर उसके पीछे का कमरा डिज़ाइन करें।
मार्ग दर्शक नहीं होता
VPN में परीक्षक को जोड़ना ठीक एक सवाल का जवाब देता है: क्या यह डिवाइस पते तक पहुँच सकता है? यह इस बारे में कुछ नहीं कहता कि वह डिवाइस कौन से पेज, API या कंसोल इस्तेमाल कर सकता है। ये अलग अनुमतियाँ हैं, और केवल पते जानने वाला गेटवे उन्हें लागू नहीं कर सकता।
प्रीव्यू अनुबंध को छोटी सूची के रूप में लिखें: होस्टनेम, लिसनर, अनुमत ऑपरेशन और कौन सी भूमिका किसके पास है। फिर जाँचें कि सूची वास्तव में जो उजागर है उससे मेल खाती है।
जो परीक्षक प्रोटोटाइप खोल सकता है, उसे डिप्लॉयमेंट कंसोल, डेटाबेस एडमिन पेज या डेवलपर की होम डायरेक्टरी की ज़रूरत नहीं है। अगर गेटवे सबनेट मार्ग देता है, तो ये सब डिफ़ॉल्ट रूप से पहुँच योग्य हैं। प्रति-गंतव्य मार्ग को प्राथमिकता दें, या अतिरिक्त सेवाओं को उनके अपने प्रमाणीकरण के पीछे रखें। दोनों में से कोई भी विकल्प यह सीमित करता है कि चोरी हुई प्रोफ़ाइल क्या कर सकती है।
आप जो रनटाइम साझा करते हैं वह अनुबंध का हिस्सा है
डीबगर और ऑटो-रीलोड वाला डेवलपमेंट सर्वर एक मशीन पर एक व्यक्ति के लिए औज़ार है। फ़्रेमवर्क का दस्तावेज़ इस बारे में स्पष्ट है: Flask की डिप्लॉयमेंट गाइड कहती है कि उसका डेवलपमेंट सर्वर और डीबगर उत्पादन के लिए नहीं हैं, और यह निजी या एकल-उपयोगकर्ता सेवाओं को भी उत्पादन मानती है। यही तर्क किसी भी ऐसे फ़्रेमवर्क पर लागू होता है जिसमें रीलोडर और इंटरैक्टिव त्रुटि पेज है। सुविधा की विशेषताएँ फ़ाइल सहेजने और बदलाव देखने के बीच का लूप छोटा करने के लिए बनी हैं, उस परीक्षक का सामना करने के लिए नहीं जिसे आप नियंत्रित नहीं करते।
इंटरैक्टिव ट्रेसबैक जानकारी का रिसाव है और कुछ डीबगर में कोड निष्पादन की सतह है। इसे प्रीव्यू से दूर रखें, या प्रीव्यू को ऐसे बिल्ड तक सीमित करें जो इसे सक्षम न कर सके। अगर परीक्षकों को निदान चाहिए, तो उन्हें कंसोल के बजाय लॉग दें।
वाइल्डकार्ड लिसनर इस भूल का दूसरा आधा हिस्सा है। हर इंटरफ़ेस पर बाइंड करना सेवा को उन नेटवर्क पर उजागर करता है जिनका आपने इरादा नहीं किया था, जिनमें कैफ़े का Wi-Fi भी शामिल है।
फेंकने योग्य खाते और असली दुष्प्रभाव रहित डेटा इस्तेमाल करें
परीक्षण के लिए बनाए गए खाते और ऐसा डेटा इस्तेमाल करें जो किसी को शर्मिंदा न कर सके। ख़तरनाक हिस्सा शायद ही कभी डेटाबेस की पंक्ति होता है; वह बटन के पीछे का इंटीग्रेशन होता है। ईमेल, भुगतान, SMS, वेबहुक और फ़ाइल निर्यात सब प्रीव्यू से बाहर पहुँचते हैं।
प्रोटोटाइप जो भी बाहर जाने वाला प्रभाव पैदा कर सकता है, उसकी सूची बनाएँ, फिर हर एक को सैंडबॉक्स की ओर मोड़ें या उसे बंद करें। निजी मार्ग किसी जीवंत भुगतान एंडपॉइंट को हानिरहित नहीं बनाता।
उत्पादन क्रेडेंशियल अलग रूप में वही समस्या हैं। जो प्रीव्यू सेटअप का समय बचाने के लिए उत्पादन API कुंजी विरासत में लेता है, वह डीबग UI वाला उत्पादन सिस्टम है। सबसे छोटी उपयोगी अनुमतियों के साथ सीमित क्रेडेंशियल बनाएँ। प्रीव्यू ख़त्म होने पर उन्हें बदलें, क्योंकि जीवंत कुंजियों वाला रद्द किया गया प्रीव्यू अब भी जीवित है।
पेज, एसेट और सॉकेट जाँचें
जो पेज रेंडर होता है वह काम करने वाला प्रीव्यू नहीं है। HTML लोड हो सकता है जबकि कोई एसेट होस्ट, API या WebSocket अब भी ऐसे URL की ओर इशारा कर रहा हो जहाँ परीक्षक नहीं पहुँच सकता। इनमें से हर एक अनुबंध में अलग प्रविष्टि है।
स्वीकृत डिवाइस से पेज और सबसे बड़ा एसेट अलग-अलग माँगें:
curl -sS -o /dev/null -w "%{http_code}" https://preview.staging.example/
curl -sS -o /dev/null -w "%{http_code}" https://preview.staging.example/assets/app.js
फिर असली इंटरैक्शन के दौरान ब्राउज़र कंसोल देखें और पुष्टि करें कि लाइव-रीलोड सॉकेट जुड़ता है। अगर नहीं, तो सुधार उस एंडपॉइंट के लिए जानबूझकर बनाया गया मार्ग है, ऐसा नियम नहीं जो पेज पूरा दिखने तक चौड़ा होता जाए।
प्रीव्यू को याददाश्त पर नहीं, तारीख़ पर सेवानिवृत्त करें
प्रीव्यू बनाते ही उसे एक मालिक और एक समाप्ति तिथि दें। जब तारीख़ आए, तो प्रविष्टि, परीक्षक पहचान और अस्थायी क्रेडेंशियल उस कॉन्फ़िगरेशन के ज़रिए हटाएँ जो उनका मालिक है। भूला हुआ प्रीव्यू ही वह रास्ता है जिससे निजी प्रोटोटाइप स्थायी सार्वजनिक बन जाता है।
बाहर से सेवानिवृत्ति सत्यापित करें: होस्टनेम का हल होना बंद होना चाहिए या अस्वीकृत क्लाइंट को जवाब देना बंद होना चाहिए।
स्रोत और रिकवरी नोट्स रखें, पर फ़ॉलबैक नहीं। अच्छे प्रीव्यू बाउंड्री का परीक्षण उबाऊ है: स्वीकृत डिवाइस आवश्यक क्रियाएँ कर सकता है, और अस्वीकृत पहचान नहीं कर सकती। सुरंग बंद होने के बाद भी यही सच होना चाहिए। वह परिणाम हर डेवलपमेंट सुविधा सक्षम के साथ चल रहे प्रोटोटाइप के बगल में VPN आइकन से अधिक मूल्यवान है।