कार्यालय आणि 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 आणि अनुप्रयोग स्तरावर स्पष्ट अनुमत यादी संरचित करा आणि विनंतीच्या होस्टनावाला केवळ मंजूर नोंदींमधून निवडू द्या। अनियंत्रित इनपुटने कधीही निरपेक्ष लिंक्सचा किंवा विश्वासार्ह रीडायरेक्ट गंतव्याचा स्रोत बनू नये।

मंजूर प्रत्येक संदर्भात त्याच बुकमार्कने पूर्ण करा: लॉगिन, सामान्य अंतर्गत नेव्हिगेशन आणि एक संसाधन विनंती। पृष्ठ लोड झाले की नाही एवढेच नव्हे, तर प्रतिसादांतील होस्टनावे तुलना करा। ती तीन-विनंती तपासणी मार्गाची समस्या आणि अजूनही चुकीचा पत्ता तयार करणारा अनुप्रयोग यांना वेगळे करते आणि प्रत्येक क्लायंट गटासाठी सुमारे एक मिनिट घेते।