Un singur URL CiviCRM pentru utilizatorii de birou și VPN: pașii de configurare

Un laptop de birou ar trebui să deschidă același semn de carte CiviCRM la birou și din nou de acasă prin VPN. Designul care rezistă la contactul cu utilizatorii este o singură adresă canonică, să spunem https://crm.example.org/, cu o cale de rețea aprobată din fiecare locație și un certificat valid pentru acel nume. VPN-ul schimbă modul în care un client la distanță ajunge la server. Nu ar trebui să schimbe niciodată identitatea aplicației, pentru că în momentul în care o face, fiecare link generat, redirecționare și apel invers de integrare devine o a doua problemă de rezolvat.

Alegeți URL-ul înainte de a alege ruta

Scrieți mai întâi adresa dorită, inclusiv orice componentă de cale de care are nevoie CMS-ul, și tratați-o ca punct fix. Tot restul din acest ghid este un detaliu de implementare care se poate schimba fără a o atinge: ce răspuns DNS primește fiecare grup, ce regulă de firewall permite listenerul și dacă traficul ajunge printr-un tunel sau printr-un port de switch local.

Înregistrați patru valori împreună în planul de acces, pentru că funcționează doar ca un set. URL-ul canonic. Răspunsul pe care ar trebui să-l primească fiecare grup de clienți pentru acel nume. Ruta și regula de acces pentru acel răspuns. Numele de gazdă pe care serverul web și certificatul sunt configurate să îl deservească. Când ceva se strică mai târziu, elementul stricat este unul dintre acele patru și veți ști pe care l-ați schimbat.

Pasul 1: faceți ca numele să se rezolve corect pentru ambele grupuri

Ambele grupuri ar trebui să primească un răspuns privat pe care îl pot accesa efectiv, iar răspunsurile pot diferi, atât timp cât numele nu diferă. Clienții LAN rezolvă prin resolverul intern; clienții VPN au nevoie de o politică de resolver care să le dea aceeași zonă, în loc să scurgă interogarea către un resolver public și să primească un răspuns public pe care nu îl pot folosi.

Testați numele din fiecare context în loc să presupuneți, și testați calea independent de DNS cu opțiunea resolve a curl, care fixează adresa pentru o singură cerere:

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

Dacă primul test returnează o adresă la care clientul nu poate ajunge, problema este rutarea tunelului sau lista de split-tunnel. Dacă al doilea test returnează o redirecționare către un nume de gazdă la care nu vă așteptați, opriți-vă și citiți antetul Location, pentru că este o problemă a aplicației și nicio schimbare de rută nu o va rezolva.

Pasul 2: aliniați serverul web, certificatul și URL-ul de bază al CMS-ului

Listenerul trebuie configurat să deservească numele canonic, iar certificatul trebuie să îl acopere. Navigarea prin adresa brută nu este o soluție: produce o nepotrivire de nume, poate rupe domeniul cookie-urilor și îi învață pe utilizatori să treacă peste avertismente pe care mai târziu va trebui să le explicați unui auditor.

În spatele unui proxy invers, asigurați-vă că aplicația știe că cererea a sosit prin HTTPS. Majoritatea platformelor CMS generează linkuri absolute din schema detectată, iar un proxy care termină TLS fără a transmite schema originală produce o pagină plină de http:// resurse pe care browserul le poate bloca. Configurați explicit proxy-ul de încredere și antetele transmise, în loc să lăsați aplicația să ghicească.

Apoi aliniați URL-ul de bază al CMS-ului și al CiviCRM. CiviCRM păstrează URL-ul de bază determinat și expune o modalitate acceptată de a-l recalcula: acțiunea administrativă Curățați cache-urile și actualizați căile, documentată în ghidul de depanare a instalării CiviCRM. Rulați-o după ce numele canonic și setarea CMS sunt de acord, nu înainte, altfel veți stoca în cache o valoare pe care sunteți pe punctul de a o schimba.

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

Pasul 3: verificați adresele pe care le generează CiviCRM

A ajunge la pagina principală dovedește foarte puțin. CiviCRM rulează în interiorul unui CMS, iar paginile care contează sunt cele care își construiesc propriile URL-uri: redirecționarea de autentificare, meniul de administrare, resursele extensiilor, linkurile către fișierele încărcate și orice apel invers extern înregistrat de o integrare.

Încărcați tabloul de bord, deschideți o înregistrare de contact și vizualizați sursa paginii pentru linkuri absolute. Dacă acestea indică un nume de gazdă pe care doar un grup de clienți îl poate accesa, URL-ul de bază este în continuare greșit chiar dacă pagina s-a afișat. Dacă indică numele corect dar schema greșită, configurația proxy-ului este cea care trebuie reparată.

Acolo unde adresa chiar trebuie schimbată, tratați-o ca o migrare a aplicației și nu ca o editare DNS. Revizuiți URL-urile resurselor, cache-urile, linkurile publicate și fiecare integrare externă care stochează adresa veche, apoi actualizați-le într-o singură fereastră, ca nimeni să nu rămână cu un semn de carte pe jumătate migrat.

Un nume de gazdă din cerere nu este o decizie de încredere

Nu selectați un URL de bază privilegiat doar pentru că un antet al cererii conține un anumit șir. PHP documentează configurații Apache în care valoarea numelui serverului poate reflecta o gazdă furnizată de client, iar variabila de adresă a serverului descrie serverul, nu locația vizitatorului. Niciuna dintre ele nu este un mecanism de control al accesului, iar construirea unuia din ele este modul în care un serviciu privat ajunge să servească conținutul greșit gazdei greșite.

Dacă sunt cu adevărat necesare mai multe nume de gazdă, configurați o listă de permisiuni explicită la serverul web, la CMS și la nivelul aplicației, și lăsați numele de gazdă din cerere să selecteze doar dintre intrările aprobate. Intrările arbitrare nu ar trebui să devină niciodată sursa linkurilor absolute sau o destinație de redirecționare de încredere.

Încheiați cu același semn de carte în fiecare context aprobat: o autentificare, o navigare internă obișnuită și o cerere de resursă. Comparați numele de gazdă din răspunsuri, nu doar dacă pagina s-a încărcat. Acel test cu trei cereri separă o problemă de cale de o aplicație care încă generează adresa greșită și durează aproximativ un minut pe grup de clienți.