Én CiviCRM-adresse til kontor- og VPN-brugere: opsætningstrin

En kontorbærbar computer bør åbne det samme CiviCRM-bogmærke ved skrivebordet og igen hjemmefra over VPN. Det design, der overlever mødet med brugerne, er én kanonisk adresse, for eksempel https://crm.example.org/, med en godkendt netværksvej fra hver placering og et certifikat, der er gyldigt for det navn. VPN ændrer, hvordan en fjernklient når serveren. Det bør aldrig ændre applikationens identitet, for i det øjeblik det gør det, bliver hvert genereret link, omdirigering og integrationscallback et nyt problem at løse.

Vælg URL'en, før du vælger ruten

Skriv den tilsigtede adresse ned først, inklusive enhver stikomponent, som CMS'et har brug for, og behandl den som det faste punkt. Alt andet i denne kørebog er en implementeringsdetalje, der kan ændres uden at røre den: hvilket DNS-svar hver gruppe får, hvilken firewallregel der tillader lytteren, og om trafikken ankommer via en tunnel eller en lokal switchport.

Notér fire værdier sammen i adgangsplanen, fordi de kun virker som et sæt. Den kanoniske URL. Det svar, hver klientgruppe skal modtage for det navn. Ruten og adgangsreglen for det svar. Det værtsnavn, som webserveren og certifikatet er konfigureret til at betjene. Når noget går i stykker senere, er det ødelagte element et af disse fire, og du ved, hvilket du ændrede.

Trin 1: sørg for, at navnet opløses korrekt for begge grupper

Begge grupper bør få et privat svar, som de faktisk kan nå, og det er legitimt, at svarene er forskellige, så længe navnet ikke er. LAN-klienter opløser via den interne resolver; VPN-klienter har brug for en resolverpolitik, der giver dem samme zone i stedet for at lække forespørgslen til en offentlig resolver og få et offentligt svar, de ikke kan bruge.

Test navnet fra hver kontekst i stedet for at antage, og test ruten uafhængigt af DNS med curls resolve-indstilling, som fastlåser adressen for én anmodning:

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 test returnerer en adresse, som klienten ikke kan nå, er problemet tunnelrouting eller split-tunnel-listen. Hvis den anden test returnerer en omdirigering til et værtsnavn, du ikke forventede, så stop og læs Location-headeren, for det er et applikationsproblem, og ingen ruteændring vil løse det.

Trin 2: afstem webserver, certifikat og CMS-basis-URL

Lytteren skal være konfigureret til at betjene det kanoniske navn, og certifikatet skal dække det. At browse efter den rå adresse er ikke en omvej: det giver navnemismatch, det kan ødelægge cookie-omfanget, og det lærer brugerne at klikke gennem advarsler, som du senere skal forklare for en revisor.

Bag en omvendt proxy skal du sikre, at applikationen ved, at anmodningen ankom over HTTPS. De fleste CMS-platforme genererer absolutte links ud fra det registrerede skema, og en proxy, der afslutter TLS uden at videresende det oprindelige skema, giver en side fuld af http://-ressourcer, som browseren kan blokere. Konfigurer den betroede proxy og de videresendte headere eksplicit i stedet for at lade applikationen gætte.

Afstem derefter CMS'ets og CiviCRM's basis-URL. CiviCRM beholder sin fastlagte basis-URL og tilbyder en understøttet måde at genberegne den: den administrative handling Cleanup Caches and Update Paths, dokumenteret i fejlfindingsvejledningen til CiviCRM-installation. Kør den, efter at det kanoniske navn og CMS-indstillingen stemmer overens, ikke før, ellers cacher du blot en værdi, du er ved at ændre.

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

Trin 3: kontroller de adresser, CiviCRM genererer

At nå forsiden beviser meget lidt. CiviCRM kører inde i et CMS, og de sider, der betyder noget, er dem, der selv bygger deres URL'er: loginomdirigeringen, administrationsmenuen, udvidelsesressourcer, links til uploadede filer og enhver ekstern callback, som en integration registrerer.

Indlæs dashboardsiden, åbn en kontaktpost, og se sidens kilde efter absolutte links. Hvis de peger på et værtsnavn, som kun én klientgruppe kan nå, er basis-URL'en stadig forkert, selv om siden blev vist. Hvis de peger på det rigtige navn men det forkerte skema, er det proxykonfigurationen, der skal rettes.

Hvor adressen virkelig skal ændres, skal du behandle det som en applikationsmigrering i stedet for en DNS-redigering. Gennemgå ressource-URL'er, caches, publicerede links og enhver ekstern integration, der gemmer den gamle adresse, og opdater dem derefter i ét vindue, så ingen sidder med et halvt migreret bogmærke.

Et anmodnings-værtsnavn er ikke en tillidsbeslutning

Vælg ikke en privilegeret basis-URL, fordi en anmodningsheader indeholder en bestemt streng. PHP dokumenterer Apache-konfigurationer, hvor værdien for servernavn kan afspejle en værtsangivelse fra klienten, og variablen for serveradresse beskriver serveren, ikke gæstens placering. Ingen af dem er en adgangskontrolmekanisme, og at bygge en ud af dem er måden, hvorpå en privat tjeneste ender med at betjene det forkerte indhold til den forkerte vært.

Hvis flere værtsnavne virkelig er påkrævet, skal du konfigurere en eksplicit tilladelsesliste på webserveren, i CMS'et og i applikationslaget og lade anmodningens værtsnavn vælge blandt kun godkendte poster. Vilkårligt input bør aldrig blive kilden til absolutte links eller en betroet omdirigeringsdestination.

Slut af med det samme bogmærke i hver godkendt kontekst: et login, en almindelig intern navigation og én ressourceanmodning. Sammenlign værtsnavnene i svarene, ikke bare om siden blev indlæst. Den kontrol med tre anmodninger adskiller et ruteproblem fra en applikation, der stadig genererer den forkerte adresse, og den tager cirka et minut per klientgruppe.