Éin CiviCRM-URL for kontor- og VPN-brukarar: oppsettsteg

Ein kontorbærbar PC skal opne den same CiviCRM-bokmerket ved pulten og igjen heimanfrå over VPN. Designet som toler møtet med brukarane, er éin kanonisk adresse, til dømes https://crm.example.org/, med ein godkjend nettverksveg frå kvar stad, og eit sertifikat som er gyldig for det namnet. VPN endrar korleis ein fjernklient når serveren. Det skal aldri endre identiteten til applikasjonen, for i det augneblinken det gjer det, blir kvar genererte lenkje, omdirigering og integrasjonstilbakekalling eit nytt problem å løyse.

Vel URL-en før du vel ruta

Skriv ned den tiltenkte adressa først, inkludert eventuell stikomponent CMS-et treng, og handsam henne som det faste punktet. Alt anna i denne køyreboka er implementasjonsdetaljar som kan endrast utan å røre henne: kva DNS-svar kvar gruppe får, kva brannmurregel som tillèt lyttaren, og om trafikken kjem over ein tunnel eller ein lokal svitsjport.

Registrer fire verdiar saman i tilgangsplanen, fordi dei berre verkar som eit sett. Den kanoniske URL-en. Svaret kvar klientgruppe skal få for det namnet. Ruta og tilgangsregelen for det svaret. Vertsmannnamnet nettserveren og sertifikatet er konfigurerte til å betene. Når noko bryt saman seinare, er det øydelagde elementet eitt av dei fire, og du veit kva du endra.

Steg 1: sørg for at namnet blir løyst riktig for begge grupper

Begge grupper bør få eit privat svar dei faktisk kan nå, og det er legitimt at svara er ulike så lenge namnet ikkje er det. LAN-klientar løyser gjennom den interne resolveren; VPN-klientar treng ein resolverpolicy som gir dei same sone i staden for å leke spørjinga til ein offentleg resolver og få eit offentleg svar dei ikkje kan bruke.

Test namnet frå kvar kontekst i staden for å anta, og test vegen uavhengig av DNS med resolve-alternativet til curl, som festar adressa for éin førespurnad:

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

Viss den første testen returnerer ei adresse klienten ikkje kan nå, er tunnelrutinga eller split-tunnel-lista problemet. Viss den andre testen returnerer ei omdirigering til eit vertsmannnamn du ikkje forventa, stopp og les Location-headeren, for det er eit applikasjonsproblem og inga ruteendring vil fikse det.

Steg 2: juster nettserveren, sertifikatet og CMS-basis-URL-en

Lyttaren må vere konfigurert til å betene det kanoniske namnet, og sertifikatet må dekkje det. Å surfe på råadressa er inga løysing: det gir namnemismatch, kan øydeleggje cookiedekninga, og lærer brukarane å klikke seg gjennom åtvaringar du seinare må forklare for ein revisor.

Bak ein omvend proxy, sørg for at applikasjonen veit at førespurnaden kom over HTTPS. Dei fleste CMS-plattformer genererer absolutte lenkjer frå det oppdaga skjemaet, og ein proxy som avsluttar TLS utan å videresende originalskjemaet, gir ei side full av http:// ressursar som ein nettlesar kan blokkere. Konfigurer den klarerte proxyen og videresende headere eksplisitt i staden for å la applikasjonen gjette.

Juster deretter CMS- og CiviCRM-basis-URL-en. CiviCRM held på den bestemte basis-URL-en og tilbyr ein støtta måte å rekne han ut på nytt: den administrative handlinga Rydd cachar og oppdater stiar, dokumentert i feilsøkingsrettleiinga for CiviCRM-installasjon. Køyr han etter at det kanoniske namnet og CMS-innstillinga stemmer, ikkje før, elles bufrer du berre ein verdi du er i ferd med å endre.

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

Steg 3: sjekk adressene CiviCRM genererer

Å nå framsida beviser svært lite. CiviCRM køyrer inne i eit CMS, og sidene som betyr noko, er dei som byggjer sine eigne URL-ar: innloggingsomdirigeringa, administrasjonsmenyen, utvidingsressursar, lenkjer til opplasta filer og kvar ekstern tilbakekalling som er registrert av ein integrasjon.

Last dashbordet, opne ein kontaktpost og sjå på sidekjelda etter absolutte lenkjer. Viss dei peikar på eit vertsmannnamn berre éi klientgruppe kan nå, er basis-URL-en framleis feil sjølv om sida vart vist. Viss dei peikar på riktig namn men feil skjema, er proxykonfigurasjonen det som må fiksast.

Der adressa verkeleg må endrast, handsam det som ein applikasjonsmigrasjon og ikkje ei DNS-endring. Gå gjennom ressurs-URL-ar, cachar, publiserte lenkjer og kvar ekstern integrasjon som lagrar den gamle adressa, og oppdater dei i eitt vindauge slik at ingen sit med ein halvmigrert bokmerke.

Eit førespurnadsvertsnamn er ikkje ei tillitsavgjerd

Ikkje vel ein privilegert basis-URL fordi ein førespurnadsheader inneheld ein bestemt streng. PHP dokumenterer Apache-konfigurasjonar der server-namnverdien kan spegle ein klientlevert vert, og serveradressevariabelen skildrar serveren, ikkje plasseringa til den besøkande. Ingen av dei er ein tilgangskontrollmekanisme, og å byggje ein ut av dei er korleis ein privat teneste endar med å betene feil innhald til feil vert.

Viss fleire vertsmannnamn verkeleg er nødvendige, konfigurer ei eksplisitt tillatingsliste på nettserveren, i CMS-et og i applikasjonslaget, og la førespurnadsvertsnamnet velje berre blant godkjende oppføringar. Vilkårleg input bør aldri bli kjelda til absolutte lenkjer eller eit klarert omdirigeringsmål.

Avslutt med den same bokmerket i kvar godkjend kontekst: ei innlogging, ein vanleg intern navigasjon og éin ressursførespurnad. Samanlikn vertsmannnamna i svara, ikkje berre om sida lasta. Den tretrinns førespurnadssjekken skil eit vegproblem frå ein applikasjon som framleis genererer feil adresse, og tar omtrent eitt minutt per klientgruppe.