Unha única URL de CiviCRM para usuarios de oficina e VPN: pasos de configuración

Un portátil de oficina debería abrir o mesmo marcador de CiviCRM no seu escritorio e de novo desde casa pola VPN. O deseño que sobrevive ao contacto cos usuarios é unha dirección canónica, por exemplo https://crm.example.org/, cunha ruta de rede aprobada desde cada localización e un certificado válido para ese nome. A VPN cambia como un cliente remoto chega ao servidor. Nunca debería cambiar a identidade da aplicación, porque no momento en que o fai, cada ligazón xerada, redirección e chamada de retorno de integración convértese nun segundo problema que resolver.

Escolla a URL antes de escoller a ruta

Anote primeiro a dirección prevista, incluído calquera compoñente de ruta que necesite o CMS, e trátea como o punto fixo. Todo o demais neste manual é un detalle de implementación que pode cambiar sen tocala: que resposta DNS recibe cada grupo, que regra de cortalumes permite o receptor e se o tráfico chega por un túnel ou por un porto de conmutador local.

Rexistre catro valores xuntos no plan de acceso, porque só funcionan como un conxunto. A URL canónica. A resposta que debe recibir cada grupo de clientes para ese nome. A ruta e a regra de acceso para esa resposta. O nome de host que o servidor web e o certificado están configurados para servir. Cando algo se rompa máis adiante, o elemento roto é un deses catro, e saberá cal cambiou.

Paso 1: faga que o nome se resolva correctamente para ambos os grupos

Ambos os grupos deberían recibir unha resposta privada á que realmente poidan chegar, e é lexítimo que as respostas difiran sempre que o nome non difira. Os clientes de LAN resolven mediante o resolvedor interno; os clientes de VPN necesitan unha política de resolvedor que lles entregue a mesma zona en lugar de filtrar a consulta a un resolvedor público e obter unha resposta pública que non poden usar.

Probe o nome desde cada contexto en lugar de supoñelo, e probe a ruta con independencia do DNS coa opción resolve de curl, que fixa o enderezo para unha petición:

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

Se a primeira proba devolve un enderezo ao que o cliente non pode chegar, o problema é o encamiñamento do túnel ou a lista de túnel dividido. Se a segunda proba devolve unha redirección a un nome de host que non esperaba, detéñase e lea a cabeceira Location, porque iso é un problema da aplicación e ningún cambio de ruta o arranxará.

Paso 2: aliñe o servidor web, o certificado e a URL base do CMS

O receptor debe estar configurado para servir o nome canónico, e o certificado debe cubrilo. Navegar polo enderezo en bruto non é unha solución: produce unha discrepancia de nome, pode romper o ámbito das cookies e ensina aos usuarios a pasar por alto avisos que despois terá que explicar a un auditor.

Detrás dun proxy inverso, asegúrese de que a aplicación sabe que a petición chegou por HTTPS. A maioría das plataformas CMS xeran ligazóns absolutas a partir do esquema detectado, e un proxy que remata TLS sen reenviar o esquema orixinal produce unha páxina chea de recursos http:// que o navegador pode bloquear. Configure o proxy de confianza e as cabeceiras reenviadas de forma explícita, en lugar de deixar que a aplicación adiviñe.

Despois aliñe a URL base do CMS e de CiviCRM. CiviCRM conserva a súa URL base determinada e ofrece unha forma compatible de recalculala: a acción administrativa Cleanup Caches and Update Paths, documentada na guía de solución de problemas de instalación de CiviCRM. Execútea despois de que coincidan o nome canónico e a configuración do CMS, non antes, ou simplemente almacenará en caché un valor que está a piques de cambiar.

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

Paso 3: comprobe os enderezos que xera CiviCRM

Chegar á páxina principal demostra moi pouco. CiviCRM execútase dentro dun CMS, e as páxinas que importan son as que constrúen as súas propias URL: a redirección de inicio de sesión, o menú de administración, os recursos das extensións, as ligazóns aos ficheiros subidos e calquera chamada de retorno externa que rexistre unha integración.

Cargue o panel, abra un rexistro de contacto e examine o código fonte da páxina na procura de ligazóns absolutas. Se apuntan a un nome de host ao que só pode chegar un grupo de clientes, a URL base segue sendo incorrecta aínda que a páxina se mostrase. Se apuntan ao nome correcto pero ao esquema incorrecto, a configuración do proxy é o que hai que corrixir.

Cando o enderezo realmente teña que cambiar, tráteo como unha migración da aplicación e non como unha edición de DNS. Revise as URL de recursos, as cachés, as ligazóns publicadas e cada integración externa que garde o enderezo antigo, e despois actualíceas nunha soa xanela para que ninguén quede cun marcador migrado a medias.

O nome de host dunha petición non é unha decisión de confianza

Non seleccione unha URL base privilexiada porque unha cabeceira de petición conteña unha cadea concreta. PHP documenta configuracións de Apache nas que o valor do nome do servidor pode reflectir un host fornecido polo cliente, e a variable de enderezo do servidor describe o servidor, non a localización do visitante. Ningunha das dúas é un mecanismo de control de acceso, e construír un a partir delas é como un servizo privado acaba servindo o contido equivocado ao host equivocado.

Se de verdade se necesitan varios nomes de host, configure unha lista de permitidos explícita no servidor web, no CMS e na capa de aplicación, e deixe que o nome de host da petición elixa só entre entradas aprobadas. A entrada arbitraria nunca debería converterse na fonte de ligazóns absolutas nin nun destino de redirección de confianza.

Remate co mesmo marcador en cada contexto aprobado: un inicio de sesión, unha navegación interna ordinaria e unha petición de recurso. Compare os nomes de host nas respostas, non só se a páxina se cargou. Esa comprobación de tres peticións separa un problema de ruta dunha aplicación que segue xerando o enderezo incorrecto, e leva aproximadamente un minuto por grupo de clientes.