Egyetlen CiviCRM URL irodai és VPN-felhasználóknak: beállítási lépések

Az irodai laptopnak ugyanazt a CiviCRM-könyvjelzőt kell megnyitnia az íróasztalánál, majd otthonról is a VPN-en keresztül. A felhasználókkal való találkozást túlélő kialakítás egyetlen kanonikus cím, mondjuk https://crm.example.org/, jóváhagyott hálózati útvonallal minden helyszínről és az adott névre érvényes tanúsítvánnyal. A VPN megváltoztatja, hogyan ér el egy távoli kliens a kiszolgálót. Soha nem szabad megváltoztatnia az alkalmazás identitását, mert abban a pillanatban, amikor mégis megteszi, minden generált hivatkozás, átirányítás és integrációs visszahívás második megoldandó problémává válik.

Az URL-t az útvonal előtt válassza ki

Először írja le a szándékolt címet, beleértve a CMS által igényelt bármely elérési út-összetevőt, és kezelje fix pontként. Minden más ebben az útmutatóban olyan megvalósítási részlet, amely anélkül változhat, hogy hozzányúlnánk: melyik DNS-választ kapja az egyes csoportok, melyik tűzfal-szabály engedi a figyelőt, és hogy a forgalom alagúton vagy helyi kapcsolóporton érkezik-e.

Rögzítsen négy értéket együtt a hozzáférési tervben, mert csak együtt működnek. A kanonikus URL. A válasz, amelyet minden klienscsoportnak kapnia kell ehhez a névhez. Az útvonal és a hozzáférési szabály ehhez a válaszhoz. A hosztnév, amelyre a webkiszolgáló és a tanúsítvány be van állítva. Amikor később valami elromlik, az elromlott elem e négy közül az egyik lesz, és tudni fogja, melyiket változtatta meg.

1 lépés: gondoskodjon arról, hogy a név mindkét csoport számára helyesen oldódjon fel

Mindkét csoportnak olyan privát választ kell kapnia, amelyet ténylegesen el tud érni, és jogos, hogy a válaszok eltérjenek, amíg a név nem tér el. A LAN-kliensek a belső feloldón keresztül oldanak fel; a VPN-klienseknek olyan feloldóházirend kell, amely ugyanazt a zónát adja nekik, ahelyett hogy a lekérdezés nyilvános feloldóhoz szivárogna, és olyan nyilvános válasz érkezne, amelyet nem tudnak használni.

Tesztelje a nevet minden környezetből ahelyett, hogy feltételezné, és tesztelje az útvonalat a DNS-től függetlenül a curl resolve kapcsolójával, amely egy kérésre rögzíti a címet:

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

Ha az első teszt olyan címet ad vissza, amelyet a kliens nem ér el, a probléma az alagút útvonalválasztása vagy a megosztott alagút listája. Ha a második teszt olyan hosztnévre irányít át, amelyre nem számított, álljon meg, és olvassa el a Location fejlécet, mert ez alkalmazásprobléma, és semmilyen útvonalváltoztatás nem javítja meg.

2 lépés: hangolja össze a webkiszolgálót, a tanúsítványt és a CMS alap-URL-jét

A figyelőt úgy kell beállítani, hogy a kanonikus nevet szolgálja ki, és a tanúsítványnak le kell fednie azt. A nyers címen való böngészés nem megoldás: név-eltérést okoz, megtörheti a sütik hatókörét, és megtanítja a felhasználókat olyan figyelmeztetések átkattintására, amelyeket később egy ellenőrnek kell elmagyaráznia.

Fordított proxy mögött győződjön meg arról, hogy az alkalmazás tudja, a kérés HTTPS-en érkezett. A legtöbb CMS-platform az észlelt sémából generál abszolút hivatkozásokat, és az a proxy, amely az eredeti séma továbbítása nélkül fejezi be a TLS-t, http:// erőforrásokkal teli oldalt állít elő, amelyeket a böngésző blokkolhat. A megbízható proxyt és a továbbított fejléceket kifejezetten állítsa be, ahelyett hogy hagyná az alkalmazást találgatni.

Ezután hangolja össze a CMS és a CiviCRM alap-URL-jét. A CiviCRM megtartja a meghatározott alap-URL-jét, és támogatott módot kínál az újraszámítására: a Cleanup Caches and Update Paths adminisztratív műveletet, amely a CiviCRM telepítési hibaelhárítási útmutatójában van dokumentálva. Akkor futtassa, miután a kanonikus név és a CMS-beállítás egyezik, ne előbb, különben csak gyorsítótáraz egy értéket, amelyet éppen módosítani fog.

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

3 lépés: ellenőrizze a CiviCRM által generált címeket

A kezdőlap elérése nagyon keveset bizonyít. A CiviCRM egy CMS-en belül fut, és azok az oldalak számítanak, amelyek saját URL-eket építenek: a bejelentkezési átirányítás, az adminisztrációs menü, a bővítmény-erőforrások, a feltöltött fájlokra mutató hivatkozások és minden olyan külső visszahívás, amelyet egy integráció regisztrál.

Töltse be az irányítópultot, nyisson meg egy kapcsolatrekordot, és nézze meg az oldal forrását abszolút hivatkozások után kutatva. Ha olyan hosztnévre mutatnak, amelyet csak egy klienscsoport ér el, az alap-URL továbbra is hibás, még ha az oldal meg is jelent. Ha a helyes névre, de a rossz sémára mutatnak, a proxy konfigurációját kell javítani.

Ahol a címnek valóban változnia kell, kezelje alkalmazás-migrációként, nem DNS-szerkesztésként. Tekintse át az erőforrás-URL-eket, a gyorsítótárakat, a közzétett hivatkozásokat és minden külső integrációt, amely a régi címet tárolja, majd egyetlen ablakban frissítse őket, hogy senkinél ne maradjon félig áttelepített könyvjelző.

A kérés hosztneve nem bizalmi döntés

Ne válasszon kiemelt alap-URL-t azért, mert egy kérésfejléc tartalmaz egy bizonyos karakterláncot. A PHP olyan Apache-konfigurációkat dokumentál, amelyekben a kiszolgálónév értéke tükrözheti az ügyfél által megadott hosztot, és a kiszolgálócím-változó a kiszolgálót írja le, nem a látogató helyét. Egyik sem hozzáférés-vezérlési mechanizmus, és az egyikből ilyet építeni az az út, amelyen egy privát szolgáltatás végül rossz tartalmat szolgál ki a rossz hosztnak.

Ha valóban több hosztnév szükséges, állítson be kifejezett engedélyezési listát a webkiszolgálón, a CMS-ben és az alkalmazásrétegben, és hagyja, hogy a kérés hosztneve csak jóváhagyott bejegyzések közül válasszon. Az önkényes bemenet soha nem válhat abszolút hivatkozások forrásává vagy megbízható átirányítási célponttá.

Ugyanazzal a könyvjelzővel fejezze be minden jóváhagyott környezetben: bejelentkezés, hétköznapi belső navigáció és egy erőforráskérés. Hasonlítsa össze a válaszokban szereplő hosztneveket, ne csak azt, hogy betöltődött-e az oldal. Ez a három kérésből álló ellenőrzés elválasztja az útvonalproblémát attól az alkalmazástól, amely még mindig rossz címet generál, és klienscsoportonként körülbelül egy percet vesz igénybe.