Um único URL CiviCRM para utilizadores de escritório e VPN: passos de configuração

Um portátil de escritório deve abrir o mesmo marcador CiviCRM na secretária e novamente em casa através da VPN. O desenho que sobrevive ao contacto com os utilizadores é um endereço canónico, digamos https://crm.example.org/, com um caminho de rede aprovado a partir de cada local e um certificado válido para esse nome. A VPN altera a forma como um cliente remoto chega ao servidor. Nunca deve alterar a identidade da aplicação, porque no momento em que o faz, cada ligação gerada, redireccionamento e callback de integração passa a ser um segundo problema para resolver.

Escolha o URL antes de escolher a rota

Escreva primeiro o endereço pretendido, incluindo qualquer componente de caminho de que o CMS necessite, e trate-o como o ponto fixo. Tudo o resto neste manual é um detalhe de implementação que pode mudar sem lhe tocar: que resposta DNS cada grupo recebe, que regra de firewall permite o listener e se o tráfego chega por um túnel ou por uma porta de switch local.

Registe quatro valores em conjunto no plano de acesso, porque só funcionam como um conjunto. O URL canónico. A resposta que cada grupo de clientes deve receber para esse nome. A rota e a regra de acesso para essa resposta. O nome de anfitrião que o servidor web e o certificado estão configurados para servir. Quando algo falhar mais tarde, o elemento avariado é um desses quatro e saberá qual alterou.

Passo 1: faça com que o nome resolva corretamente para ambos os grupos

Ambos os grupos devem receber uma resposta privada que consigam realmente alcançar, e é legítimo que as respostas difiram desde que o nome não difira. Os clientes LAN resolvem através do resolver interno; os clientes VPN precisam de uma política de resolver que lhes dê a mesma zona em vez de deixar a consulta escapar para um resolver público e receber uma resposta pública que não conseguem usar.

Teste o nome a partir de cada contexto em vez de assumir, e teste o caminho independentemente do DNS com a opção resolve do curl, que fixa o endereço para um pedido:

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

Se o primeiro teste devolver um endereço que o cliente não consegue alcançar, o problema é o encaminhamento do túnel ou a lista de split-tunnel. Se o segundo teste devolver um redireccionamento para um nome de anfitrião que não esperava, pare e leia o cabeçalho Location, porque isso é um problema da aplicação e nenhuma alteração de rota o corrige.

Passo 2: alinhe o servidor web, o certificado e o URL base do CMS

O listener tem de estar configurado para servir o nome canónico, e o certificado tem de o cobrir. Navegar pelo endereço em bruto não é uma solução alternativa: produz uma incompatibilidade de nome, pode quebrar o âmbito dos cookies e ensina os utilizadores a ignorar avisos que mais tarde terá de explicar a um auditor.

Atrás de um proxy inverso, certifique-se de que a aplicação sabe que o pedido chegou por HTTPS. A maioria das plataformas CMS gera ligações absolutas a partir do esquema detetado, e um proxy que termina o TLS sem reencaminhar o esquema original produz uma página cheia de http:// recursos que o navegador pode bloquear. Configure o proxy de confiança e os cabeçalhos reencaminhados explicitamente, em vez de deixar a aplicação adivinhar.

Depois alinhe o URL base do CMS e do CiviCRM. O CiviCRM mantém o URL base determinado e expõe uma forma suportada de o recalcular: a ação administrativa Limpar caches e atualizar caminhos, documentada no guia de resolução de problemas da instalação do CiviCRM. Execute-a depois de o nome canónico e a definição do CMS concordarem, não antes, ou limitar-se-á a guardar em cache um valor que está prestes a alterar.

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

Passo 3: verifique os endereços que o CiviCRM gera

Chegar à página inicial prova muito pouco. O CiviCRM corre dentro de um CMS, e as páginas que importam são as que constroem os seus próprios URLs: o redireccionamento de início de sessão, o menu de administração, os recursos das extensões, as ligações aos ficheiros carregados e qualquer callback externo registado por uma integração.

Carregue o painel, abra um registo de contacto e veja o código-fonte da página à procura de ligações absolutas. Se apontarem para um nome de anfitrião que só um grupo de clientes consegue alcançar, o URL base continua errado mesmo que a página tenha sido apresentada. Se apontarem para o nome certo mas para o esquema errado, é a configuração do proxy que tem de ser corrigida.

Onde o endereço tiver mesmo de mudar, trate-o como uma migração da aplicação e não como uma edição de DNS. Reveja os URLs dos recursos, as caches, as ligações publicadas e todas as integrações externas que guardam o endereço antigo, e depois atualize-as numa única janela para que ninguém fique com um marcador meio migrado.

Um nome de anfitrião no pedido não é uma decisão de confiança

Não selecione um URL base privilegiado só porque um cabeçalho do pedido contém uma determinada cadeia. O PHP documenta configurações do Apache em que o valor do nome do servidor pode refletir um anfitrião fornecido pelo cliente, e a variável de endereço do servidor descreve o servidor, não a localização do visitante. Nenhuma delas é um mecanismo de controlo de acesso, e construir um a partir delas é como um serviço privado acaba a servir o conteúdo errado ao anfitrião errado.

Se forem realmente necessários vários nomes de anfitrião, configure uma lista de permissões explícita no servidor web, no CMS e na camada da aplicação, e deixe o nome de anfitrião do pedido escolher apenas entre entradas aprovadas. Entradas arbitrárias nunca devem tornar-se a origem de ligações absolutas nem um destino de redireccionamento fidedigno.

Termine com o mesmo marcador em cada contexto aprovado: um início de sessão, uma navegação interna normal e um pedido de recurso. Compare os nomes de anfitrião nas respostas, e não apenas se a página carregou. Esse teste de três pedidos separa um problema de caminho de uma aplicação que continua a gerar o endereço errado, e leva cerca de um minuto por grupo de clientes.