पुराने VPN फ़ाइल पोर्टल को बदलना: नियंत्रण बनाए रखें

पुराने क्लाइंट-रहित पोर्टल में एक डिलीट बटन, एक पसंदीदा स्टार और ईमेल में चिपकाया गया एक शेयर पाथ था। इनमें से केवल एक नियंत्रण है। पोर्टल बदलने का अर्थ है यह तय करना कि दूरस्थ उपयोगकर्ताओं को अब भी कौन-से परिचालन चाहिए और हर एक कहाँ लागू होता है, न कि किसी ऐसे पेज का लेआउट दोहराना जो संयोग से काम कर गया था। दो प्रतिस्थापन आकार ज़्यादातर मामलों को कवर करते हैं, और वे अलग-अलग जगहों पर विफल होते हैं।

बटन अनुमति नहीं है

परिचालन सूची से शुरू करें: पढ़ना, अपलोड करना, नाम बदलना, हटाना। तय करें कि कौन-सी भूमिकाएँ क्या पाती हैं, फिर उस निर्णय को इंटरफ़ेस में नहीं बल्कि फ़ाइल सेवा पर लागू करें। नए पोर्टल में डिलीट नियंत्रण छिपाने से बैकएंड अनुमति बरकरार रहती है, और जिसके पास नेटिव क्लाइंट और वही खाता है वह अब भी फ़ाइल हटा सकता है।

हटाने पर अलग निर्णय इसलिए ज़रूरी है क्योंकि यही वह परिचालन है जिस पर उपयोगकर्ताओं को पछतावा होता है। पूछें कि हटाई गई वस्तु वास्तव में कहाँ से पुनर्प्राप्त हो सकती है, और यह न मानें कि उत्तर लैपटॉप का रीसायकल बिन या पोर्टल का अपना ट्रैश है। नेटवर्क शेयर आम तौर पर हटाने को स्थानीय रीसायकल बिन से नहीं गुज़ारता।

Windows-आधारित शेयर पर, Volume Shadow Copy स्नैपशॉट मशीनरी और वह समन्वय देता है जो बैकअप सॉफ़्टवेयर उपयोग करता है, लेकिन इसकी उपस्थिति यह नहीं बताती कि यह शेयर ऐसे संस्करण रखता है जिन्हें आप पुनर्स्थापित कर सकें। पोर्टल को सेवानिवृत्त करने से पहले फ़ाइल-सेवा के स्वामी को संस्करण नीति की पुष्टि करनी होगी और एक पुनर्स्थापन प्रदर्शित करना होगा।

विकल्प A: टनल के ऊपर नेटिव फ़ाइल क्लाइंट

मैप्ड ड्राइव या SMB क्लाइंट वे परिचालन बनाए रखता है जिन्हें उपयोगकर्ता पहले से जानते हैं, और अनुमतियाँ हर अनुरोध पर फ़ाइल सर्वर द्वारा लागू होती हैं। मायने रखने वाली पहचान फ़ाइल-सेवा की पहचान है, इसलिए पहुँच VPN उत्पाद बदलने पर भी टिकी रहती है, जब तक टनल ट्रैफ़िक ले जाता है और खाता मौजूद रहता है।

कीमत यह है कि क्लाइंट को सीधे सेवा तक पहुँचना होता है। नाम समाधान, पोर्ट पहुँच और प्रमाणीकरण विधि सभी दूरस्थ-पहुँच डिज़ाइन का हिस्सा बन जाते हैं, और जो पोर्टल पहले कनेक्शन का प्रॉक्सी करता था वह इन सभी आवश्यकताओं को छिपा देता था। अनिर्वित मोबाइल उपकरणों पर उपयोगकर्ताओं को अपने फ़ाइल मैनेजर में माउंट किया हुआ शेयर भी मिलता है, जो ब्राउज़र टैब से अधिक चौड़ी सतह है। माइग्रेशन से पहले उस सहायता भार के लिए बजट रखें, क्योंकि वह पहले ही दिन आता है, किसी छूट अवधि के बाद नहीं।

