পুরোনো ক্লায়েন্টবিহীন পোর্টালে একটি মুছে ফেলার বোতাম, একটি প্রিয় তারকা আর একটি ইমেলে পেস্ট করা শেয়ার পাথ ছিল। এর মধ্যে কেবল একটি নিয়ন্ত্রণ। পোর্টাল বদলানোর মানে হলো দূরবর্তী ব্যবহারকারীদের কোন কাজগুলো এখনো দরকার এবং প্রতিটি কোথায় প্রয়োগ হয় তা ঠিক করা, কোনোভাবে কাজ করা একটি পাতার বিন্যাস নকল করা নয়। দুটি প্রতিস্থাপন কাঠামো বেশিরভাগ ক্ষেত্র ঢেকে দেয়, এবং তারা ভিন্ন জায়গায় ব্যর্থ হয়।

বোতাম কোনো অনুমতি নয়

কাজের তালিকা দিয়ে শুরু করুন: পড়া, আপলোড, নাম বদলানো, মুছে ফেলা। কোন ভূমিকা কোনটি পাবে তা ঠিক করুন, তারপর সেই সিদ্ধান্ত ইন্টারফেসে নয়, ফাইল সেবায় প্রয়োগ করুন। নতুন পোর্টালে মুছে ফেলার নিয়ন্ত্রণ লুকালে ব্যাকএন্ডের অনুমতি অক্ষত থাকে, আর নেটিভ ক্লায়েন্ট ও একই অ্যাকাউন্ট থাকা যে কেউ ফাইলটি মুছে ফেলতে পারে।

মুছে ফেলা আলাদা সিদ্ধান্ত দাবি করে, কারণ এটিই সেই কাজ যার জন্য ব্যবহারকারীরা অনুতপ্ত হয়। জিজ্ঞাসা করুন মুছে ফেলা একটি আইটেম আসলে কোথা থেকে পুনরুদ্ধার করা যায়, এবং উত্তরটি ল্যাপটপের রিসাইকেল বিন বা পোর্টালের নিজের ট্র্যাশ বলে ধরে নেবেন না। একটি নেটওয়ার্ক শেয়ার সাধারণত স্থানীয় রিসাইকেল বিনের মধ্য দিয়ে মুছে ফেলা পাঠায় না।

Windows-সমর্থিত শেয়ারে Volume Shadow Copy স্ন্যাপশট ব্যবস্থা ও ব্যাকআপ সফটওয়্যার যে সমন্বয় ব্যবহার করে তা সরবরাহ করে, কিন্তু এর উপস্থিতি এই শেয়ার আপনার পুনরুদ্ধারযোগ্য সংস্করণ ধরে রাখে কি না সে সম্পর্কে কিছুই বলে না। ফাইল সেবার মালিককে সংস্করণ নীতি নিশ্চিত করতে হবে এবং পোর্টাল অবসরে যাওয়ার আগে একটি পুনরুদ্ধার প্রদর্শন করতে হবে।

বিকল্প A: টানেলের উপর একটি নেটিভ ফাইল ক্লায়েন্ট

একটি ম্যাপ করা ড্রাইভ বা SMB ক্লায়েন্ট ব্যবহারকারীদের ইতিমধ্যে জানা কাজগুলো ধরে রাখে, এবং প্রতিটি অনুরোধে ফাইল সার্ভার অনুমতি প্রয়োগ করে। গুরুত্বপূর্ণ পরিচয় হলো ফাইল সেবার পরিচয়, তাই VPN পণ্য বদলালেও অ্যাক্সেস টিকে থাকে, যতক্ষণ টানেল এখনো ট্র্যাফিক বহন করে এবং অ্যাকাউন্ট এখনো থাকে।

খরচ হলো ক্লায়েন্টকে সেবায় সরাসরি পৌঁছাতে হবে। নাম রিজলিউশন, পোর্ট পৌঁছানোযোগ্যতা এবং প্রমাণীকরণ পদ্ধতি সবই দূরবর্তী অ্যাক্সেস নকশার অংশ হয়ে যায়, আর যে পোর্টাল আগে সংযোগ প্রক্সি করত তা এই প্রতিটি প্রয়োজন লুকিয়ে রাখত। অপরিচালিত ডিভাইসের ব্যবহারকারীরাও তাদের ফাইল ম্যানেজারে মাউন্ট করা একটি শেয়ার পান, যা ব্রাউজার ট্যাবের চেয়ে বিস্তৃত পটভূমি। মাইগ্রেশনের আগে সেই সহায়তা চাপের জন্য বাজেট রাখুন, কারণ এটি গ্রেস পিরিয়ডের পরে নয়, প্রথম দিনেই আসে।

পুনরুদ্ধার এই কাঠামোর সবচেয়ে শক্তিশালী যুক্তি: পূর্ববর্তী সংস্করণ ও পুনরুদ্ধারের অনুমতি প্ল্যাটফর্মের নিজস্ব, এবং হেল্প ডেস্ক সাইটে যে পদ্ধতি ব্যবহার করে সেটিই ব্যবহার করতে পারে।

