Кеңсе және VPN пайдаланушылары үшін бір CiviCRM мекенжайы: баптау қадамдары

Кеңсе ноутбугі өз үстелінде және үйден 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-ын үйлестіріңіз

Тыңдаушы канондық атауға қызмет көрсетуге бапталуы керек, ал сертификат оны қамтуы керек. Шикі мекенжаймен шолу шешім емес: ол атау сәйкессіздігін тудырады, cookie ауқымын бұзуы мүмкін және пайдаланушыларды кейін аудиторға түсіндіруге тура келетін ескертулерден өтуге үйретеді.

Кері проксидің артында қолданбаның сұраныс 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-те және қолданба деңгейінде айқын рұқсат етілген тізімді баптаңыз және сұраныс хост атауына тек бекітілген жазбалардың ішінен таңдауға мүмкіндік беріңіз. Ерікті енгізу ешқашан абсолютті сілтемелердің көзі немесе сенімді қайта бағыттау мақсаты болмауы керек.

Әр бекітілген контексте сол бетбелгімен аяқтаңыз: кіру, қарапайым ішкі навигация және бір ресурс сұранысы. Жауаптардағы хост атауларын салыстырыңыз, тек бет ашылды ма дегенді емес. Осы үш сұранысты тексеру жол мәселесін әлі де қате мекенжай жасап жатқан қолданбадан ажыратады және әр клиент тобына шамамен бір минут алады.