Üks CiviCRM-i aadress kontori- ja VPN-kasutajatele: seadistamise sammud

Kontori sülearvuti peaks avama sama CiviCRM-i järjehoidja oma laua taga ja uuesti kodust VPN-i kaudu. Disain, mis peab vastu kasutajatega kokkupuutumisele, on üks kanooniline aadress, näiteks https://crm.example.org/, koos kinnitatud võrguteega igast asukohast ja selle nime jaoks kehtiva sertifikaadiga. VPN muudab seda, kuidas kaugklient serverini jõuab. See ei tohiks kunagi muuta rakenduse identiteeti, sest hetkel, mil see juhtub, muutub iga genereeritud link, ümbersuunamine ja integratsiooni tagasikutse teiseks lahendamist vajavaks probleemiks.

Valige URL enne, kui valite marsruudi

Kirjutage kavatsetud aadress kõigepealt üles, sealhulgas kõik teeosa, mida CMS vajab, ja käsitlege seda fikseeritud punktina. Kõik muu selles juhendis on rakendamise detail, mis võib muutuda ilma seda puutumata: millise DNS-vastuse saab iga grupp, milline tulemüürireegel lubab kuulajat ja kas liiklus saabub tunneli või kohaliku lülitipordi kaudu.

Kirjutage neli väärtust koos juurdepääsuplaani, sest need toimivad ainult komplektina. Kanooniline URL. Vastus, mille iga kliendigrupp selle nime jaoks saama peaks. Marsruut ja juurdepääsureegel selle vastuse jaoks. Hostinimi, mida veebiserver ja sertifikaat on seadistatud teenindama. Kui hiljem midagi katki läheb, on katkine element üks neist neljast, ja te teate, millist muutsite.

Samm 1: veenduge, et nimi laheneb mõlema grupi jaoks õigesti

Mõlemad grupid peaksid saama privaatse vastuse, milleni nad tegelikult jõuavad, ja on õiguspärane, et vastused erinevad, kui nimi ei erine. LAN-i kliendid lahendavad sisemise resolveri kaudu; VPN-i kliendid vajavad resolveri poliitikat, mis annab neile sama tsooni, selle asemel et päring avalikku resolverisse lekitada ja saada avalik vastus, mida nad kasutada ei saa.

Testige nime igast kontekstist, selle asemel et eeldada, ja testige teed DNS-ist sõltumatult curl-i resolve-valikuga, mis kinnitab aadressi ühe päringu jaoks:

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

Kui esimene test tagastab aadressi, kuhu klient ei jõua, on probleem tunneli marsruutimises või jagatud tunneli nimekirjas. Kui teine test tagastab ümbersuunamise hostinimele, mida te ei oodanud, peatuge ja lugege Location-päist, sest see on rakenduse probleem ja ükski marsruudimuudatus ei paranda seda.

Samm 2: viige veebiserver, sertifikaat ja CMS-i baas-URL kooskõlla

Kuulaja peab olema seadistatud teenindama kanoonilist nime ja sertifikaat peab selle katma. Tooraadressi järgi sirvimine ei ole lahendus: see tekitab nime mittevastavuse, võib rikkuda küpsiste ulatuse ja õpetab kasutajaid klõpsama hoiatustest läbi, mida peate hiljem auditile selgitama.

Pöördproksi taga veenduge, et rakendus teab, et päring saabus HTTPS-i kaudu. Enamik CMS-i platvorme genereerib absoluutsed lingid tuvastatud skeemist ning proksi, mis lõpetab TLS-i ilma algset skeemi edastamata, loob lehe, mis on täis http://-ressursse, mida brauser võib blokeerida. Seadistage usaldusväärne proksi ja edastatud päised selgesõnaliselt, selle asemel et lasta rakendusel oletada.

Seejärel viige CMS-i ja CiviCRM-i baas-URL kooskõlla. CiviCRM hoiab oma määratud baas-URL-i ja pakub toetatud viisi selle ümberarvutamiseks: haldustoiming Cleanup Caches and Update Paths, mis on dokumenteeritud CiviCRM-i paigalduse tõrkeotsingu juhendis. Käivitage see pärast seda, kui kanooniline nimi ja CMS-i säte ühtivad, mitte enne, muidu puhverdate lihtsalt väärtuse, mida kavatsete muuta.

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

Samm 3: kontrollige aadresse, mille CiviCRM genereerib

Avalehele jõudmine tõestab väga vähe. CiviCRM töötab CMS-i sees ja olulised on need lehed, mis ehitavad oma URL-id: sisselogimise ümbersuunamine, haldusmenüü, laienduste ressursid, üleslaaditud failide lingid ja iga integreerimise registreeritud väline tagasikutse.

Laadige juhtpaneel, avage kontaktikirje ja vaadake lehe allikat absoluutsete linkide jaoks. Kui need osutavad hostinimele, kuhu pääseb ainult üks kliendigrupp, on baas-URL endiselt vale, kuigi leht kuvati. Kui need osutavad õigele nimele, kuid vale skeemiga, tuleb parandada proksi seadistust.

Kus aadress peab tõesti muutuma, käsitlege seda rakenduse migreerimisena, mitte DNS-i muutmisena. Vaadake üle ressursi-URL-id, vahemälud, avaldatud lingid ja iga väline integratsioon, mis salvestab vana aadressi, seejärel värskendage neid ühes aknas, et kellelgi ei jääks pooleldi migreeritud järjehoidjat.

Päringu hostinimi ei ole usaldusotsus

Ärge valige privileegseks baas-URL-i ainult seetõttu, et päringu päis sisaldab kindlat stringi. PHP dokumenteerib Apache'i seadistusi, kus serverinime väärtus võib peegeldada kliendi esitatud hosti, ja serveriaadressi muutuja kirjeldab serverit, mitte külastaja asukohta. Kumbki neist ei ole juurdepääsukontrolli mehhanism ja ühe nende põhjal ehitamine on viis, kuidas privaatne teenus hakkab valale hostile valet sisu serveerima.

Kui mitut hostinime on tõesti vaja, seadistage selgesõnaline lubatud loend veebiserveris, CMS-is ja rakenduskihis ning laske päringu hostinimel valida ainult heakskiidetud kirjete hulgast. Suvaline sisend ei tohiks kunagi saada absoluutsete linkide allikaks ega usaldusväärseks ümbersuunamise sihtkohaks.

Lõpetage sama järjehoidjaga igas heakskiidetud kontekstis: sisselogimine, tavaline sisemine navigeerimine ja üks ressursipäring. Võrrelge vastustes olevaid hostinimesid, mitte ainult seda, kas leht laaditi. See kolme päringu kontroll eristab tee probleemi rakendusest, mis genereerib endiselt vale aadressi, ja see võtab kliendigrupi kohta umbes minuti.