Jedna adresa CiviCRM pro kancelářské uživatele i uživatele VPN: kroky nastavení

Kancelářský notebook by měl otevřít stejnou záložku CiviCRM u stolu a znovu z domova přes VPN. Návrh, který přežije setkání s uživateli, je jedna kanonická adresa, řekněme https://crm.example.org/, se schválenou síťovou cestou z každého místa a certifikátem platným pro tento název. VPN mění to, jak se vzdálený klient dostane na server. Nikdy by neměla změnit identitu aplikace, protože ve chvíli, kdy to udělá, se každý generovaný odkaz, přesměrování a zpětné volání integrace stává druhým problémem k řešení.

Vyberte URL dřív, než vyberete trasu

Nejprve zapište zamýšlenou adresu, včetně případné části cesty, kterou CMS potřebuje, a berte ji jako pevný bod. Všechno ostatní v této příručce je implementační detail, který se může změnit, aniž by se jí dotkl: kterou odpověď DNS dostane každá skupina, které pravidlo firewallu povolí posluchač a zda provoz přichází tunelem, nebo přes místní port přepínače.

Zapište čtyři hodnoty společně do plánu přístupu, protože fungují jen jako sada. Kanonická URL. Odpověď, kterou má každá klientská skupina pro tento název dostat. Trasa a přístupové pravidlo pro tuto odpověď. Název hostitele, který jsou webový server a certifikát nakonfigurovány obsluhovat. Když se později něco rozbije, rozbitý prvek je jeden z těch čtyř a budete vědět, který jste změnili.

Krok 1: zajistěte, aby se název správně překládal pro obě skupiny

Obě skupiny by měly dostat privátní odpověď, na kterou skutečně dosáhnou, a je legitimní, aby se odpovědi lišily, pokud se neliší název. Klienti v LAN překládají přes interní resolver; klienti VPN potřebují politiku resolveru, která jim předá stejnou zónu, místo aby dotaz unikl k veřejnému resolveru a vrátila se veřejná odpověď, kterou nemohou použít.

Otestujte název z každého kontextu místo předpokládání a otestujte cestu nezávisle na DNS pomocí volby resolve u curl, která připne adresu pro jeden požadavek:

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

Pokud první test vrátí adresu, na kterou se klient nedostane, je problém ve směrování tunelu nebo v seznamu rozděleného tunelu. Pokud druhý test vrátí přesměrování na název hostitele, který jste nečekali, zastavte se a přečtěte hlavičku Location, protože to je problém aplikace a žádná změna trasy ho neopraví.

Krok 2: slaďte webový server, certifikát a základní URL CMS

Posluchač musí být nakonfigurován tak, aby obsluhoval kanonický název, a certifikát ho musí pokrývat. Prohlížení podle surové adresy není náhradní řešení: vytváří neshodu názvů, může rozbít rozsah cookies a učí uživatele proklikat varování, která pak budete muset vysvětlovat auditorovi.

Za reverzním proxy se ujistěte, že aplikace ví, že požadavek dorazil přes HTTPS. Většina platforem CMS generuje absolutní odkazy z rozpoznaného schématu a proxy, které ukončí TLS bez předání původního schématu, vytvoří stránku plnou prostředků http://, které prohlížeč může zablokovat. Nakonfigurujte důvěryhodné proxy a předávané hlavičky výslovně, místo abyste nechali aplikaci hádat.

Poté slaďte základní URL CMS a CiviCRM. CiviCRM si drží svou určenou základní URL a nabízí podporovaný způsob, jak ji přepočítat: administrativní akci Cleanup Caches and Update Paths, popsanou v průvodci řešením problémů s instalací CiviCRM. Spusťte ji poté, co se kanonický název a nastavení CMS shodují, ne dřív, jinak si jen uložíte do mezipaměti hodnotu, kterou se chystáte změnit.

cv flush
# then Administer > System Settings > Cleanup Caches and Update Paths

Krok 3: zkontrolujte adresy, které CiviCRM generuje

Dostat se na úvodní stránku dokazuje velmi málo. CiviCRM běží uvnitř CMS a důležité jsou stránky, které si samy staví URL: přesměrování při přihlášení, administrační menu, prostředky rozšíření, odkazy na nahrané soubory a každé externí zpětné volání registrované integrací.

Načtěte nástěnku, otevřete záznam kontaktu a prohlédněte zdrojový kód stránky kvůli absolutním odkazům. Pokud ukazují na název hostitele, na který se dostane jen jedna klientská skupina, základní URL je stále špatná, i když se stránka vykreslila. Pokud ukazují na správný název, ale špatné schéma, opravit je třeba konfiguraci proxy.

Tam, kde se adresa skutečně musí změnit, berte to jako migraci aplikace, ne jako úpravu DNS. Projděte URL prostředků, mezipaměti, publikované odkazy a každou externí integraci, která ukládá starou adresu, a pak je aktualizujte v jednom okně, aby nikdo nedržel napůl migrovanou záložku.

Název hostitele v požadavku není rozhodnutím o důvěře

Nevybírejte privilegovanou základní URL jen proto, že hlavička požadavku obsahuje určitý řetězec. PHP dokumentuje konfigurace Apache, v nichž hodnota názvu serveru může odrážet hostitele dodaného klientem, a proměnná adresy serveru popisuje server, ne polohu návštěvníka. Ani jedno z toho není mechanismus řízení přístupu a stavět jeden z nich je způsob, jakým privátní služba začne poskytovat špatný obsah špatnému hostiteli.

Pokud je skutečně potřeba více názvů hostitelů, nakonfigurujte výslovný seznam povolených na webovém serveru, v CMS a na vrstvě aplikace a nechte název hostitele z požadavku vybírat jen mezi schválenými položkami. Libovolný vstup by se nikdy neměl stát zdrojem absolutních odkazů ani důvěryhodným cílem přesměrování.

Skončete se stejnou záložkou v každém schváleném kontextu: přihlášení, běžná interní navigace a jeden požadavek na prostředek. Porovnejte názvy hostitelů v odpovědích, ne jen to, zda se stránka načetla. Tato kontrola se třemi požadavky odděluje problém cesty od aplikace, která stále generuje špatnou adresu, a trvá asi minutu na klientskou skupinu.