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

Prijenosno računalo u uredu treba otvoriti istu CiviCRM oznaku na svom stolu i ponovno od kuće preko VPN-a. Dizajn koji preživi susret s korisnicima je jedna kanonska adresa, recimo https://crm.example.org/, s odobrenom mrežnom putanjom sa 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, svaki generirani link, preusmjeravanje i povratni poziv integracije postaje drugi problem koji treba riješiti.

Odaberite URL prije nego što odaberete rutu

Prvo zapišite namjeravanu adresu, uključujući svaku komponentu putanje koja CMS-u treba, i tretirajte je kao fiksnu točku. Sve ostalo u ovom priručniku je detalj implementacije koji se može promijeniti bez diranja u nju: koji DNS odgovor dobiva svaka grupa, 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 grupa klijenata treba dobiti za to ime. Ruta i pravilo pristupa za taj odgovor. Ime hosta koje su web poslužitelj i certifikat konfigurirani posluživati. Kada se nešto kasnije pokvari, pokvareni element je jedan od tih četiri i znat ćete koji ste promijenili.

Korak 1: osigurajte da se ime ispravno razrješava za obje grupe

Obje grupe 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 dobije javni odgovor koji ne mogu koristiti.

Testirajte ime iz svakog konteksta umjesto da pretpostavljate, i testirajte putanju neovisno o DNS-u pomoću curl-ove opcije 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 u rutiranju tunela ili na popisu podijeljenog tunela. Ako drugi test vrati preusmjeravanje na ime hosta koje niste očekivali, zaustavite se i pročitajte zaglavlje Location, jer je to problem aplikacije i nikakva promjena rute ga neće popraviti.

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 po sirovoj adresi nije zaobilazno rješenje: stvara nepodudarnost imena, može slomiti opseg kolačića i uči korisnike da klikću kroz upozorenja koja ćete kasnije morati objasniti revizoru.

Iza obrnutog proxyja pobrinite se da aplikacija zna da je zahtjev stigao preko HTTPS-a. Većina CMS platformi generira apsolutne linkove iz otkrivene sheme, a proxy koji prekida TLS bez prosljeđivanja izvorne sheme stvara stranicu punu http:// resursa koje preglednik može blokirati. Konfigurirajte pouzdani proxy i proslijeđena zaglavlja izričito, umjesto da pustite aplikaciju da nagađa.

Zatim uskladite osnovni URL CMS-a i CiviCRM-a. CiviCRM čuva svoj određeni osnovni URL i nudi podržan način da ga ponovno izračuna: administrativna radnja Cleanup Caches and Update Paths, dokumentirana u vodiču za rješavanje problema s instalacijom CiviCRM-a. Pokrenite je nakon što se kanonsko ime i postavka CMS-a slažu, a ne prije, inače ćete samo keširati vrijednost koju ćete upravo promijeniti.

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

Korak 3: provjerite adrese koje CiviCRM generira

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

Učitajte nadzornu ploču, otvorite zapis kontakta i pregledajte izvorni kod stranice za apsolutne linkove. Ako pokazuju na ime hosta do kojeg može doći samo jedna grupa klijenata, osnovni URL je još uvijek pogrešan iako se stranica prikazala. Ako pokazuju na ispravno ime, ali pogrešnu shemu, konfiguracija proxyja je ono što treba popraviti.

Kada se adresa doista mora promijeniti, tretirajte to kao migraciju aplikacije, a ne kao uređivanje DNS-a. Pregledajte URL-ove resursa, keš, objavljene linkove i svaku vanjsku integraciju koja pohranjuje staru adresu, zatim ih ažurirajte u jednom prozoru kako nitko ne bi držao napola migriranu oznaku.

Ime hosta zahtjeva nije odluka o povjerenju

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

Ako je više imena hostova doista potrebno, konfigurirajte izričit popis dopuštenih na web poslužitelju, u CMS-u i na sloju aplikacije, i dopustite imenu hosta zahtjeva da bira samo među odobrenim zapisima. Proizvoljni unos nikada ne smije postati izvor apsolutnih linkova ili pouzdano odredište preusmjeravanja.

Završite s istom oznakom u svakom odobrenom kontekstu: prijava, obična interna navigacija i jedan zahtjev za resurs. Usporedite imena hostova u odgovorima, a ne samo je li se stranica učitala. Ta provjera s tri zahtjeva razdvaja problem putanje od aplikacije koja još uvijek generira pogrešnu adresu, a traje oko minute po grupi klijenata.