Én CiviCRM-URL for kontor- og VPN-brukere: oppsettstrinn

En kontorbærbar PC skal åpne det samme CiviCRM-bokmerket ved pulten og igjen hjemmefra over VPN. Designet som tåler møtet med brukerne, er én kanonisk adresse, for eksempel https://crm.example.org/, med en godkjent nettverksvei fra hvert sted, og et sertifikat som er gyldig for det navnet. VPN endrer hvordan en fjernklient når serveren. Det skal aldri endre applikasjonens identitet, for i det øyeblikket det gjør det, blir hver genererte lenke, omdirigering og integrasjonstilbakekalling et nytt problem å løse.

Velg URL-en før du velger ruten

Skriv ned den tiltenkte adressen først, inkludert eventuell stikomponent CMS-et trenger, og behandle den som det faste punktet. Alt annet i denne kjøreboken er implementasjonsdetaljer som kan endres uten å røre den: hvilket DNS-svar hver gruppe får, hvilken brannmurregel som tillater lytteren, og om trafikken kommer over en tunnel eller en lokal svitsjport.

Registrer fire verdier sammen i tilgangsplanen, fordi de bare virker som et sett. Den kanoniske URL-en. Svaret hver klientgruppe skal få for det navnet. Ruten og tilgangsregelen for det svaret. Vertsnavnet webserveren og sertifikatet er konfigurert til å betjene. Når noe bryter sammen senere, er det ødelagte elementet ett av de fire, og du vet hvilket du endret.

Trinn 1: sørg for at navnet løses riktig for begge grupper

Begge grupper bør få et privat svar de faktisk kan nå, og det er legitimt at svarene er forskjellige så lenge navnet ikke er det. LAN-klienter løser gjennom den interne resolveren; VPN-klienter trenger en resolverpolicy som gir dem samme sone i stedet for å lekke spørringen til en offentlig resolver og få et offentlig svar de ikke kan bruke.

Test navnet fra hver kontekst i stedet for å anta, og test veien uavhengig av DNS med curls resolve-alternativ, som fester adressen for én forespørsel:

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

Hvis den første testen returnerer en adresse klienten ikke kan nå, er tunnelrutingen eller split-tunnel-listen problemet. Hvis den andre testen returnerer en omdirigering til et vertsnavn du ikke forventet, stopp og les Location-headeren, for det er et applikasjonsproblem og ingen ruteendring vil fikse det.

Trinn 2: juster webserveren, sertifikatet og CMS-basis-URL-en

Lytteren må være konfigurert til å betjene det kanoniske navnet, og sertifikatet må dekke det. Å surfe på råadressen er ingen løsning: det gir navnemismatch, kan ødelegge cookiedekningen, og lærer brukerne å klikke seg gjennom advarsler du senere må forklare for en revisor.

Bak en omvendt proxy, sørg for at applikasjonen vet at forespørselen kom over HTTPS. De fleste CMS-plattformer genererer absolutte lenker fra det oppdagede skjemaet, og en proxy som avslutter TLS uten å videresende originalskjemaet, gir en side full av http:// ressurser som en nettleser kan blokkere. Konfigurer den klarerte proxyen og videresendte headere eksplisitt i stedet for å la applikasjonen gjette.

Juster deretter CMS- og CiviCRM-basis-URL-en. CiviCRM beholder den bestemte basis-URL-en og tilbyr en støttet måte å beregne den på nytt: den administrative handlingen Rydd cacher og oppdater stier, dokumentert i feilsøkingsveiledningen for CiviCRM-installasjon. Kjør den etter at det kanoniske navnet og CMS-innstillingen stemmer, ikke før, ellers bufrer du bare en verdi du er i ferd med å endre.

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

Trinn 3: sjekk adressene CiviCRM genererer

Å nå forsiden beviser svært lite. CiviCRM kjører inne i et CMS, og sidene som betyr noe, er de som bygger sine egne URL-er: innloggingsomdirigeringen, administrasjonsmenyen, utvidelsesressurser, lenker til opplastede filer og enhver ekstern tilbakekalling registrert av en integrasjon.

Last dashbordet, åpne en kontaktpost og se på sidekilden etter absolutte lenker. Hvis de peker på et vertsnavn bare én klientgruppe kan nå, er basis-URL-en fortsatt feil selv om siden ble vist. Hvis de peker på riktig navn men feil skjema, er proxykonfigurasjonen det som må fikses.

Der adressen virkelig må endres, behandle det som en applikasjonsmigrering og ikke en DNS-endring. Gå gjennom ressurs-URL-er, cacher, publiserte lenker og hver ekstern integrasjon som lagrer den gamle adressen, og oppdater dem i ett vindu slik at ingen sitter med et halvmigrert bokmerke.

Et forespørselsvertsnavn er ikke en tillitsbeslutning

Ikke velg en privilegert basis-URL fordi en forespørselsheader inneholder en bestemt streng. PHP dokumenterer Apache-konfigurasjoner der server-navnverdien kan gjenspeile en klientlevert vert, og serveradressevariabelen beskriver serveren, ikke besøkendes plassering. Ingen av dem er en tilgangskontrollmekanisme, og å bygge en ut av dem er hvordan en privat tjeneste ender med å betjene feil innhold til feil vert.

Hvis flere vertsnavn virkelig er nødvendige, konfigurer en eksplisitt tillatelsesliste på webserveren, i CMS-et og i applikasjonslaget, og la forespørselsvertsnavnet velge bare blant godkjente oppføringer. Vilkårlig input bør aldri bli kilden til absolutte lenker eller et klarert omdirigeringsmål.

Avslutt med det samme bokmerket i hver godkjente kontekst: en innlogging, en vanlig intern navigasjon og én ressurssforespørsel. Sammenlign vertsnavnene i svarene, ikke bare om siden lastet. Den tretrinns forespørselssjekken skiller et veiproblem fra en applikasjon som fortsatt genererer feil adresse, og tar omtrent ett minutt per klientgruppe.