En URL CiviCRM za pisarniške in VPN uporabnike: koraki nastavitve

Pisarniški prenosnik mora odpreti isto zaznamek CiviCRM za mizo in znova od doma prek VPN. Zasnova, ki preživi stik z uporabniki, je en kanonični naslov, recimo https://crm.example.org/, z odobreno omrežno potjo iz vsake lokacije in potrdilom, ki velja za to ime. VPN spremeni, kako oddaljeni odjemalec doseže strežnik. Nikoli ne sme spremeniti identitete aplikacije, ker v trenutku, ko jo, vsaka ustvarjena povezava, preusmeritev in povratni klic integracije postanejo druga težava, ki jo je treba rešiti.

Izberite URL, preden izberete pot

Najprej zapišite predvideni naslov, vključno z vsako komponento poti, ki jo CMS potrebuje, in ga obravnavajte kot fiksno točko. Vse ostalo v tem priročniku je podrobnost izvedbe, ki jo je mogoče spremeniti, ne da bi se ga dotaknili: kateri odgovor DNS prejme vsaka skupina, katero pravilo požarnega zidu dovoli poslušalca in ali promet prispe skozi tunel ali skozi lokalna vrata stikala.

Štiri vrednosti zapišite skupaj v načrt dostopa, ker delujejo le kot nabor. Kanonični URL. Odgovor, ki naj bi ga vsaka skupina odjemalcev prejela za to ime. Pot in pravilo dostopa za ta odgovor. Ime gostitelja, ki sta ga spletni strežnik in potrdilo nastavljena za streženje. Ko se pozneje nekaj pokvari, je pokvarjeni element eden od tistih štirih in vedeli boste, katerega ste spremenili.

Korak 1: poskrbite, da se ime pravilno razreši za obe skupini

Obe skupini bi morali prejeti zasebni odgovor, do katerega lahko resnično dostopata, in povsem legitimno je, da se odgovora razlikujeta, dokler se ime ne razlikuje. Odjemalci LAN razrešujejo prek notranjega razreševalnika; odjemalci VPN potrebujejo pravilnik razreševalnika, ki jim da isto območje, namesto da bi poizvedba uhajala v javni razreševalnik in prejeli javni odgovor, ki ga ne morejo uporabiti.

Ime preizkusite iz vsakega konteksta, namesto da bi predpostavljali, in pot preizkusite neodvisno od DNS z možnostjo resolve v curlu, ki naslov pripne na eno zahtevo:

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

Če prvi preizkus vrne naslov, do katerega odjemalec ne more dostopati, je težava usmerjanje tunela ali seznam split-tunnel. Če drugi preizkus vrne preusmeritev na ime gostitelja, ki ga niste pričakovali, se ustavite in preberite glavo Location, ker je to težava aplikacije in nobena sprememba poti je ne bo odpravila.

Korak 2: uskladite spletni strežnik, potrdilo in osnovni URL CMS

Poslušalec mora biti nastavljen za streženje kanoničnega imena, potrdilo pa ga mora pokrivati. Brskanje po surovem naslovu ni obhod: povzroči neujemanje imena, lahko pokvari obseg piškotkov in uporabnike uči, da klikajo skozi opozorila, ki jih boste pozneje morali razložiti revizorju.

Za obrnjenim posrednikom poskrbite, da aplikacija ve, da je zahteva prispela po HTTPS. Večina platform CMS ustvari absolutne povezave iz zaznane sheme, posrednik, ki zaključi TLS, ne da bi posredoval izvirno shemo, pa ustvari stran, polno http:// virov, ki jih brskalnik lahko blokira. Zaupanja vredni posrednik in posredovane glave nastavite izrecno, namesto da bi pustili aplikaciji ugibati.

Nato uskladite osnovni URL CMS in CiviCRM. CiviCRM ohrani določen osnovni URL in ponuja podprt način za njegov ponoven izračun: administrativno dejanje Počisti predpomnilnike in posodobi poti, dokumentirano v vodniku za odpravljanje težav z namestitvijo CiviCRM. Zaženite ga po tem, ko se kanonično ime in nastavitev CMS ujemata, ne prej, sicer boste samo v predpomnilnik shranili vrednost, ki jo boste pravkar spremenili.

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

Korak 3: preverite naslove, ki jih ustvarja CiviCRM

Doseganje domače strani dokaže zelo malo. CiviCRM teče znotraj CMS, pomembne pa so strani, ki same gradijo svoje URL-je: preusmeritev prijave, skrbniški meni, viri razširitev, povezave do naloženih datotek in vsak zunanji povratni klic, ki ga registrira integracija.

Naložite nadzorno ploščo, odprite zapis stika in si oglejte izvorno kodo strani zaradi absolutnih povezav. Če kažejo na ime gostitelja, do katerega lahko dostopa le ena skupina odjemalcev, je osnovni URL še vedno napačen, čeprav se je stran izrisala. Če kažejo na pravilno ime, a napačno shemo, je treba popraviti konfiguracijo posrednika.

Kjer je treba naslov resnično spremeniti, to obravnavajte kot selitev aplikacije in ne kot urejanje DNS. Preglejte URL-je virov, predpomnilnike, objavljene povezave in vsako zunanjo integracijo, ki hrani stari naslov, nato pa jih posodobite v enem oknu, da nikomur ne ostane na pol preseljen zaznamek.

Ime gostitelja v zahtevi ni odločitev o zaupanju

Ne izberite privilegiranega osnovnega URL samo zato, ker glava zahteve vsebuje določen niz. PHP dokumentira konfiguracije Apache, v katerih lahko vrednost imena strežnika odraža gostitelja, ki ga je priskrbel odjemalec, spremenljivka naslova strežnika pa opisuje strežnik, ne lokacije obiskovalca. Nobeno od tega ni mehanizem nadzora dostopa, in gradnja enega izmed njih je pot, po kateri zasebna storitev začne streči napačno vsebino napačnemu gostitelju.

Če je resnično potrebnih več imen gostiteljev, nastavite izrecen seznam dovoljenih na spletnem strežniku, v CMS in na ravni aplikacije ter dovolite, da ime gostitelja iz zahteve izbira le med odobrenimi vnosi. Samovoljni vnos nikoli ne sme postati vir absolutnih povezav ali zaupanja vredna cilj preusmeritve.

Končajte z istim zaznamkom v vsakem odobrenem kontekstu: prijava, običajna notranja navigacija in ena zahteva za virom. Primerjajte imena gostiteljev v odgovorih, ne le ali se je stran naložila. Ta preizkus treh zahtev loči težavo poti od aplikacije, ki še vedno ustvarja napačen naslov, in traja približno minuto na skupino odjemalcev.