Ien CiviCRM-adres foar kantoar- en VPN-brûkers: ynstellingsstappen

In kantoarlaptop moat deselde CiviCRM-blêdwizer by syn buro en wer fan hûs ôf fia de VPN iepenje. It ûntwerp dat kontakt mei brûkers oerlibbet, is ien kanonyk adres, sis https://crm.example.org/, mei in goedkarde netwurkpaad fan elke lokaasje en in sertifikaat dat jildich is foar dy namme. De VPN feroaret hoe't in klant op ôfstân de server berikt. It moat nea de identiteit fan 'e applikaasje feroarje, want op it momint dat it dat docht, wurdt elke generearre keppeling, trochferwizing en yntegraasje-callback in twadde probleem om op te lossen.

Kies de URL foardat jo de rûte kieze

Skriuw earst it bedoelde adres op, ynklusyf elk paadkomponint dat it CMS nedich hat, en behannelje it as it fêste punt. Al it oare yn dizze hânlieding is in ymplemintaasjedetail dat feroarje kin sûnder it oan te reitsjen: hokker DNS-antwurd elke groep krijt, hokker firewallregel de listener tastiet, en oft it ferkear oer in tunnel of oer in lokale switchpoarte komt.

Skriuw fjouwer wearden byinoar op yn it tagongsplan, want se wurkje allinnich as in set. De kanonike URL. It antwurd dat elke klantgroep foar dy namme krije moat. De rûte en tagongsregel foar dat antwurd. De hostnamme dy't de webserver en it sertifikaat ynsteld binne om te tsjinjen. As letter eat brekt, is it brutsen elemint ien fan dy fjouwer, en jo witte hokker jo feroare hawwe.

Stap 1: soargje dat de namme foar beide groepen goed oplost

Beide groepen moatte in privee-antwurd krije dat se echt berikke kinne, en it is legitiem dat de antwurden ferskille salang't de namme dat net docht. LAN-klanten losse op fia de ynterne resolver; VPN-klanten hawwe in resolverbelied nedich dat har deselde sône jout ynstee fan de fraach nei in iepenbiere resolver te lekken en in iepenbier antwurd te krijen dat se net brûke kinne.

Test de namme fanút elke kontekst ynstee fan oan te nimmen, en test it paad ûnôfhinklik fan DNS mei curl syn resolve-opsje, dy't it adres foar ien oanfraach fêstset:

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

As de earste test in adres werombringt dat de klant net berikke kin, is it probleem de tunnelrouting of de list fan split-tunnel. As de twadde test in trochferwizing nei in hostnamme werombringt dy't jo net ferwachten, stop dan en lês de Location-header, want dat is in applikaasjeprobleem en gjin rûtewiziging sil it oplosse.

Stap 2: lijn de webserver, it sertifikaat en de CMS-basis-URL út

De listener moat ynsteld wêze om de kanonike namme te tsjinjen, en it sertifikaat moat dy dekke. Browske troch it rauwe adres is gjin omwei: it produsearret in namme-mismatch, it kin it cookie-berik brekke, en it leart brûkers om troch warskôgings te klikken dy't jo letter oan in auditor útlisje moatte.

Efter in omkearde proxy, soargje dat de applikaasje wit dat de oanfraach fia HTTPS oankaam. De measte CMS-platfoarmen generearje absolute keppelings út it detektearre skema, en in proxy dy't TLS einiget sûnder it oarspronklike skema troch te stjoeren, produsearret in side fol http://-boarnen dy't de browser blokkearje kin. Konfigurearje de fertroude proxy en trochstjoerde headers eksplisyt, ynstee fan de applikaasje te litten rieden.

Lijn dan de basis-URL fan CMS en CiviCRM út. CiviCRM hâldt syn bepaalde basis-URL en biedt in stipe manier om dy opnij te berekkenjen: de administratyf aksje Cleanup Caches and Update Paths, dokumintearre yn 'e gids foar probleemoplossing by CiviCRM-ynstallaasje. Fier it út neidat de kanonike namme en de CMS-ynstelling oerienkomme, net earder, oars cache jo gewoan in wearde dy't jo op it punt steane te feroarjen.

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

Stap 3: kontrolearje de adressen dy't CiviCRM generearret

De foarside berikke bewiist heul lyts. CiviCRM draait binnen in CMS, en de siden dy't der ta dogge binne dyjingen dy't har eigen URL's bouwe: de oanmeldtrochferwizing, it administraasjemenu, útwreidingsboarnen, keppelings nei uploade bestannen en elke eksterne callback dy't in yntegraasje registrearret.

Laad it dashboard, iepenje in kontaktrecord en besjoch de boarne fan 'e side foar absolute keppelings. As se nei in hostnamme wize dy't mar ien klantgroep berikke kin, is de basis-URL noch altyd ferkeard ek al waard de side werjûn. As se nei de goede namme mar it ferkearde skema wize, is de proxykonfiguraasje it ding om te reparearjen.

Dêr't it adres echt feroarje moat, behannelje it as in applikaasjemigraasje ynstee fan in DNS-bewurking. Besjoch boarne-URL's, caches, publisearre keppelings en elke eksterne yntegraasje dy't it âlde adres bewarret, en wurkje se dan by yn ien finster sadat nimmen in heal migrearre blêdwizer hâldt.

In oanfraach-hostnamme is gjin fertrouwensbeslút

Kies gjin befoarrjochte basis-URL om't in oanfrachtheader in bepaalde tekenrige befettet. PHP dokumintearret Apache-konfiguraasjes wêryn't de wearde fan 'e servernamme in host wjerspegelje kin dy't de klant oanlevere hat, en de fariabele foar serveradres beskriuwt de server, net de lokaasje fan 'e besiker. Net ien fan beide is in tagongskontrôlemechanisme, en ien dêrfan bouwe is hoe't in privee tsjinst úteinlik de ferkearde ynhâld oan 'e ferkearde host tsjinnet.

As der echt meardere hostnammen nedich binne, konfigurearje dan in eksplisite tastiene list op 'e webserver, yn it CMS en op 'e applikaasjelaach, en lit de oanfraach-hostnamme allinnich út goedkarde yngongen kieze. Willekeurige ynfier moat nea de boarne wurde fan absolute keppelings of in fertroud trochferwizingsdoel.

Einigje mei deselde blêdwizer yn elke goedkarde kontekst: in oanmelding, in gewoane ynterne navigaasje en ien boarne-oanfraach. Fergelykje de hostnammen yn 'e antwurden, net allinnich oft de side laden is. Dy kontrôle mei trije oanfragen skiedt in paadprobleem fan in applikaasje dy't noch altyd it ferkearde adres generearret, en it duorret sawat in minút per klantgroep.