Један CiviCRM URL за канцеларијске и VPN кориснике: кораци подешавања

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

Ако први тест врати адресу до које клијент не може да дође, проблем је рутирање тунела или листа 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-у и на слоју апликације, и дозволите да назив хоста из захтева бира само међу одобреним уносима. Произвољан унос никада не треба да постане извор апсолутних веза или поуздано одредиште преусмерења.

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