रिकवरी इस आकार के पक्ष में सबसे मज़बूत तर्क है: पिछले संस्करण और पुनर्स्थापन अनुमतियाँ प्लेटफ़ॉर्म के मूल हैं, और हेल्प डेस्क वही प्रक्रिया अपना सकता है जो वह साइट पर अपनाता है।

विकल्प B: प्रॉक्सी या एप्लिकेशन गेटवे

जो पोर्टल फ़ाइल लाकर उसे ब्राउज़र तक स्ट्रीम करता है, वह फ़ाइल सेवा को उपयोगकर्ता के नेटवर्क पाथ से बाहर रखता है। यह तब उपयोगी है जब उपकरण टनल में शामिल नहीं हो सकता या जब संगठन चाहता है कि हर अनुरोध एक ही अवरोध बिंदु पर लॉग हो। नुकसान यह है कि प्रॉक्सी हर परिचालन में भागीदार बन जाता है, और उसे हर चीज़ के लिए अपना सेवा खाता उपयोग करने के बजाय उपयोगकर्ता की पहचान फ़ाइल सेवा तक पहुँचानी होती है।

हटाने और नाम बदलने का व्यवहार विरासत में मिलने के बजाय लागू करना पड़ता है। यदि प्रॉक्सी कोई डिलीट क्रिया देता है, तो वह क्रिया किसी पहचान के साथ बैकएंड को कॉल करती है, और ऑडिट ट्रेल में गेटवे के बजाय उपयोगकर्ता का नाम होना चाहिए। यदि प्रॉक्सी नाम नहीं बदल सकता, तो यह उपयोगकर्ताओं के किसी प्रोजेक्ट के बीच में पता चलने से पहले बता दें।

लिंक रीराइटिंग वह जगह है जहाँ यह आकार चुपचाप अर्थ बदलता है। जिस URL का पोर्टल प्रॉक्सी करता है वह उस URL जैसी वस्तु नहीं है जिसे ब्राउज़र सीधे खोलता है, और एक को दूसरे में बदलने से वह प्रमाणीकरण संदर्भ हट सकता है जिसने उसे काम करने लायक बनाया था।

नाम, पहचानें, और बीच के लिंक

स्वीकृत सर्वर और शेयर पाथ बाँटें, डोमेन ब्राउज़िंग सूची नहीं। ब्राउज़िंग डिस्कवरी सेवाओं पर निर्भर करती है जो टनल पार नहीं कर सकतीं, और जो पाथ इसलिए काम करता है कि उपयोगकर्ता का लैपटॉप डोमेन की गणना कर सकता है, वह अगले अनिर्वित उपकरण पर टूट जाता है।

सिंगल साइन-ऑन की समीक्षा एप्लिकेशन दर एप्लिकेशन करें। पोर्टल के लिए जारी टोकन उस फ़ाइल सेवा को नहीं दोहराया जाना चाहिए जिसने उसे कभी मान्य नहीं किया, और पहचानकर्ता ले जाने वाले क्वेरी पैरामीटर केवल इसलिए सार्वजनिक लिंक में नहीं कॉपी होने चाहिए कि वे पुराने बुकमार्क में दिखे थे। हर स्वीकृत एप्लिकेशन को अपनी अलग ट्रस्ट सीमा मानें।

आवश्यकता सूची के विरुद्ध चुनें

कोई भी आकार सीधे जीतता नहीं है। काम करने वाले टनल के साथ प्रबंधित लैपटॉप पर काम करने वाला कार्यबल नेटिव क्लाइंट से अधिक पाता है, क्योंकि पुनर्स्थापन और अनुमतियाँ प्लेटफ़ॉर्म से आती हैं, किसी पुनः कार्यान्वयन से नहीं। ठेकेदारों और व्यक्तिगत उपकरणों की मिश्रित आबादी प्रॉक्सी को उचित ठहरा सकती है, बशर्ते पहचान की पाइपलाइन वास्तविक हो और साझा सेवा खाता न हो।

तुलना को चार परिचालनों और रिकवरी के उत्तर के सामने लिख लें, और पुराने पोर्टल को तभी सेवानिवृत्त करें जब नए पाथ से एक बार पुनर्स्थापन हो चुका हो। वह परीक्षण डिज़ाइन के उन हिस्सों को चलाता है जिन्हें सफल लॉगिन कभी नहीं छूता।