বিকল্প B: একটি প্রক্সি বা অ্যাপ্লিকেশন গেটওয়ে

যে পোর্টাল ফাইলটি এনে ব্রাউজারে স্ট্রিম করে, তা ফাইল সেবাকে ব্যবহারকারীর নেটওয়ার্ক পথের বাইরে রাখে। এটি উপকারী যখন ডিভাইস টানেলে যোগ দিতে পারে না বা যখন সংস্থা চায় প্রতিটি অনুরোধ একটি একক চোক পয়েন্টে লগ হোক। বিনিময় হলো প্রক্সি প্রতিটি কাজের অংশীদার হয়ে যায়, এবং সবকিছুর জন্য নিজের সেবা অ্যাকাউন্ট ব্যবহার না করে ব্যবহারকারীর পরিচয় ফাইল সেবা পর্যন্ত বহন করতে হয়।

মুছে ফেলা ও নাম বদলানোর আচরণ উত্তরাধিকারসূত্রে নয়, বাস্তবায়ন করতে হয়। প্রক্সি যদি মুছে ফেলার কাজ প্রকাশ করে, সেই কাজটি কিছু পরিচয় দিয়ে ব্যাকএন্ডকে ডাকে, এবং অডিট ট্রেইলে গেটওয়ে নয়, ব্যবহারকারীর নাম থাকা উচিত। প্রক্সি যদি নাম বদলাতে না পারে, ব্যবহারকারীরা প্রকল্পের মাঝপথে তা আবিষ্কারের আগেই বলে দিন।

লিংক পুনর্লিখন হলো যেখানে এই কাঠামো নিঃশব্দে অর্থ বদলে দেয়। পোর্টাল যে URL প্রক্সি করে তা ব্রাউজার সরাসরি যে URL খোলে তার একই বস্তু নয়, আর একটিকে অন্যটিতে রূপান্তর করলে যে প্রমাণীকরণ প্রসঙ্গ এটি কাজ করাত তা ছিঁড়ে যেতে পারে।

নাম, পরিচয় এবং মাঝের লিংকগুলো

অনুমোদিত সার্ভার ও শেয়ার পাথ বিতরণ করুন, ডোমেইন ব্রাউজিং তালিকা নয়। ব্রাউজিং আবিষ্কার সেবার উপর নির্ভর করে যা টানেল পার না-ও হতে পারে, আর যে পাথ কাজ করে কারণ ব্যবহারকারীর ল্যাপটপ একটি ডোমেইন গণনা করতে পারে, তা পরের অপরিচালিত ডিভাইসে ভেঙে যায়।

একক সাইন-অন অ্যাপ্লিকেশন ধরে ধরে পর্যালোচনা করুন। পোর্টালের জন্য ইস্যু করা টোকেন এমন ফাইল সেবায় পুনরায় পাঠানো উচিত নয় যা এটি কখনো যাচাই করেনি, আর আইডেন্টিফায়ার বহনকারী কোয়েরি প্যারামিটার কেবল পুরোনো বুকমার্কে দেখা গিয়েছিল বলে পাবলিক লিংকে কপি করা উচিত নয়। প্রতিটি অনুমোদিত অ্যাপ্লিকেশনকে তার নিজস্ব বিশ্বাস সীমানা হিসেবে গণ্য করুন।

RequirementNative clientProxy portal
Permission enforcementFile service, per requestProxy identity, then file service
Restore pathPlatform versions and backupsProxy trash plus backend restore
Device requirementsTunnel and clientBrowser only
Audit identityFile server logsProxy logs, if it forwards the user

প্রয়োজন তালিকার বিপরীতে বেছে নিন

কোনো কাঠামোই সম্পূর্ণ জেতে না। কার্যকর টানেলসহ পরিচালিত ল্যাপটপে কাজ করা জনশক্তি নেটিভ ক্লায়েন্ট থেকে বেশি পায়, কারণ পুনরুদ্ধার ও অনুমতি পুনর্বাস্তবায়ন নয়, প্ল্যাটফর্ম থেকেই আসে। ঠিকাদার ও ব্যক্তিগত ডিভাইসের মিশ্র জনগোষ্ঠী প্রক্সিকে ন্যায্যতা দিতে পারে, শর্ত হলো পরিচয় অবকাঠামো বাস্তব এবং শেয়ার করা সেবা অ্যাকাউন্ট নয়।

চারটি কাজ ও পুনরুদ্ধারের উত্তর ধরে তুলনাটি লিখে রাখুন, তারপর নতুন পথে একটি পুনরুদ্ধার সম্পন্ন হওয়ার পরেই পুরোনো পোর্টাল অবসরে দিন। সেই পরীক্ষা নকশার সেই অংশগুলো চালায় যা সফল লগইন কখনো স্পর্শ করে না।

সম্পর্কিত নিবন্ধ