En CiviCRM-URL för kontors- och VPN-användare: installationssteg

En kontorslaptop ska öppna samma CiviCRM-bokmärke vid skrivbordet och igen hemifrån över VPN. Den design som klarar mötet med användarna är en kanonisk adress, säg https://crm.example.org/, med en godkänd nätverksväg från varje plats och ett certifikat som är giltigt för det namnet. VPN ändrar hur en fjärrklient når servern. Det ska aldrig ändra applikationens identitet, för i samma stund som det gör det blir varje genererad länk, omdirigering och integrationsåterkallelse ett andra problem att lösa.

Välj URL:en innan du väljer vägen

Skriv ner den avsedda adressen först, inklusive eventuell sökvägskomponent som CMS:et behöver, och behandla den som den fasta punkten. Allt annat i den här runbooken är en implementationsdetalj som kan ändras utan att röra den: vilket DNS-svar varje grupp får, vilken brandväggsregel som tillåter lyssnaren och om trafiken kommer via en tunnel eller via en lokal switchport.

Registrera fyra värden tillsammans i åtkomstplanen, eftersom de bara fungerar som en uppsättning. Den kanoniska URL:en. Svaret varje klientgrupp ska få för det namnet. Vägen och åtkomstregeln för det svaret. Värdnamnet som webbservern och certifikatet är konfigurerade att betjäna. När något går sönder senare är det trasiga elementet ett av de fyra, och du vet vilket du ändrade.

Steg 1: se till att namnet löses korrekt för båda grupperna

Båda grupperna bör få ett privat svar som de faktiskt kan nå, och det är legitimt att svaren skiljer sig så länge namnet inte gör det. LAN-klienter löser via den interna resolveraren; VPN-klienter behöver en resolverpolicy som ger dem samma zon i stället för att läcka frågan till en offentlig resolver och få ett offentligt svar som de inte kan använda.

Testa namnet från varje kontext i stället för att anta, och testa vägen oberoende av DNS med curls resolve-alternativ, som fäster adressen för en begäran:

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

Om det första testet returnerar en adress som klienten inte kan nå är tunneldirigeringen eller split-tunnel-listan problemet. Om det andra testet returnerar en omdirigering till ett värdnamn du inte förväntade dig, stanna och läs Location-huvudet, för det är ett applikationsproblem och ingen vägändring åtgärdar det.

Steg 2: samordna webbservern, certifikatet och CMS-bas-URL:en

Lyssnaren måste vara konfigurerad att betjäna det kanoniska namnet, och certifikatet måste täcka det. Att surfa på råadressen är ingen lösning: det ger namnmissmatchning, kan förstöra cookieomfånget och lär användarna att klicka sig igenom varningar som du senare måste förklara för en revisor.

Bakom en omvänd proxy, se till att applikationen vet att begäran kom via HTTPS. De flesta CMS-plattformar genererar absoluta länkar från det upptäckta schemat, och en proxy som avslutar TLS utan att vidarebefordra det ursprungliga schemat ger en sida full av http:// resurser som en webbläsare kan blockera. Konfigurera den betrodda proxyn och vidarebefordrade huvuden explicit i stället för att låta applikationen gissa.

Samordna sedan CMS- och CiviCRM-bas-URL:en. CiviCRM behåller sin bestämda bas-URL och erbjuder ett stött sätt att räkna om den: den administrativa åtgärden Rensa cachar och uppdatera sökvägar, dokumenterad i felsökningsguiden för CiviCRM-installation. Kör den efter att det kanoniska namnet och CMS-inställningen stämmer, inte före, annars cachar du bara ett värde du är på väg att ändra.

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

Steg 3: kontrollera adresserna som CiviCRM genererar

Att nå startsidan bevisar väldigt lite. CiviCRM körs inuti ett CMS, och sidorna som spelar roll är de som bygger sina egna URL:er: inloggningsomdirigeringen, administrationsmenyn, tilläggsresurser, länkar till uppladdade filer och varje extern återkallelse som registreras av en integration.

Ladda instrumentpanelen, öppna en kontaktpost och titta på sidkällan efter absoluta länkar. Om de pekar på ett värdnamn som bara en klientgrupp kan nå är bas-URL:en fortfarande fel även om sidan renderades. Om de pekar på rätt namn men fel schema är det proxykonfigurationen som ska fixas.

Där adressen verkligen måste ändras, behandla det som en applikationsmigrering och inte som en DNS-ändring. Gå igenom resurs-URL:er, cachar, publicerade länkar och varje extern integration som lagrar den gamla adressen, och uppdatera dem sedan i ett enda fönster så att ingen sitter med ett halvmigrerat bokmärke.

Ett begärans värdnamn är inte ett förtroendebeslut

Välj inte en privilegierad bas-URL bara för att ett begäranshuvud innehåller en viss sträng. PHP dokumenterar Apache-konfigurationer där servernamnsvärdet kan återspegla en klientlevererad värd, och serveradressvariabeln beskriver servern, inte besökarens plats. Ingen av dem är en åtkomstkontrollmekanism, och att bygga en av dem är hur en privat tjänst till slut betjänar fel innehåll till fel värd.

Om flera värdnamn verkligen behövs, konfigurera en explicit tillåtelselista på webbservern, i CMS:et och i applikationslagret, och låt begärans värdnamn välja endast bland godkända poster. Godtycklig indata bör aldrig bli källan till absoluta länkar eller ett betrott omdirigeringsmål.

Avsluta med samma bokmärke i varje godkänd kontext: en inloggning, en vanlig intern navigering och en resursbegäran. Jämför värdnamnen i svaren, inte bara om sidan laddades. Den kontrollen med tre begäranden skiljer ett vägproblem från en applikation som fortfarande genererar fel adress, och tar ungefär en minut per klientgrupp.