पुरानो VPN फाइल पोर्टल प्रतिस्थापन: नियन्त्रणहरू कायम राख्नु

क्लाइन्ट नभएको पुरानो पोर्टलमा मेटाउने बटन, मनपर्ने तारा र इमेलमा टाँसिएको साझा मार्ग थियो। तीमध्ये एउटा मात्र नियन्त्रण हो। पोर्टल प्रतिस्थापन गर्नु भनेको टाढाका प्रयोगकर्तालाई अझै कुन कार्य चाहिन्छ र प्रत्येक कहाँ लागू हुन्छ भन्ने निर्णय गर्नु हो, संयोगवश चलेको पृष्ठको लेआउट दोहोर्याउनु होइन। दुई प्रतिस्थापन आकारले अधिकांश अवस्था समेट्छन्, र ती फरक बिन्दुमा असफल हुन्छन्।

बटन अनुमति होइन

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

मेटाउनु अलग निर्णय योग्य छ किनभने यो त्यही कार्य हो जसको प्रयोगकर्ताले पछुताउँछन्। मेटिएको वस्तु वास्तवमै कहाँबाट पुनर्स्थापित गर्न सकिन्छ सोध्नुहोस्, र उत्तर ल्यापटपको रिसाइकल बिन वा पोर्टलको आफ्नै रद्दीटोकरी हो भनी नमान्नुहोस्। नेटवर्क साझेदारीले सामान्यतया मेटाउने कार्य स्थानीय रिसाइकल बिनबाट जान दिँदैन।

Windows आधारित साझेदारीमा, Volume Shadow Copy ले स्न्यापसट संयन्त्र र ब्याकअप सफ्टवेयरले प्रयोग गर्ने समन्वय प्रदान गर्छ, तर यसको उपस्थितिले यो साझेदारीले पुनर्स्थापना गर्न सकिने संस्करण राख्छ कि राख्दैन भन्ने केही बताउँदैन। फाइल सेवाको मालिकले संस्करण नीति पुष्टि गरी पोर्टल अवकाश लिनुअघि पुनर्स्थापना देखाउनुपर्छ।

विकल्प A: सुरुङमाथि स्थानीय फाइल क्लाइन्ट

म्याप गरिएको ड्राइभ वा SMB क्लाइन्टले प्रयोगकर्ताले पहिले नै जानेका कार्य कायम राख्छ, र अनुमति प्रत्येक अनुरोधमा फाइल सर्भरले लागू गर्छ। महत्त्वपूर्ण पहिचान फाइल सेवाको पहिचान हो, त्यसैले सुरुङले अझै ट्राफिक बोक्ने र खाता अझै रहेसम्म VPN उत्पादन फेरिए पनि पहुँच टिक्छ।

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

पुनर्स्थापना यो आकारको पक्षमा सबैभन्दा बलियो तर्क हो: अघिल्ला संस्करण र पुनर्स्थापना अनुमति प्लेटफर्मका मौलिक हुन्, र हेल्प डेस्कले साइटमा प्रयोग गर्ने त्यही प्रक्रिया प्रयोग गर्न सक्छ।

विकल्प B: प्रोक्सी वा अनुप्रयोग गेटवे

फाइल ल्याएर ब्राउजरमा स्ट्रिम गर्ने पोर्टलले फाइल सेवालाई प्रयोगकर्ताको नेटवर्क मार्गबाहिर राख्छ। उपकरण सुरुङमा सामेल हुन नसक्दा वा संस्थाले प्रत्येक अनुरोध एकै साँघुरो बिन्दुमा अभिलेख गर्न चाहँदा यो उपयोगी हुन्छ। सम्झौता यो हो कि प्रोक्सी प्रत्येक कार्यमा सहभागी बन्छ, र सबैका लागि आफ्नै सेवा खाता प्रयोग गर्नुको सट्टा प्रयोगकर्ताको पहिचान फाइल सेवासम्म पुर्याउनुपर्छ।

मेटाउने र नाम परिवर्तनको व्यवहार वंशानुगत होइन, कार्यान्वयन गर्नुपर्छ। प्रोक्सीले मेटाउने कार्य खोल्यो भने त्यो कार्यले कुनै पहिचानसहित ब्याकएन्डलाई बोलाउँछ, र अडिट ट्रेलले गेटवे होइन, प्रयोगकर्ताको नाम उल्लेख गर्नुपर्छ। प्रोक्सीले नाम परिवर्तन गर्न नसक्ने भए प्रयोगकर्ताले परियोजनाको बीचमा थाहा पाउनुअघि भन्नुहोस्।

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

नाम, पहिचान र तिनीबीचका लिङ्क

स्वीकृत सर्भर र साझा मार्ग वितरण गर्नुहोस्, डोमेन ब्राउजिङ सूची होइन। ब्राउजिङ सुरुङ पार नगर्न सक्ने खोज सेवामा निर्भर छ, र प्रयोगकर्ताको ल्यापटपले डोमेन गणना गर्न सक्ने भएकाले चल्ने मार्ग अर्को अव्यवस्थित उपकरणमा टुट्छ।

सिंगल साइन-अनलाई अनुप्रयोगैपिच्छे समीक्षा गर्नुहोस्। पोर्टलका लागि जारी टोकन त्यसलाई कहिल्यै प्रमाणित नगरेको फाइल सेवामा पुनः नपठाउनुहोस्, र पहिचानकर्ता बोक्ने क्वेरी प्यारामिटर पुरानो बुकमार्कमा देखिएकै भरमा सार्वजनिक लिङ्कमा प्रतिलिपि गर्नु हुँदैन। प्रत्येक स्वीकृत अनुप्रयोगलाई आफ्नै विश्वास सीमा मान्नुहोस्।

आवश्यकता सूचीविरुद्ध छान्नुहोस्

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

चार कार्य र पुनर्स्थापनाको उत्तरसामु तुलना लेख्नुहोस्, त्यसपछि नयाँ मार्गबाट एक पटक पुनर्स्थापना भएपछि मात्र पुरानो पोर्टल अवकाश दिनुहोस्। त्यो परीक्षणले डिजाइनका ती भाग चलाउँछ जसलाई सफल लगइनले कहिल्यै छुँदैन।