Един CiviCRM адрес за офис и 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

Ако първият тест върне адрес, до който клиентът не може да достигне, проблемът е в маршрутизацията на тунела или в списъка за разделен тунел. Ако вторият тест върне пренасочване към име на хост, което не сте очаквали, спрете и прочетете заглавката Location, защото това е проблем на приложението и никаква промяна на маршрута няма да го поправи.

Стъпка 2: подравнете уеб сървъра, сертификата и базовия URL на CMS

Слушателят трябва да е конфигуриран да обслужва каноничното име, а сертификатът трябва да го покрива. Сърфирането по суров адрес не е заобиколен път: то създава несъответствие на името, може да счупи обхвата на бисквитките и учи потребителите да кликват през предупреждения, които по-късно ще трябва да обяснявате на одитор.

Зад обратен прокси се уверете, че приложението знае, че заявката е пристигнала по HTTPS. Повечето CMS платформи генерират абсолютни връзки от откритата схема, а прокси, което прекратява TLS без да препраща оригиналната схема, произвежда страница, пълна с ресурси http://, които браузърът може да блокира. Конфигурирайте довереното прокси и препращаните заглавки изрично, вместо да оставяте приложението да гадае.

След това подравнете базовия URL на CMS и CiviCRM. 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 и на слоя на приложението и оставете името на хоста от заявката да избира само сред одобрени записи. Произволният вход никога не трябва да става източник на абсолютни връзки или доверена дестинация за пренасочване.

Завършете със същата отметка във всеки одобрен контекст: вход, обикновена вътрешна навигация и една заявка за ресурс. Сравнете имената на хостовете в отговорите, а не само дали страницата се е заредила. Тази проверка с три заявки отделя проблем с пътя от приложение, което все още генерира грешния адрес, и отнема около минута на клиентска група.