Една CiviCRM URL за канцелариски и VPN корисници: чекори за поставување

Канцелариски лаптоп треба да го отвори истиот CiviCRM обележувач на бирото и повторно од дома преку VPN. Решението што го преживува контактот со корисниците е една канонска адреса, да речеме https://crm.example.org/, со одобрена мрежна патека од секоја локација и сертификат што е валиден за тоа име. VPN го менува начинот на кој далечински клиент стигнува до серверот. Тоа никогаш не треба да го смени идентитетот на апликацијата, бидејќи во моментот кога ќе го смени, секоја генерирана врска, пренасочување и повик за интеграција стануваат втор проблем што треба да се реши.

Изберете ја URL пред да ја изберете рутата

Прво запишете ја предвидената адреса, вклучително секоја компонента на патеката што му е потребна на CMS, и третирајте ја како фиксна точка. Останатото во ова упатство е детаљ од имплементацијата што може да се смени без да се допре таа: кој DNS одговор го добива секоја група, кое правило на огнениот ѕид го дозволува слушачот и дали сообраќајот пристигнува преку тунел или преку локален порт на прекинувач.

Запишете четири вредности заедно во планот за пристап, бидејќи тие функционираат само како сет. Канонската URL. Одговорот што треба да го добие секоја клиентска група за тоа име. Рутата и правилото за пристап за тој одговор. Името на домаќинот што веб-серверот и сертификатот се конфигурирани да го служат. Кога нешто подоцна ќе се расипе, расипаниот елемент е еден од тие четири и ќе знаете кој сте го смениле.

Чекор 1: направете името да се резолвира правилно за двете групи

Двете групи треба да добијат приватен одговор што навистина можат да го достават, и сосема е легитимно одговорите да се разликуваат се додека името не се разликува. LAN клиентите резолвираат преку внатрешниот резолвер; VPN клиентите бараат политика на резолверот што им ја дава истата зона наместо да го изнесе барањето до јавен резолвер и да добијат јавен одговор што не можат да го користат.

Тестирајте го името од секој контекст наместо да претпоставувате, и тестирајте ја патеката независно од DNS со опцијата resolve на curl, која ја заклучува адресата за едно барање:

dig +short crm.example.org
curl -sSI --resolve crm.example.org:443:10.10.5.20 https://crm.example.org/ | head -5

Ако првиот тест врати адреса што клиентот не може да ја достигне, проблемот е рутирањето на тунелот или списокот за split-tunnel. Ако вториот тест врати пренасочување кон име на домаќин што не сте го очекувале, запрете и прочитајте го заглавјето Location, бидејќи тоа е проблем на апликацијата и никаква промена на рутата нема да го реши.

Чекор 2: усогласете ги веб-серверот, сертификатот и основната URL на CMS

Слушачот мора да биде конфигуриран да служи канонското име, а сертификатот мора да го покрива. Прелистувањето по сурова адреса не е заобиколување: тоа создава несовпаѓање на името, може да го наруши опсегот на колачиња и ги учи корисниците да кликнуваат низ предупредувања што подоцна ќе треба да му ги објасните на ревизорот.

Зад обратен прокси, проверете дали апликацијата знае дека барањето пристигнало преку HTTPS. Повеќето CMS платформи генерираат апсолутни врски од откриената шема, а прокси што го завршува TLS без да ја препрати оригиналната шема создава страница полна со http:// ресурси што прелистувачот може да ги блокира. Експлицитно конфигурирајте го доверениот прокси и препратените заглавја наместо да ја оставате апликацијата да претпоставува.

Потоа усогласете ја основата URL на CMS и CiviCRM. 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 и слојот на апликацијата, и дозволете името на домаќинот во барањето да избира само меѓу одобрените записи. Произволен внес никогаш не треба да стане извор на апсолутни врски или доверлива дестинација за пренасочување.

Завршете со истиот обележувач во секој одобрен контекст: најава, обична внатрешна навигација и едно барање за ресурс. Споредете ги имињата на домаќините во одговорите, не само дали страницата се вчитала. Таа проверка со три барања го одвојува проблемот со патеката од апликација што продолжува да ја генерира погрешната адреса, и трае околу една минута по клиентска група.