Jedan CiviCRM URL za uredske i VPN korisnike: koraci podešavanja

Prijenosno računalo u uredu treba otvoriti istu CiviCRM zabilješku za stolom i ponovno od kuće preko VPN-a. Rješenje koje izdrži susret s korisnicima jest jedan kanonski URL, recimo https://crm.example.org/, s odobrenom mrežnom putanjom iz svake lokacije i certifikatom koji vrijedi za to ime. VPN mijenja način na koji udaljeni klijent dolazi do poslužitelja. Nikada ne smije promijeniti identitet aplikacije, jer u trenutku kada to učini, svaka generirana veza, preusmjerenje i povratni poziv integracije postaju drugi problem koji treba riješiti.

Odaberite URL prije nego što odaberete rutu

Prvo zapišite predviđenu adresu, uključujući svaku komponentu putanje koja je potrebna CMS-u, i tretirajte je kao fiksnu točku. Sve ostalo u ovom priručniku je implementacijski detalj koji se može promijeniti bez dodirivanja adrese: koji DNS odgovor dobiva svaka skupina, koje pravilo vatrozida dopušta slušatelja i dolazi li promet kroz tunel ili kroz lokalni port preklopnika.

Zapišite četiri vrijednosti zajedno u plan pristupa, jer funkcioniraju samo kao skup. Kanonski URL. Odgovor koji svaka skupina klijenata treba dobiti za to ime. Ruta i pravilo pristupa za taj odgovor. Naziv hosta koji su web poslužitelj i certifikat konfigurirani da poslužuju. Kada se nešto kasnije pokvari, pokvareni element je jedan od tih četiriju i znat ćete koji ste promijenili.

Korak 1: pobrinite se da se ime ispravno razriješi za obje skupine

Obje skupine trebaju dobiti privatni odgovor do kojeg stvarno mogu doći, i legitimno je da se odgovori razlikuju sve dok se ime ne razlikuje. LAN klijenti razrješavaju kroz interni razrješivač; VPN klijentima treba politika razrješivača koja im daje istu zonu umjesto da procuri upit prema javnom razrješivaču i vrati javni odgovor koji ne mogu koristiti.

Testirajte ime iz svakog konteksta umjesto da pretpostavljate, i testirajte putanju neovisno od DNS-a s curlovom opcijom resolve, koja prikvači adresu za jedan zahtjev:

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

Ako prvi test vrati adresu do koje klijent ne može doći, problem je usmjeravanje tunela ili popis split-tunnel. Ako drugi test vrati preusmjerenje na naziv hosta koji niste očekivali, zaustavite se i pročitajte zaglavlje Location, jer je to problem aplikacije i nikakva promjena rute ga neće riješiti.

Korak 2: uskladite web poslužitelj, certifikat i osnovni URL CMS-a

Slušatelj mora biti konfiguriran da poslužuje kanonsko ime, a certifikat ga mora pokrivati. Pregledavanje preko sirove adrese nije zaobilazno rješenje: stvara nepodudarnost imena, može pokvariti doseg kolačića i uči korisnike da klikću kroz upozorenja koja ćete kasnije morati objasniti revizoru.

Iza obrnutog proxyja provjerite zna li aplikacija da je zahtjev stigao preko HTTPS-a. Većina CMS platformi generira apsolutne veze iz otkrivene sheme, a proxy koji završava TLS bez prosljeđivanja izvorne sheme stvara stranicu punu http:// resursa koje preglednik može blokirati. Eksplicitno konfigurirajte pouzdani proxy i proslijeđena zaglavlja umjesto da pustite aplikaciju da nagađa.

Zatim uskladite osnovni URL CMS-a i CiviCRM-a. CiviCRM zadržava utvrđeni osnovni URL i nudi podržan način da ga ponovno izračuna: administrativnu radnju Očisti keševe i ažuriraj putanje, dokumentiranu u vodiču za rješavanje problema s instalacijom CiviCRM-a. Pokrenite je nakon što se kanonsko ime i postavka CMS-a usklade, ne prije, inače ćete jednostavno keširati vrijednost koju ćete upravo promijeniti.

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

Korak 3: provjerite adrese koje generira CiviCRM

Dolazak na početnu stranicu dokazuje vrlo malo. CiviCRM radi unutar CMS-a, a važne su stranice koje same grade svoje URL-ove: preusmjerenje prijave, administrativni izbornik, resursi proširenja, veze na prenesene datoteke i svaki vanjski povratni poziv koji registrira integracija.

Učitajte nadzornu ploču, otvorite zapis kontakta i pogledajte izvorni kod stranice zbog apsolutnih veza. Ako pokazuju na naziv hosta do kojeg može doći samo jedna skupina klijenata, osnovni URL je i dalje pogrešan iako se stranica prikazala. Ako pokazuju na ispravno ime ali pogrešnu shemu, konfiguracija proxyja je ono što treba popraviti.

Gdje se adresa doista mora promijeniti, tretirajte to kao migraciju aplikacije, a ne kao uređivanje DNS-a. Pregledajte URL-ove resursa, keševe, objavljene veze i svaku vanjsku integraciju koja čuva staru adresu, a zatim ih ažurirajte u jednom prozoru kako nitko ne bi ostao s napola migriranom zabilješkom.

Naziv hosta u zahtjevu nije odluka o povjerenju

Ne odabirete privilegirani osnovni URL samo zato što zaglavlje zahtjeva sadrži određeni niz. PHP dokumentira Apache konfiguracije u kojima vrijednost naziva poslužitelja može odražavati host koji je dostavio klijent, a varijabla adrese poslužitelja opisuje poslužitelj, ne lokaciju posjetitelja. Nijedno od toga nije mehanizam kontrole pristupa, a gradnja jednoga od njih je način na koji privatna usluga završi poslužujući pogrešan sadržaj pogrešnom hostu.

Ako je doista potrebno više naziva hostova, konfigurirajte eksplicitni popis dopuštenih na web poslužitelju, u CMS-u i na sloju aplikacije, i dopustite da naziv hosta iz zahtjeva bira samo među odobrenim unosima. Proizvoljan unos nikada ne smije postati izvor apsolutnih veza ili pouzdano odredište preusmjerenja.

Završite istom zabilješkom u svakom odobrenom kontekstu: prijava, obična interna navigacija i jedan zahtjev za resursom. Usporedite nazive hostova u odgovorima, a ne samo je li se stranica učitala. Ta provjera s tri zahtjeva razdvaja problem putanje od aplikacije koja još generira pogrešnu adresu i traje otprilike minutu po skupini klijenata.