Une seule URL CiviCRM pour les utilisateurs du bureau et du VPN : étapes de configuration

Un ordinateur portable de bureau doit ouvrir le même signet CiviCRM à son poste puis à nouveau depuis chez lui via le VPN. La conception qui survit au contact des utilisateurs est une adresse canonique, par exemple https://crm.example.org/, avec un chemin réseau approuvé depuis chaque emplacement et un certificat valide pour ce nom. Le VPN change la façon dont un client distant atteint le serveur. Il ne doit jamais changer l'identité de l'application, car à l'instant où il le fait, chaque lien généré, redirection et rappel d'intégration devient un second problème à résoudre.

Choisissez l'URL avant de choisir la route

Notez d'abord l'adresse prévue, y compris tout composant de chemin dont le CMS a besoin, et traitez-la comme le point fixe. Tout le reste dans ce guide est un détail de mise en œuvre qui peut changer sans y toucher : quelle réponse DNS chaque groupe reçoit, quelle règle de pare-feu autorise l'écouteur et si le trafic arrive par un tunnel ou par un port de commutateur local.

Consignez quatre valeurs ensemble dans le plan d'accès, car elles ne fonctionnent qu'en tant qu'ensemble. L'URL canonique. La réponse que chaque groupe de clients doit recevoir pour ce nom. La route et la règle d'accès pour cette réponse. Le nom d'hôte que le serveur web et le certificat sont configurés pour servir. Lorsque quelque chose casse plus tard, l'élément cassé est l'un de ces quatre, et vous saurez lequel vous avez modifié.

Étape 1 : faites en sorte que le nom se résolve correctement pour les deux groupes

Les deux groupes doivent recevoir une réponse privée qu'ils peuvent réellement atteindre, et il est légitime que les réponses diffèrent tant que le nom ne diffère pas. Les clients du LAN résolvent via le résolveur interne ; les clients du VPN ont besoin d'une politique de résolveur qui leur remet la même zone plutôt que de laisser fuir la requête vers un résolveur public et d'obtenir une réponse publique inutilisable.

Testez le nom depuis chaque contexte au lieu de le supposer, et testez le chemin indépendamment du DNS avec l'option resolve de curl, qui fixe l'adresse pour une requête :

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

Si le premier test renvoie une adresse que le client ne peut pas atteindre, le problème vient du routage du tunnel ou de la liste de tunnel divisé. Si le second test renvoie une redirection vers un nom d'hôte que vous n'attendiez pas, arrêtez-vous et lisez l'en-tête Location, car il s'agit d'un problème applicatif et aucun changement de route ne le corrigera.

Étape 2 : alignez le serveur web, le certificat et l'URL de base du CMS

L'écouteur doit être configuré pour servir le nom canonique, et le certificat doit le couvrir. Naviguer par l'adresse brute n'est pas une solution : cela produit une incohérence de nom, peut casser la portée des cookies et apprend aux utilisateurs à ignorer des avertissements que vous devrez ensuite expliquer à un auditeur.

Derrière un proxy inverse, assurez-vous que l'application sait que la requête est arrivée en HTTPS. La plupart des plateformes CMS génèrent des liens absolus à partir du schéma détecté, et un proxy qui termine TLS sans transmettre le schéma d'origine produit une page pleine de ressources http:// que le navigateur peut bloquer. Configurez explicitement le proxy de confiance et les en-têtes transmis, au lieu de laisser l'application deviner.

Alignez ensuite l'URL de base du CMS et de CiviCRM. CiviCRM conserve son URL de base déterminée et expose un moyen pris en charge de la recalculer : l'action administrative Cleanup Caches and Update Paths, documentée dans le guide de dépannage de l'installation de CiviCRM. Exécutez-la après que le nom canonique et le réglage du CMS concordent, pas avant, sinon vous ne ferez que mettre en cache une valeur que vous êtes sur le point de changer.

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

Étape 3 : vérifiez les adresses que CiviCRM génère

Atteindre la page d'accueil prouve très peu de chose. CiviCRM s'exécute à l'intérieur d'un CMS, et les pages qui comptent sont celles qui construisent leurs propres URL : la redirection de connexion, le menu d'administration, les ressources des extensions, les liens vers les fichiers téléversés et tout rappel externe enregistré par une intégration.

Chargez le tableau de bord, ouvrez une fiche de contact et examinez le code source de la page pour y trouver des liens absolus. S'ils pointent vers un nom d'hôte qu'un seul groupe de clients peut atteindre, l'URL de base est toujours erronée même si la page s'est affichée. S'ils pointent vers le bon nom mais le mauvais schéma, c'est la configuration du proxy qu'il faut corriger.

Là où l'adresse doit réellement changer, traitez cela comme une migration d'application et non comme une modification DNS. Passez en revue les URL de ressources, les caches, les liens publiés et chaque intégration externe qui stocke l'ancienne adresse, puis mettez-les à jour dans une seule fenêtre pour que personne ne garde un signet à moitié migré.

Un nom d'hôte de requête n'est pas une décision de confiance

Ne sélectionnez pas une URL de base privilégiée parce qu'un en-tête de requête contient une chaîne particulière. PHP documente des configurations Apache dans lesquelles la valeur du nom de serveur peut refléter un hôte fourni par le client, et la variable d'adresse du serveur décrit le serveur, pas l'emplacement du visiteur. Aucune des deux n'est un mécanisme de contrôle d'accès, et en construire un à partir de celles-ci est la façon dont un service privé finit par servir le mauvais contenu au mauvais hôte.

Si plusieurs noms d'hôte sont réellement nécessaires, configurez une liste d'autorisation explicite sur le serveur web, dans le CMS et au niveau de l'application, et laissez le nom d'hôte de la requête choisir uniquement parmi les entrées approuvées. Une entrée arbitraire ne devrait jamais devenir la source de liens absolus ni une destination de redirection fiable.

Terminez avec le même signet dans chaque contexte approuvé : une connexion, une navigation interne ordinaire et une requête de ressource. Comparez les noms d'hôte dans les réponses, pas seulement si la page s'est chargée. Ce contrôle en trois requêtes sépare un problème de chemin d'une application qui génère encore la mauvaise adresse, et il prend environ une minute par groupe de clients.