Een CiviCRM-adres vir kantoor- en VPN-gebruikers: opstellingsstappe

'n Kantoorrekenaar moet dieselfde CiviCRM-merker by sy lessenaar en weer van die huis af oor die VPN oopmaak. Die ontwerp wat kontak met gebruikers oorleef, is een kanonieke adres, sê https://crm.example.org/, met 'n goedgekeurde netwerkpad vanaf elke ligging en 'n sertifikaat wat vir daardie naam geldig is. Die VPN verander hoe 'n afgeleë kliënt die bediener bereik. Dit moet nooit die toepassing se identiteit verander nie, want sodra dit dit doen, word elke gegenereerde skakel, herleiding en integrasie-terugroeping 'n tweede probleem om op te los.

Kies die URL voordat jy die roete kies

Skryf die beoogde adres eerste neer, insluitend enige padkomponent wat die CMS nodig het, en behandel dit as die vaste punt. Alles anders in hierdie handleiding is 'n implementeringsbesonderheid wat kan verander sonder om dit te raak: watter DNS-antwoord elke groep ontvang, watter firewallreël die luisteraar toelaat, en of die verkeer oor 'n tonnel of 'n plaaslike skakelpoort aankom.

Teken vier waardes saam in die toegangsplan aan, want hulle werk net as 'n stel. Die kanonieke URL. Die antwoord wat elke kliëntegroep vir daardie naam moet ontvang. Die roete en toegangsreël vir daardie antwoord. Die gasheernaam wat die webbediener en sertifikaat opgestel is om te bedien. Wanneer iets later breek, is die gebreekte element een van daardie vier, en jy sal weet watter een jy verander het.

Stap 1: maak dat die naam vir albei groepe korrek oplos

Albei groepe moet 'n private antwoord kry wat hulle werklik kan bereik, en dit is regmatig dat die antwoorde verskil solank die naam nie verskil nie. LAN-kliënte los op deur die interne oplosser; VPN-kliënte het 'n oplosserbeleid nodig wat aan hulle dieselfde sone gee eerder as om die navraag na 'n openbare oplosser te lek en 'n openbare antwoord te kry wat hulle nie kan gebruik nie.

Toets die naam vanuit elke konteks eerder as om aan te neem, en toets die pad onafhanklik van DNS met curl se resolve-opsie, wat die adres vir een versoek vaspen:

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

As die eerste toets 'n adres teruggee wat die kliënt nie kan bereik nie, is die tonnelroetering of die splits-tonnelys die probleem. As die tweede toets 'n herleiding na 'n gasheernaam teruggee wat jy nie verwag het nie, stop en lees die Location-opskrif, want dit is 'n toepassingskwessie en geen roeteverandering sal dit regmaak nie.

Stap 2: belyn die webbediener, sertifikaat en CMS-basis-URL

Die luisteraar moet opgestel wees om die kanonieke naam te bedien, en die sertifikaat moet dit dek. Blaai per rou adres is nie 'n ompad nie: dit veroorsaak 'n naamwanpassing, dit kan koekiebestek breek, en dit leer gebruikers om deur waarskuwings te klik wat jy later aan 'n ouditeur sal moet verduidelik.

Agter 'n omgekeerde instaanbediener, maak seker die toepassing weet die versoek het oor HTTPS aangekom. Die meeste CMS-platforms genereer absolute skakels uit die bespeurde skema, en 'n instaanbediener wat TLS beëindig sonder om die oorspronklike skema aan te stuur, lewer 'n bladsy vol http://-hulpbronne wat 'n blaaier mag blokkeer. Stel die vertroude instaanbediener en aangestuurde opskrifte eksplisiet op eerder as om die toepassing te laat raai.

Belyn dan die CMS- en CiviCRM-basis-URL. CiviCRM hou sy bepaalde basis-URL en bied 'n ondersteunde manier om dit te herbereken: die administratiewe aksie Cleanup Caches and Update Paths, gedokumenteer in die CiviCRM-installasieprobleemgids. Voer dit uit nadat die kanonieke naam en CMS-instelling ooreenstem, nie vantevore nie, anders kas jy bloot 'n waarde wat jy op die punt is om te verander.

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

Stap 3: kontroleer die adresse wat CiviCRM genereer

Om die voorblad te bereik bewys baie min. CiviCRM loop binne 'n CMS, en die bladsye wat saak maak, is dié wat hul eie URL's bou: die aanmeldherleiding, die administrasiekieslys, uitbreidingshulpbronne, skakels na opgelaaide lêers en enige eksterne terugroeping wat deur 'n integrasie geregistreer is.

Laai die paneelbord, maak 'n kontakrekord oop en bekyk die bladsybron vir absolute skakels. As hulle na 'n gasheernaam wys wat net een kliëntegroep kan bereik, is die basis-URL steeds verkeerd al het die bladsy vertoon. As hulle na die regte naam maar die verkeerde skema wys, is die instaanbediener se opstelling die ding om reg te maak.

Waar die adres werklik moet verander, behandel dit as 'n toepassingsmigrasie eerder as 'n DNS-wysiging. Hersien hulpbron-URL's, kasgeheues, gepubliseerde skakels en elke eksterne integrasie wat die ou adres stoor, en werk dit dan in een venster by sodat niemand 'n half-gemigreerde merker vashou nie.

'n Versoek-gasheernaam is nie 'n vertrouensbesluit nie

Moenie 'n bevoorregte basis-URL kies omdat 'n versoekopskrif 'n bepaalde string bevat nie. PHP dokumenteer Apache-opstellings waarin die bedienernaamwaarde 'n gasheernaam kan weerspieël wat die kliënt verskaf het, en die bedieneradresveranderlike beskryf die bediener, nie die besoeker se ligging nie. Nie een van dié is 'n toegangsbeheermeganisme nie, en om een daaruit te bou is hoe 'n private diens uiteindelik die verkeerde inhoud aan die verkeerde gasheer lewer.

As veelvuldige gasheernames werklik nodig is, stel 'n eksplisiete toelaatlys by die webbediener, die CMS en die toepassingslaag op, en laat die versoek-gasheernaam slegs onder goedgekeurde inskrywings kies. Willekeurige invoer moet nooit die bron van absolute skakels of 'n vertroude herleidingsbestemming word nie.

Eindig met dieselfde merker in elke goedgekeurde konteks: 'n aanmelding, 'n gewone interne navigasie en een hulpbronversoek. Vergelyk die gasheernames in die response, nie net of die bladsy gelaai het nie. Daardie drie-versoek-kontrole skei 'n padprobleem van 'n toepassing wat steeds die verkeerde adres genereer, en dit neem omtrent 'n minuut per kliëntegroep.