APM পোর্টাল অ্যাক্সেস: অ্যাপ্লিকেশন সেশন কার?

BIG-IP APM Portal Access দিয়ে একটি ইন্ট্রানেট অ্যাপ প্রকাশ করা সেশন নিয়ে সিদ্ধান্ত, ভার্চুয়াল সার্ভার কপি করা নয়। পোর্টাল ব্যবহারকারীকে ঢোকায়, রিরাইট প্রোফাইল নির্বাচিত রিকোয়েস্ট গেটওয়ে পথে রাখে, আর অ্যাপ্লিকেশন তখনও নিজের সেশন ধরে রাখে। পাঁচটি পরীক্ষা অনুমানযোগ্য আচরণ করা ডিজাইনকে সেই অবস্থা থেকে আলাদা করে যেখানে হেল্প ডেস্ক একেক ব্যবহারকারীর কাছে টাইমআউট সম্পর্কে জানতে পারে। ক্রমে এগুলো করুন এবং প্রথম যে পরীক্ষা সত্য নয় সেখানেই থামুন।

পরীক্ষা 1: রিসোর্স প্রকাশিত, শুধু লিংক করা নয়

webtop বুকমার্ক প্রমাণ করে ব্যবহারকারী একটি এন্ট্রি দেখতে পান। এটি প্রমাণ করে না অ্যাপ্লিকেশন প্রকাশিত। access profile, rewrite profile এবং এদের একত্র করা virtual server খুঁজুন, তারপর নিশ্চিত করুন resource assignment আপনার ধারণা করা অ্যাপ্লিকেশনেই নির্দেশ করে কি না। এই তিনটির কোনোটি অনুপস্থিত বা অসঙ্গত হলে বাকি তালিকা অর্থহীন।

অর্ধ-প্রকাশিত অবস্থা এন্ট্রি পয়েন্টে সুস্থ দেখায়। virtual server access profile বহন করে, অথচ rewrite profile অন্য একটি resource URI-তে সীমাবদ্ধ, তাই webtop এন্ট্রি দেখা যায় ও প্রথম পৃষ্ঠা লোড হয়, তারপর sub-path রিকোয়েস্ট গেটওয়ে পথ ছেড়ে সরাসরি ব্যাকএন্ডে পৌঁছায়। বিপরীত ছবিটি হলো ভুল অ্যাপ্লিকেশনকে দেওয়া resource: বুকমার্ক খোলে, আর এমন কিছু খোলে যা কেউ অনুমোদন করেনি।

পরীক্ষা 2: ব্যাকএন্ড সেশন আলাদা অবস্থা

APM ব্যবহারকারীকে সাইন ইন করা ধরে নিলেও ব্যাকএন্ড নিজের authentication দাবি করতে পারে। সমর্থিত SSO integration এই সম্পর্ক আপনার জন্য তৈরি করে, কিন্তু পোর্টাল লগইন গ্রহণ করলেই প্রতিটি অ্যাপ্লিকেশন একই credentials বা একই session cookie গ্রহণ করে না। রিসোর্সের জন্য SSO কনফিগার না থাকলে অ্যাপ্লিকেশন ইতিমধ্যেই authenticated পোর্টালের ভেতরে নিজের লগইন চাইবে।

দৃশ্যমান prompt বদলাতে SSO বন্ধ করা একটি প্রচলিত ও দুর্বল শর্টকাট: এটি prompt তৈরি করা lifecycle-এ হাত না দিয়েই authentication ডিজাইন বদলে দেয়। এর বদলে ঠিক করুন ব্যাকএন্ড লগইন আদৌ দেখা উচিত কি না, আর দেখা উচিত হলে সেটিকে প্রকাশিত flow-এর স্পষ্ট অংশ করুন।

পরীক্ষা 3: দুটি ঘড়ি আছে, আর তারা একই ঘড়ি নয়

APM-এর access profile একটি inactivity timeout ও সর্বোচ্চ session lifetime বহন করে। অ্যাপ্লিকেশন নিজের idle timer ও cookie expiry বহন করে। পোর্টালের timer বাড়ালে অ্যাপ্লিকেশন session বাড়ে না, আর অ্যাপ্লিকেশন session ছোট করলে ব্যবহারকারী পোর্টাল থেকে লগআউট হন না।

ক্লাসিক সাপোর্ট কল আসে এক অমিল জোড়া থেকে: পোর্টাল এখনও বৈধ, অ্যাপ্লিকেশন session নয়, আর ব্যবহারকারী এমন একটি লগইন ফর্ম দেখেন যা পোর্টালের বিপরীত মনে হয়। এটি সঠিক আচরণ, ত্রুটি নয়, আর সমাধান হলো এই অ্যাপ্লিকেশনের জন্য কোন ঘড়ি আগে শেষ হবে তা বেছে নেওয়া।

পরীক্ষা 4: লগআউটের নির্দিষ্ট পরিধি আছে

লিখে রাখুন অ্যাপ্লিকেশনের sign-out বোতাম কী শেষ করবে: কেবল সেই অ্যাপ্লিকেশন, পুরো APM session, নাকি আরও বড় identity-provider session। access profile ঐচ্ছিক বিলম্বসহ একটি logout URI তালিকা সমর্থন করে, আর এভাবেই প্রয়োজনে অ্যাপ্লিকেশনের logout পোর্টাল session শেষ করে। এটি ছাড়া অ্যাপ্লিকেশনের logout পোর্টালকে জীবিত রাখে, আর পরের রিকোয়েস্ট নিঃশব্দে ব্যবহারকারীকে আবার ঢুকিয়ে দিতে পারে।

একই পোর্টালের অন্য রিসোর্সে প্রভাব হিসাব করুন। একটি অ্যাপ্লিকেশন থেকে logout ছয়টি অন্যটির session শেষ করলে ব্যবহারকারীরা একে বাগ বলবে, যদি না আচরণটি আগে অ্যাপ্লিকেশন মালিকের সঙ্গে সম্মত হয়। ট্যাব বন্ধ করা আর webtop-এ ফেরা কোনো কিছু শেষ হওয়ার প্রমাণ নয়।

পরীক্ষা 5: অ্যাপ্লিকেশন রিরাইটিং সহ্য করে

Portal Access নির্বাচিত ওয়েব কনটেন্ট রিরাইট করে, আর রিরাইটিংয়ের সীমা আছে। আধুনিক client-side ফিচার, background worker, upload flow ও federated login কোনো নির্দিষ্ট release-এর পরিধির বাইরে পড়তে পারে। F5-এর সংস্করণভিত্তিক compatibility matrix হলো প্রতিশ্রুতি দেওয়ার আগে পড়ার নথি, কারণ সীমাগুলো release-নির্দিষ্ট।

landing page নয়, গুরুত্বপূর্ণ flow পরীক্ষা করুন: সাইন ইন করুন, প্রতিটি প্রয়োজনীয় ফাংশনে যান, অ্যাপ upload করলে upload করুন, নির্ধারিত session শেষ হতে দিন এবং প্রতিটি logout পথ অনুসরণ করুন। একবার রেন্ডার হওয়া পৃষ্ঠা অ্যাপ্লিকেশন কাজ করার প্রমাণ নয়।

প্রয়োজনীয় flow রিরাইট করা না গেলে ডকুমেন্টেড federation, reverse proxy বা network-access ডিজাইনে যান। সাধারণ tunnel-এর মতো আচরণ করতে বলা browser portal ডেমো পাস করবে আর অডিটে ব্যর্থ হবে।