कार्यालय और VPN उपयोगकर्ताओं के लिए एक CiviCRM URL: सेटअप के चरण

कार्यालय का लैपटॉप अपने डेस्क पर और घर से VPN के ज़रिए फिर वही CiviCRM बुकमार्क खोलना चाहिए। उपयोगकर्ताओं के संपर्क में टिकने वाला डिज़ाइन एक विहित पता है, मान लीजिए https://crm.example.org/, हर स्थान से स्वीकृत नेटवर्क मार्ग और उस नाम के लिए वैध प्रमाणपत्र के साथ। VPN बदलता है कि दूरस्थ क्लायंट सर्वर तक कैसे पहुँचता है। इसे कभी एप्लिकेशन की पहचान नहीं बदलनी चाहिए, क्योंकि जिस पल यह ऐसा करता है, हर उत्पन्न लिंक, रीडायरेक्ट और इंटीग्रेशन कॉलबैक हल करने योग्य दूसरी समस्या बन जाता है।

मार्ग चुनने से पहले URL चुनें

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

एक्सेस योजना में चार मान साथ-साथ दर्ज करें, क्योंकि वे केवल एक समुच्चय के रूप में काम करते हैं। विहित URL। वह उत्तर जो उस नाम के लिए हर क्लायंट समूह को मिलना चाहिए। उस उत्तर के लिए मार्ग और एक्सेस नियम। वह होस्टनाम जिसे वेब सर्वर और प्रमाणपत्र परोसने के लिए कॉन्फ़िगर किए गए हैं। जब बाद में कुछ टूटता है, तो टूटा हुआ घटक उन चार में से एक होता है, और आप जानेंगे कि आपने कौन-सा बदला।

चरण 1: सुनिश्चित करें कि नाम दोनों समूहों के लिए सही ढंग से हल हो

दोनों समूहों को एक निजी उत्तर मिलना चाहिए जहाँ वे वास्तव में पहुँच सकें, और यह वैध है कि उत्तर भिन्न हों जब तक नाम भिन्न न हो। LAN क्लायंट आंतरिक रिज़ॉल्वर से हल करते हैं; VPN क्लायंट को ऐसी रिज़ॉल्वर नीति चाहिए जो उन्हें वही ज़ोन दे, बजाय क्वेरी को सार्वजनिक रिज़ॉल्वर तक लीक करके ऐसा सार्वजनिक उत्तर पाने के जिसका वे उपयोग नहीं कर सकते।

मान लेने के बजाय हर संदर्भ से नाम जाँचें, और curl के resolve विकल्प से DNS से स्वतंत्र रूप से मार्ग जाँचें, जो एक अनुरोध के लिए पता स्थिर करता है:

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 और एप्लिकेशन परत पर स्पष्ट अनुमति-सूची कॉन्फ़िगर करें, और अनुरोध के होस्टनाम को केवल स्वीकृत प्रविष्टियों में से चुनने दें। मनमाना इनपुट कभी भी निरपेक्ष लिंक का स्रोत या विश्वसनीय रीडायरेक्ट गंतव्य नहीं बनना चाहिए।

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