अफिस र 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 राख्छ र त्यसलाई पुनर्गणना गर्ने समर्थित तरिका दिन्छ: 'क्यास सफा गर्नुहोस् र मार्ग अद्यावधिक गर्नुहोस्' प्रशासनिक कार्य, जसको दस्तावेज यहाँ छ 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 र अनुप्रयोग तहमा स्पष्ट अनुमति सूची कन्फिगर गर्नुहोस्, र अनुरोधको होस्टनामले स्वीकृत प्रविष्टिहरूबीच मात्र छनोट गर्न दिनुहोस्। स्वेच्छाचारी इनपुट कहिल्यै निरपेक्ष लिङ्क वा विश्वसनीय रिडाइरेक्ट गन्तव्यको स्रोत बन्नु हुँदैन।

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