অফিস ও VPN ব্যবহারকারীদের জন্য একক CiviCRM URL: সেটআপের ধাপ

একটি অফিস ল্যাপটপের ডেস্কে এবং বাড়ি থেকে VPN-এর মাধ্যমে একই CiviCRM বুকমার্ক খোলা উচিত। ব্যবহারকারীদের সঙ্গে সংস্পর্শে টিকে থাকা নকশা হলো একটি প্রামাণিক ঠিকানা, ধরা যাক https://crm.example.org/, প্রতিটি অবস্থান থেকে অনুমোদিত নেটওয়ার্ক পথ এবং সেই নামের জন্য বৈধ একটি সার্টিফিকেট। VPN পরিবর্তন করে কীভাবে একটি দূরবর্তী ক্লায়েন্ট সার্ভারে পৌঁছায়। এটি কখনোই অ্যাপ্লিকেশনের পরিচয় পরিবর্তন করা উচিত নয়, কারণ যেই মুহূর্তে তা করে, প্রতিটি উৎপন্ন লিঙ্ক, রিডাইরেক্ট ও ইন্টিগ্রেশন কলব্যাক সমাধান করার দ্বিতীয় সমস্যা হয়ে ওঠে।

পথ বেছে নেওয়ার আগে URL বেছে নিন

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

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

ধাপ 1: উভয় গ্রুপের জন্য নামটি সঠিকভাবে রিজলভ হচ্ছে কি না নিশ্চিত করুন

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

অনুমান না করে প্রতিটি প্রসঙ্গ থেকে নামটি পরীক্ষা করুন, এবং DNS থেকে স্বাধীনভাবে curl-এর resolve অপশন দিয়ে পথটি পরীক্ষা করুন, যা একটি অনুরোধের জন্য ঠিকানাটি পিন করে:

dig +short crm.example.org
curl -sSI --resolve crm.example.org:443:10.10.5.20 https://crm.example.org/ | head -5

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

ধাপ 2: ওয়েব সার্ভার, সার্টিফিকেট ও CMS বেস URL মিলিয়ে নিন

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

রিভার্স প্রক্সির পেছনে নিশ্চিত করুন যে অ্যাপ্লিকেশন জানে অনুরোধটি HTTPS-এর মাধ্যমে এসেছে। বেশিরভাগ CMS প্ল্যাটফর্ম সনাক্ত করা স্কিম থেকে পরম লিঙ্ক তৈরি করে, আর যে প্রক্সি মূল স্কিম ফরওয়ার্ড না করে TLS সমাপ্ত করে তা http:// রিসোর্সে ভরা পৃষ্ঠা তৈরি করে যা ব্রাউজার ব্লক করতে পারে। অ্যাপ্লিকেশনকে অনুমান করতে দেওয়ার বদলে বিশ্বস্ত প্রক্সি ও ফরওয়ার্ডেড হেডারগুলো স্পষ্টভাবে কনফিগার করুন।

তারপর CMS ও CiviCRM বেস URL মিলিয়ে নিন। CiviCRM তার নির্ধারিত বেস URL রাখে এবং তা পুনরায় গণনা করার একটি সমর্থিত উপায় দেয়: প্রশাসনিক Cleanup Caches and Update Paths অ্যাকশন, যা CiviCRM ইনস্টলেশন সমস্যা সমাধান নির্দেশিকায় নথিভুক্ত। প্রামাণিক নাম ও CMS সেটিং মিলে যাওয়ার পরে এটি চালান, আগে নয়, নাহলে আপনি যে মানটি বদলাতে যাচ্ছেন তা-ই কেবল ক্যাশ করবেন।

cv flush
# then Administer > System Settings > Cleanup Caches and Update Paths

ধাপ 3: CiviCRM যে ঠিকানাগুলো তৈরি করে তা যাচাই করুন

প্রথম পৃষ্ঠায় পৌঁছানো খুব কম প্রমাণ করে। CiviCRM একটি CMS-এর ভেতরে চলে, এবং গুরুত্বপূর্ণ পৃষ্ঠাগুলো হলো যেগুলো নিজের URL তৈরি করে: লগইন রিডাইরেক্ট, প্রশাসন মেনু, এক্সটেনশন রিসোর্স, আপলোড করা ফাইলের লিঙ্ক এবং কোনো ইন্টিগ্রেশন কর্তৃক নিবন্ধিত যেকোনো বাহ্যিক কলব্যাক।

ড্যাশবোর্ড লোড করুন, একটি কন্ট্যাক্ট রেকর্ড খুলুন, এবং পরম লিঙ্কের জন্য পৃষ্ঠার সোর্স দেখুন। যদি সেগুলো এমন হোস্টনেমের দিকে ইঙ্গিত করে যেখানে কেবল একটি ক্লায়েন্ট গ্রুপ পৌঁছাতে পারে, তবে পৃষ্ঠাটি রেন্ডার হলেও বেস URL এখনো ভুল। যদি সেগুলো সঠিক নাম কিন্তু ভুল স্কিমের দিকে ইঙ্গিত করে, তবে প্রক্সি কনফিগারেশনই ঠিক করার বিষয়।

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

অনুরোধের হোস্টনেম কোনো বিশ্বাসের সিদ্ধান্ত নয়

কোনো অনুরোধ হেডারে নির্দিষ্ট স্ট্রিং আছে বলে বিশেষাধিকারপ্রাপ্ত বেস URL বেছে নেবেন না। PHP এমন Apache কনফিগারেশন নথিভুক্ত করে যেখানে সার্ভার-নামের মান ক্লায়েন্ট-প্রদত্ত হোস্ট প্রতিফলিত করতে পারে, আর সার্ভার ঠিকানা ভেরিয়েবল সার্ভারকে বর্ণনা করে, দর্শকের অবস্থানকে নয়। এর কোনোটিই অ্যাক্সেস-নিয়ন্ত্রণ ব্যবস্থা নয়, এবং সেগুলো থেকে একটি বানানোই সেই পথ যেখানে একটি প্রাইভেট সেবা ভুল হোস্টকে ভুল কনটেন্ট পরিবেশন করে।

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

প্রতিটি অনুমোদিত প্রসঙ্গে একই বুকমার্ক দিয়ে শেষ করুন: একটি লগইন, একটি সাধারণ অভ্যন্তরীণ নেভিগেশন, এবং একটি রিসোর্স অনুরোধ। প্রতিক্রিয়াগুলোতে হোস্টনেমগুলো তুলনা করুন, কেবল পৃষ্ঠাটি লোড হয়েছে কি না তা নয়। এই তিন-অনুরোধ পরীক্ষাটি পথের সমস্যাকে এমন অ্যাপ্লিকেশন থেকে আলাদা করে যা এখনো ভুল ঠিকানা তৈরি করছে, এবং প্রতি ক্লায়েন্ট গ্রুপে প্রায় এক মিনিট সময় নেয়।