Jedna adresa URL CiviCRM pre používateľov kancelárie a VPN: kroky nastavenia

Kancelársky notebook by mal otvoriť rovnakú záložku CiviCRM pri stole a znova z domu cez VPN. Riešenie, ktoré prežije kontakt s používateľmi, je jedna kanonická adresa, povedzme https://crm.example.org/, so schválenou sieťovou cestou z každého miesta a certifikátom platným pre to meno. VPN mení spôsob, akým sa vzdialený klient dostane na server. Nikdy by nemala meniť identitu aplikácie, pretože v okamihu, keď to urobí, každý vygenerovaný odkaz, presmerovanie a spätné volanie integrácie sa stane druhým problémom na riešenie.

Vyberte adresu URL skôr, než vyberiete trasu

Najprv zapíšte zamýšľanú adresu vrátane ktorejkoľvek zložky cesty, ktorú CMS potrebuje, a berte ju ako pevný bod. Všetko ostatné v tomto postupe je implementačný detail, ktorý sa dá zmeniť bez toho, aby ste sa jej dotkli: akú odpoveď DNS dostane každá skupina, ktoré pravidlo brány firewall povoľuje listener a či prevádzka prichádza cez tunel alebo cez lokálny port prepínača.

Zapíšte štyri hodnoty spolu do plánu prístupu, pretože fungujú len ako sada. Kanonická adresa URL. Odpoveď, ktorú má každá skupina klientov dostať pre to meno. Trasa a pravidlo prístupu pre tú odpoveď. Názov hostiteľa, ktorý majú obsluhovať webový server a certifikát. Keď sa neskôr niečo pokazí, pokazený prvok je jeden z tých štyroch a budete vedieť, ktorý ste zmenili.

Krok 1: dosiahnite, aby sa meno správne prekladalo pre obe skupiny

Obe skupiny by mali dostať súkromnú odpoveď, ku ktorej sa naozaj dostanú, a je legitímne, aby sa odpovede líšili, pokiaľ sa nelíši meno. Klienti LAN prekladajú cez interný resolver; klienti VPN potrebujú politiku resolvera, ktorá im dá tú istú zónu, namiesto toho, aby unikla dopyt do verejného resolvera a dostali verejnú odpoveď, ktorú nemôžu použiť.

Testujte meno z každého kontextu namiesto predpokladania a testujte cestu nezávisle od DNS pomocou možnosti resolve v curl, ktorá pripne adresu na jednu požiadavku:

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

Ak prvý test vráti adresu, ku ktorej sa klient nedostane, problémom je smerovanie tunela alebo zoznam split-tunnel. Ak druhý test vráti presmerovanie na názov hostiteľa, ktorý ste nečakali, zastavte sa a prečítajte hlavičku Location, pretože to je problém aplikácie a žiadna zmena trasy ho neopraví.

Krok 2: zosúlaďte webový server, certifikát a základnú adresu URL CMS

Listener musí byť nakonfigurovaný tak, aby obsluhoval kanonické meno, a certifikát ho musí pokrývať. Prehliadanie po surovej adrese nie je obchádzka: spôsobuje nezhodu mien, môže pokaziť rozsah cookies a učí používateľov preklikávať sa cez upozornenia, ktoré budete musieť neskôr vysvetliť audítorovi.

Za reverzným proxy sa uistite, že aplikácia vie, že požiadavka prišla cez HTTPS. Väčšina platforiem CMS generuje absolútne odkazy z rozpoznanej schémy a proxy, ktoré ukončí TLS bez odovzdania pôvodnej schémy, vytvorí stránku plnú http:// zdrojov, ktoré prehliadač môže zablokovať. Nakonfigurujte dôveryhodné proxy a odovzdávané hlavičky explicitne namiesto toho, aby aplikácia hádala.

Potom zosúlaďte základnú adresu URL CMS a CiviCRM. CiviCRM si ponecháva určenú základnú adresu URL a ponúka podporovaný spôsob jej prepočítania: administratívnu akciu Vyčistiť vyrovnávacie pamäte a aktualizovať cesty, zdokumentovanú v príručke na riešenie problémov s inštaláciou CiviCRM. Spustite ju po tom, ako sa kanonické meno a nastavenie CMS zhodujú, nie predtým, inak len uložíte do vyrovnávacej pamäte hodnotu, ktorú sa chystáte zmeniť.

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

Krok 3: skontrolujte adresy, ktoré CiviCRM generuje

Dostať sa na úvodnú stránku dokazuje veľmi málo. CiviCRM beží vnútri CMS a dôležité sú stránky, ktoré si budujú vlastné adresy URL: presmerovanie prihlásenia, administratívne menu, zdroje rozšírení, odkazy na nahraté súbory a každé externé spätné volanie registrované integráciou.

Načítajte panel, otvorte záznam kontaktu a pozrite si zdrojový kód stránky kvôli absolútnym odkazom. Ak ukazujú na názov hostiteľa, ku ktorému sa dostane len jedna skupina klientov, základná adresa URL je stále nesprávna, aj keď sa stránka vykreslila. Ak ukazujú na správne meno, ale nesprávnu schému, opraviť treba konfiguráciu proxy.

Tam, kde sa adresa naozaj musí zmeniť, berte to ako migráciu aplikácie, nie ako úpravu DNS. Prejdite adresy URL zdrojov, vyrovnávacie pamäte, publikované odkazy a každú externú integráciu, ktorá ukladá starú adresu, a potom ich aktualizujte v jednom okne, aby nikomu nezostala polovica migrovanej záložky.

Názov hostiteľa v požiadavke nie je rozhodnutím o dôvere

Nevyberajte privilegovanú základnú adresu URL len preto, že hlavička požiadavky obsahuje určitý reťazec. PHP dokumentuje konfigurácie Apache, v ktorých hodnota názvu servera môže odrážať hostiteľa poskytnutého klientom, a premenná adresy servera opisuje server, nie polohu návštevníka. Ani jedno z toho nie je mechanizmus kontroly prístupu a budovanie jedného z nich je spôsob, akým súkromná služba začne obsluhovať nesprávny obsah nesprávnemu hostiteľovi.

Ak je skutočne potrebných viac názvov hostiteľov, nakonfigurujte explicitný zoznam povolených na webovom serveri, v CMS a vo vrstve aplikácie a nechajte názov hostiteľa z požiadavky vyberať len spomedzi schválených položiek. Ľubovoľný vstup by sa nikdy nemal stať zdrojom absolútnych odkazov ani dôveryhodným cieľom presmerovania.

Skončite tou istou záložkou v každom schválenom kontexte: prihlásenie, bežná interná navigácia a jedna požiadavka na zdroj. Porovnajte názvy hostiteľov v odpovediach, nielen to, či sa stránka načítala. Ten test troch požiadaviek oddeľuje problém trasy od aplikácie, ktorá stále generuje nesprávnu adresu, a trvá približne minútu na skupinu klientov.