Yksi CiviCRM-osoite toimisto- ja VPN-käyttäjille: asennusvaiheet

Toimiston kannettavan tietokoneen pitäisi avata sama CiviCRM-kirjanmerkki työpöydällä ja uudelleen kotoa VPN:n kautta. Suunnittelu, joka kestää käyttäjien kohtaamisen, on yksi kanoninen osoite, esimerkiksi https://crm.example.org/, johon kuuluu hyväksytty verkkoreitti jokaisesta sijainnista ja kyseiselle nimelle voimassa oleva varmenne. VPN muuttaa sitä, miten etäasiakas saavuttaa palvelimen. Sen ei pitäisi koskaan muuttaa sovelluksen identiteettiä, sillä heti kun se tekee niin, jokaisesta luodusta linkistä, uudelleenohjauksesta ja integraation takaisinkutsusta tulee toinen ratkaistava ongelma.

Valitse URL ennen kuin valitset reitin

Kirjoita aiottu osoite ensin ylös, mukaan lukien mikä tahansa polkukomponentti, jonka CMS tarvitsee, ja kohtele sitä kiinteänä pisteenä. Kaikki muu tässä ohjeessa on toteutuksen yksityiskohta, joka voi muuttua siihen koskematta: minkä DNS-vastauksen kukin ryhmä saa, mikä palomuurisääntö sallii kuuntelijan ja saapuuko liikenne tunnelin vai paikallisen kytkinportin kautta.

Kirjaa neljä arvoa yhteen käyttöoikeussuunnitelmaan, koska ne toimivat vain joukkona. Kanoninen URL. Vastaus, jonka kunkin asiakasryhmän pitäisi saada kyseiselle nimelle. Reitti ja käyttöoikeussääntö kyseiselle vastaukselle. Isäntänimi, jota varten verkkopalvelin ja varmenne on määritetty palvelemaan. Kun jotain myöhemmin hajoaa, rikkinäinen elementti on yksi noista neljästä, ja tiedät, mitä muutit.

Vaihe 1: varmista, että nimi ratkeaa oikein molemmille ryhmille

Molempien ryhmien pitäisi saada yksityinen vastaus, johon ne todella pääsevät, ja on hyväksyttävää, että vastaukset eroavat, kunhan nimi ei eroa. LAN-asiakkaat ratkaisevat sisäisen ratkaisijan kautta; VPN-asiakkaat tarvitsevat ratkaisijakäytännön, joka antaa heille saman vyöhykkeen sen sijaan, että kysely vuotaisi julkiseen ratkaisijaan ja palauttaisi julkisen vastauksen, jota he eivät voi käyttää.

Testaa nimi kustakin ympäristöstä sen sijaan että olettaisit, ja testaa reitti DNS:stä riippumatta curlin resolve-valinnalla, joka kiinnittää osoitteen yhtä pyyntöä varten:

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

Jos ensimmäinen testi palauttaa osoitteen, johon asiakas ei pääse, ongelma on tunnelin reitityksessä tai jaetun tunnelin luettelossa. Jos toinen testi palauttaa uudelleenohjauksen isäntänimeen, jota et odottanut, pysähdy ja lue Location-otsake, sillä se on sovellusongelma, eikä mikään reittimuutos korjaa sitä.

Vaihe 2: kohdista verkkopalvelin, varmenne ja CMS:n perus-URL

Kuuntelija on määritettävä palvelemaan kanonista nimeä, ja varmenteen on katettava se. Raakaosoitteella selaaminen ei ole kiertotie: se tuottaa nimien epäsuhdan, voi rikkoa evästeiden laajuuden ja opettaa käyttäjät ohittamaan varoituksia, jotka joudut myöhemmin selittämään tilintarkastajalle.

Käänteisen välityspalvelimen takana varmista, että sovellus tietää pyynnön saapuneen HTTPS:n kautta. Useimmat CMS-alustat luovat absoluuttisia linkkejä havaitusta skeemasta, ja välityspalvelin, joka päättää TLS:n välittämättä alkuperäistä skeemaa, tuottaa sivun, joka on täynnä http://-resursseja, jotka selain voi estää. Määritä luotettu välityspalvelin ja välitetyt otsakkeet eksplisiittisesti sen sijaan, että annat sovelluksen arvata.

Kohdista sitten CMS:n ja CiviCRMin perus-URL. CiviCRM säilyttää määritetyn perus-URL:nsa ja tarjoaa tuetun tavan laskea sen uudelleen: hallinnollinen Cleanup Caches and Update Paths -toiminto, joka on dokumentoitu CiviCRMin asennuksen vianmääritysoppaassa. Suorita se sen jälkeen, kun kanoninen nimi ja CMS-asetus ovat yhtäpitäviä, ei ennen, muuten vain välimuistiin tallennat arvon, jota olet juuri muuttamassa.

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

Vaihe 3: tarkista osoitteet, jotka CiviCRM luo

Etusivulle pääseminen todistaa hyvin vähän. CiviCRM toimii CMS:n sisällä, ja tärkeitä ovat ne sivut, jotka rakentavat omat URL:nsa: kirjautumisen uudelleenohjaus, hallintavalikko, laajennusten resurssit, ladattujen tiedostojen linkit ja jokainen integraation rekisteröimä ulkoinen takaisinkutsu.

Lataa kojelauta, avaa kontaktitietue ja katso sivun lähdekoodista absoluuttisia linkkejä. Jos ne osoittavat isäntänimeen, johon vain yksi asiakasryhmä pääsee, perus-URL on edelleen väärä, vaikka sivu renderöitiin. Jos ne osoittavat oikeaan nimeen mutta väärään skeemaan, välityspalvelimen kokoonpano on korjattava.

Kun osoite todella on muutettava, kohtele sitä sovellusmigraationa, älä DNS-muokkauksena. Käy läpi resurssien URL:t, välimuistit, julkaistut linkit ja jokainen ulkoinen integraatio, joka tallentaa vanhan osoitteen, ja päivitä ne sitten yhdessä ikkunassa, jotta kenellekään ei jää puoliksi siirrettyä kirjanmerkkiä.

Pyynnön isäntänimi ei ole luottamuspäätös

Älä valitse etuoikeutettua perus-URL:ää siksi, että pyynnön otsake sisältää tietyn merkkijonon. PHP dokumentoi Apache-kokoonpanoja, joissa palvelimen nimen arvo voi heijastaa asiakkaan toimittamaa isäntää, ja palvelimen osoitemuuttuja kuvaa palvelinta, ei vierailijan sijaintia. Kumpikaan niistä ei ole käyttöoikeuden valvontamekanismi, ja sellaisen rakentaminen niistä on tapa, jolla yksityinen palvelu päätyy tarjoamaan väärää sisältöä väärälle isännälle.

Jos useita isäntänimiä todella tarvitaan, määritä eksplisiittinen sallittujen luettelo verkkopalvelimelle, CMS:ään ja sovelluskerrokseen ja anna pyynnön isäntänimen valita vain hyväksytyistä merkinnöistä. Mielivaltainen syöte ei saisi koskaan tulla absoluuttisten linkkien lähteeksi tai luotetuksi uudelleenohjauskohteeksi.

Lopeta samalla kirjanmerkillä jokaisessa hyväksytyssä ympäristössä: kirjautuminen, tavallinen sisäinen navigointi ja yksi resurssipyyntö. Vertaa vastausten isäntänimiä, ei vain sitä, latautuiko sivu. Tämä kolmen pyynnön tarkistus erottaa reittiongelman sovelluksesta, joka edelleen luo väärän osoitteen, ja se vie noin minuutin asiakasryhmää kohden.