அலுவலகம் மற்றும் VPN பயனர்களுக்கான ஒரு CiviCRM URL: அமைப்பு படிகள்

ஒரு அலுவலக மடிக்கணினி தனது மேசையில் அதே CiviCRM புக்மார்க்கைத் திறக்க வேண்டும், மீண்டும் வீட்டிலிருந்து VPN வழியாக. பயனர்களுடனான தொடர்பைத் தாங்கும் வடிவமைப்பு ஒரு நியதி முகவரி, சொல்லப்போனால் 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-ஐத் தேர்ந்தெடுக்காதீர்கள். சேவையகப் பெயர் மதிப்பு வாடிக்கையாளர் வழங்கிய புரவலனைப் பிரதிபலிக்கக்கூடிய Apache கட்டமைப்புகளை PHP ஆவணப்படுத்துகிறது, சேவையக முகவரி மாறி சேவையகத்தை விவரிக்கிறது, பார்வையாளரின் இருப்பிடத்தை அல்ல. அவற்றில் எதுவும் அணுகல் கட்டுப்பாட்டு பொறிமுறை அல்ல, அவற்றில் ஒன்றைக் கட்டுவதே தனியார் சேவை தவறான புரவலனுக்குத் தவறான உள்ளடக்கத்தை வழங்கும் வழி.

பல புரவலன் பெயர்கள் உண்மையில் தேவைப்பட்டால், வலைச் சேவையகம், CMS மற்றும் பயன்பாட்டு அடுக்கில் வெளிப்படையான அனுமதிப் பட்டியலை அமைத்து, கோரிக்கையின் புரவலன் பெயர் அங்கீகரிக்கப்பட்ட உள்ளீடுகளுக்கு இடையே மட்டும் தேர்ந்தெடுக்கட்டும். தன்னிச்சையான உள்ளீடு ஒருபோதும் முழுமையான இணைப்புகளின் அல்லது நம்பகமான திசைமாற்ற இலக்கின் மூலமாக இருக்கக் கூடாது.

அங்கீகரிக்கப்பட்ட ஒவ்வொரு சூழலிலும் அதே புக்மார்க்குடன் முடிக்கவும்: ஒரு உள்நுழைவு, ஒரு சாதாரண உள் வழிசெலுத்தல் மற்றும் ஒரு வளக் கோரிக்கை. பக்கம் ஏற்றப்பட்டதா என்பது மட்டுமல்ல, பதில்களில் உள்ள புரவலன் பெயர்களை ஒப்பிடுங்கள். அந்த மூன்று கோரிக்கைச் சோதனை பாதைப் பிரச்சினையை இன்னும் தவறான முகவரியை உருவாக்கும் பயன்பாட்டிலிருந்து பிரிக்கிறது, ஒரு வாடிக்கையாளர் குழுவுக்கு சுமார் ஒரு நிமிடம் எடுக்கும்.