Vienas CiviCRM URL biuro ir VPN naudotojams: sąrankos žingsniai

Biuro nešiojamasis kompiuteris turėtų atidaryti tą pačią CiviCRM žymą prie savo stalo ir vėl namuose per VPN. Sprendimas, kuris atlaiko susidūrimą su naudotojais, yra vienas kanoninis adresas, tarkime https://crm.example.org/, su patvirtintu tinklo maršrutu iš kiekvienos vietos ir sertifikatu, galiojančiu tam vardui. VPN keičia tai, kaip nuotolinis klientas pasiekia serverį. Jis niekada neturėtų keisti programos tapatybės, nes tą akimirką, kai ją pakeičia, kiekviena sugeneruota nuoroda, peradresavimas ir integracijos atgalinis iškvietimas tampa antrąja problema, kurią reikia išspręsti.

Pasirinkite URL prieš pasirinkdami maršrutą

Pirmiausia užrašykite numatytą adresą, įskaitant bet kurį kelio komponentą, kurio reikia CMS, ir laikykite jį fiksuotu tašku. Visa kita šiame vadove yra įgyvendinimo detalė, kurią galima pakeisti jo neliečiant: kokį DNS atsakymą gauna kiekviena grupė, kuri užkardos taisyklė leidžia klausiklį ir ar srautas atvyksta per tunelį, ar per vietinį komutatoriaus prievadą.

Užrašykite keturias reikšmes kartu prieigos plane, nes jos veikia tik kaip rinkinys. Kanoninis URL. Atsakymas, kurį turėtų gauti kiekviena klientų grupė tam vardui. Maršrutas ir prieigos taisyklė tam atsakymui. Vardas, kurį turi aptarnauti žiniatinklio serveris ir sertifikatas. Kai vėliau kažkas sugenda, sugedęs elementas yra vienas iš tų keturių, ir žinosite, kurį pakeitėte.

1 žingsnis: užtikrinkite, kad vardas būtų teisingai išsprendžiamas abiem grupėms

Abi grupės turėtų gauti privatų atsakymą, kurį iš tikrųjų gali pasiekti, ir visiškai priimtina, kad atsakymai skiriasi, jei tik vardas nesikeičia. LAN klientai sprendžia per vidinį resolverį; VPN klientams reikia resolverio politikos, kuri jiems duoda tą pačią zoną, o ne nutekina užklausą į viešą resolverį ir grąžina viešą atsakymą, kurio jie negali naudoti.

Išbandykite vardą kiekviename kontekste, o ne darykite prielaidų, ir išbandykite kelią nepriklausomai nuo DNS naudodami curl resolve parinktį, kuri prisega adresą vienai užklausai:

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

Jei pirmasis bandymas grąžina adresą, kurio klientas negali pasiekti, problema yra tunelio maršrutizavimas arba skaidyto tunelio sąrašas. Jei antrasis bandymas grąžina peradresavimą į vardą, kurio nesitikėjote, sustokite ir perskaitykite Location antraštę, nes tai yra programos problema ir joks maršruto pakeitimas jos neišspręs.

2 žingsnis: sulyginkite žiniatinklio serverį, sertifikatą ir CMS bazinį URL

Klausiklis turi būti sukonfigūruotas aptarnauti kanoninį vardą, o sertifikatas turi jį apimti. Naršymas pagal neapdorotą adresą nėra apėjimo būdas: jis sukelia vardo nesutapimą, gali sugadinti slapukų taikymo sritį ir moko naudotojus spustelėti įspėjimus, kuriuos vėliau turėsite paaiškinti auditoriui.

Už atvirkštinio proxy įsitikinkite, kad programa žino, jog užklausa atėjo per HTTPS. Dauguma CMS platformų generuoja absoliučias nuorodas pagal aptiktą schemą, o proxy, kuris užbaigia TLS neperduodamas pradinės schemos, sukuria puslapį su daugybe http:// išteklių, kuriuos naršyklė gali blokuoti. Aiškiai sukonfigūruokite patikimą proxy ir persiunčiamas antraštes, užuot leidę programai spėlioti.

Tada sulyginkite CMS ir CiviCRM bazinį URL. CiviCRM išlaiko nustatytą bazinį URL ir siūlo palaikomą būdą jam perskaičiuoti: administracinį veiksmą „Išvalyti podėlius ir atnaujinti kelius“, aprašytą CiviCRM diegimo trikčių šalinimo vadove. Paleiskite jį po to, kai kanoninis vardas ir CMS nustatymas sutampa, o ne prieš tai, kitaip tiesiog įdėsite į podėlį reikšmę, kurią tuoj pat keisite.

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

3 žingsnis: patikrinkite adresus, kuriuos generuoja CiviCRM

Pasiekti pagrindinį puslapį įrodo labai mažai. CiviCRM veikia CMS viduje, o svarbiausi puslapiai yra tie, kurie susikuria savo URL: prisijungimo peradresavimas, administravimo meniu, plėtinių ištekliai, įkeltų failų nuorodos ir bet koks išorinis atgalinis iškvietimas, užregistruotas integracijos.

Įkelkite valdymo skydą, atidarykite kontakto įrašą ir peržiūrėkite puslapio šaltinį, ieškodami absoliučių nuorodų. Jei jos nurodo į vardą, kurį gali pasiekti tik viena klientų grupė, bazinis URL vis dar neteisingas, nors puslapis ir atsisiuntė. Jei jos nurodo teisingą vardą, bet neteisingą schemą, taisyti reikia proxy konfigūraciją.

Kai adresą tikrai reikia pakeisti, traktuokite tai kaip programos migraciją, o ne DNS pakeitimą. Peržiūrėkite išteklių URL, podėlius, paskelbtas nuorodas ir kiekvieną išorinę integraciją, kuri saugo seną adresą, tada atnaujinkite juos viename lange, kad niekas neliktų su pusiau perkelta žyma.

Užklausos vardas nėra pasitikėjimo sprendimas

Nepasirinkite privilegijuoto bazinio URL vien todėl, kad užklausos antraštėje yra tam tikra eilutė. PHP dokumentuoja Apache konfigūracijas, kuriose serverio vardo reikšmė gali atspindėti kliento pateiktą host'ą, o serverio adreso kintamasis apibūdina serverį, o ne lankytojo vietą. Nė vienas iš jų nėra prieigos kontrolės mechanizmas, o statant tokį mechanizmą iš jų privati paslauga ima rodyti netinkamą turinį netinkamam host'ui.

Jei kelių vardų tikrai reikia, sukonfigūruokite aiškų leidžiamų sąrašą žiniatinklio serveryje, CMS ir programos lygmenyje, ir leiskite užklausos vardui rinktis tik iš patvirtintų įrašų. Savavališka įvestis niekada neturėtų tapti absoliučių nuorodų ar patikimo peradresavimo tikslo šaltiniu.

Užbaikite su ta pačia žyma kiekviename patvirtintame kontekste: prisijungimas, įprasta vidinė navigacija ir viena ištekliaus užklausa. Palyginkite atsakymų vardus, o ne tik tai, ar puslapis įkeltas. Šis trijų užklausų patikrinimas atskiria kelio problemą nuo programos, kuri vis dar generuoja neteisingą adresą, ir užtrunka apie minutę vienai klientų grupei.