Una adreça CiviCRM única per a usuaris d'oficina i VPN: passos de configuració

Un portàtil d'oficina hauria d'obrir el mateix marcador de CiviCRM a la seva taula i de nou des de casa a través de la VPN. El disseny que sobreviu al contacte amb els usuaris és una adreça canònica, per exemple https://crm.example.org/, amb un camí de xarxa aprovat des de cada ubicació i un certificat vàlid per a aquest nom. La VPN canvia com un client remot arriba al servidor. No hauria de canviar mai la identitat de l'aplicació, perquè en el moment que ho fa, cada enllaç generat, redirecció i crida de retorn d'integració es converteix en un segon problema per resoldre.

Trieu l'URL abans de triar la ruta

Escriviu primer l'adreça prevista, incloent-hi qualsevol component de camí que necessiti el CMS, i tracteu-la com a punt fix. La resta d'aquest manual són detalls d'implementació que poden canviar sense tocar-la: quina resposta DNS rep cada grup, quina regla de tallafocs permet l'oient i si el trànsit arriba per un túnel o per un port de commutador local.

Registreu quatre valors junts al pla d'accés, perquè només funcionen com a conjunt. L'URL canònica. La resposta que ha de rebre cada grup de clients per a aquest nom. La ruta i la regla d'accés per a aquesta resposta. El nom d'amfitrió que el servidor web i el certificat estan configurats per servir. Quan alguna cosa es trenqui més endavant, l'element trencat és un d'aquests quatre, i sabreu quin heu canviat.

Pas 1: feu que el nom es resolgui correctament per als dos grups

Els dos grups haurien de rebre una resposta privada a la qual realment puguin arribar, i és legítim que les respostes difereixin sempre que el nom no difereixi. Els clients de LAN resolen a través del resolutor intern; els clients de VPN necessiten una política de resolutor que els doni la mateixa zona en lloc de filtrar la consulta a un resolutor públic i obtenir una resposta pública que no poden utilitzar.

Proveu el nom des de cada context en lloc de suposar-lo, i proveu el camí independentment del DNS amb l'opció resolve de curl, que fixa l'adreça per a una petició:

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

Si la primera prova retorna una adreça a la qual el client no pot arribar, el problema és l'encaminament del túnel o la llista de túnel dividit. Si la segona prova retorna una redirecció a un nom d'amfitrió que no esperàveu, atureu-vos i llegiu la capçalera Location, perquè això és un problema d'aplicació i cap canvi de ruta el resoldrà.

Pas 2: alineeu el servidor web, el certificat i l'URL base del CMS

L'oient ha d'estar configurat per servir el nom canònic, i el certificat l'ha de cobrir. Navegar per l'adreça en brut no és una solució alternativa: produeix una discrepància de nom, pot trencar l'abast de les galetes i ensenya els usuaris a fer clic a través d'avisos que després haureu d'explicar a un auditor.

Darrere d'un proxy invers, assegureu-vos que l'aplicació sap que la petició ha arribat per HTTPS. La majoria de plataformes CMS generen enllaços absoluts a partir de l'esquema detectat, i un proxy que acaba TLS sense reenviar l'esquema original produeix una pàgina plena de recursos http:// que el navegador pot bloquejar. Configureu el proxy de confiança i les capçaleres reenviades explícitament, en lloc de deixar que l'aplicació ho endevini.

A continuació, alineeu l'URL base del CMS i de CiviCRM. CiviCRM conserva el seu URL base determinat i ofereix una manera suportada de recalcular-lo: l'acció administrativa Cleanup Caches and Update Paths, documentada a la guia de resolució de problemes d'instal·lació de CiviCRM. Executeu-la després que el nom canònic i la configuració del CMS coincideixin, no abans, o simplement memoritzareu un valor que esteu a punt de canviar.

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

Pas 3: comproveu les adreces que genera CiviCRM

Arribar a la pàgina principal demostra molt poc. CiviCRM s'executa dins d'un CMS, i les pàgines que importen són les que construeixen els seus propis URL: la redirecció d'inici de sessió, el menú d'administració, els recursos de les extensions, els enllaços als fitxers pujats i qualsevol crida de retorn externa registrada per una integració.

Carregueu el tauler, obriu un registre de contacte i mireu el codi font de la pàgina per trobar enllaços absoluts. Si apunten a un nom d'amfitrió al qual només pot arribar un grup de clients, l'URL base encara és incorrecte tot i que la pàgina s'ha representat. Si apunten al nom correcte però a l'esquema incorrecte, la configuració del proxy és el que cal corregir.

On l'adreça realment ha de canviar, tracteu-ho com una migració d'aplicació i no com una edició de DNS. Reviseu els URL dels recursos, les memòries cau, els enllaços publicats i cada integració externa que emmagatzemi l'adreça antiga, i després actualitzeu-los en una sola finestra perquè ningú no quedi amb un marcador migrat a mitges.

El nom d'amfitrió d'una petició no és una decisió de confiança

No seleccioneu un URL base privilegiat perquè una capçalera de petició contingui una cadena concreta. PHP documenta configuracions d'Apache en què el valor del nom del servidor pot reflectir un amfitrió subministrat pel client, i la variable d'adreça del servidor descriu el servidor, no la ubicació del visitant. Cap d'aquests és un mecanisme de control d'accés, i construir-ne un a partir d'ells és com un servei privat acaba servint el contingut equivocat a l'amfitrió equivocat.

Si realment calen diversos noms d'amfitrió, configureu una llista d'autoritzats explícita al servidor web, al CMS i a la capa d'aplicació, i deixeu que el nom d'amfitrió de la petició triï només entre entrades aprovades. L'entrada arbitrària no s'hauria de convertir mai en la font d'enllaços absoluts ni en una destinació de redirecció de confiança.

Acabeu amb el mateix marcador a cada context aprovat: un inici de sessió, una navegació interna ordinària i una petició de recurs. Compareu els noms d'amfitrió a les respostes, no només si la pàgina s'ha carregat. Aquesta comprovació de tres peticions separa un problema de camí d'una aplicació que encara genera l'adreça incorrecta, i triga aproximadament un minut per grup de clients.