Un unico URL CiviCRM per utenti ufficio e VPN: passaggi di configurazione

Un portatile da ufficio dovrebbe aprire lo stesso segnalibro CiviCRM alla scrivania e di nuovo da casa tramite la VPN. Il progetto che sopravvive al contatto con gli utenti è un indirizzo canonico, ad esempio https://crm.example.org/, con un percorso di rete approvato da ogni sede e un certificato valido per quel nome. La VPN cambia il modo in cui un client remoto raggiunge il server. Non dovrebbe mai cambiare l'identità dell'applicazione, perché nel momento in cui lo fa, ogni link generato, reindirizzamento e callback di integrazione diventa un secondo problema da risolvere.

Scegli l'URL prima di scegliere il percorso

Annota prima l'indirizzo previsto, incluso qualsiasi componente di percorso necessario al CMS, e trattalo come punto fisso. Tutto il resto di questa guida è un dettaglio implementativo che può cambiare senza toccarlo: quale risposta DNS riceve ogni gruppo, quale regola del firewall consente l'ascoltatore e se il traffico arriva da un tunnel o da una porta di commutatore locale.

Registra quattro valori insieme nel piano di accesso, perché funzionano solo come insieme. L'URL canonico. La risposta che ogni gruppo di client deve ricevere per quel nome. Il percorso e la regola di accesso per quella risposta. Il nome host che il server web e il certificato sono configurati a servire. Quando qualcosa si romperà più avanti, l'elemento rotto sarà uno di quei quattro, e saprai quale hai modificato.

Passaggio 1: fai in modo che il nome si risolva correttamente per entrambi i gruppi

Entrambi i gruppi dovrebbero ricevere una risposta privata che possano davvero raggiungere, ed è legittimo che le risposte differiscano purché il nome non differisca. I client LAN risolvono tramite il resolver interno; i client VPN hanno bisogno di una politica del resolver che consegni loro la stessa zona invece di far trapelare la query a un resolver pubblico e ottenere una risposta pubblica che non possono usare.

Verifica il nome da ogni contesto invece di supporlo, e verifica il percorso indipendentemente dal DNS con l'opzione resolve di curl, che fissa l'indirizzo per una richiesta:

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

Se il primo test restituisce un indirizzo che il client non riesce a raggiungere, il problema è nell'instradamento del tunnel o nell'elenco del tunnel diviso. Se il secondo test restituisce un reindirizzamento verso un nome host che non ti aspettavi, fermati e leggi l'intestazione Location, perché è un problema dell'applicazione e nessuna modifica del percorso lo risolverà.

Passaggio 2: allinea il server web, il certificato e l'URL di base del CMS

L'ascoltatore deve essere configurato per servire il nome canonico, e il certificato deve coprirlo. Navigare tramite l'indirizzo grezzo non è una soluzione: produce una mancata corrispondenza del nome, può rompere l'ambito dei cookie e insegna agli utenti a ignorare avvisi che poi dovrai spiegare a un revisore.

Dietro un proxy inverso, assicurati che l'applicazione sappia che la richiesta è arrivata tramite HTTPS. La maggior parte delle piattaforme CMS genera link assoluti dallo schema rilevato, e un proxy che termina TLS senza inoltrare lo schema originale produce una pagina piena di risorse http:// che il browser potrebbe bloccare. Configura esplicitamente il proxy fidato e le intestazioni inoltrate, invece di lasciare che l'applicazione indovini.

Poi allinea l'URL di base del CMS e di CiviCRM. CiviCRM conserva il proprio URL di base determinato ed espone un modo supportato per ricalcolarlo: l'azione amministrativa Cleanup Caches and Update Paths, documentata nella guida alla risoluzione dei problemi di installazione di CiviCRM. Eseguila dopo che il nome canonico e l'impostazione del CMS coincidono, non prima, altrimenti metterai in cache solo un valore che stai per cambiare.

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

Passaggio 3: controlla gli indirizzi che CiviCRM genera

Raggiungere la pagina iniziale dimostra molto poco. CiviCRM gira all'interno di un CMS, e le pagine che contano sono quelle che costruiscono i propri URL: il reindirizzamento del login, il menu di amministrazione, le risorse delle estensioni, i link ai file caricati e qualsiasi callback esterna registrata da un'integrazione.

Carica la dashboard, apri un record di contatto e guarda il codice sorgente della pagina per trovare link assoluti. Se puntano a un nome host che solo un gruppo di client può raggiungere, l'URL di base è ancora sbagliato anche se la pagina è stata visualizzata. Se puntano al nome giusto ma allo schema sbagliato, è la configurazione del proxy da correggere.

Dove l'indirizzo deve davvero cambiare, trattalo come una migrazione dell'applicazione e non come una modifica DNS. Esamina gli URL delle risorse, le cache, i link pubblicati e ogni integrazione esterna che memorizza il vecchio indirizzo, poi aggiornali in un'unica finestra così nessuno resta con un segnalibro migrato a metà.

Un nome host di richiesta non è una decisione di fiducia

Non selezionare un URL di base privilegiato perché un'intestazione di richiesta contiene una certa stringa. PHP documenta configurazioni Apache in cui il valore del nome del server può riflettere un host fornito dal client, e la variabile dell'indirizzo del server descrive il server, non la posizione del visitatore. Nessuna delle due è un meccanismo di controllo degli accessi, e costruirne uno da esse è il modo in cui un servizio privato finisce per servire il contenuto sbagliato all'host sbagliato.

Se sono davvero necessari più nomi host, configura una lista di autorizzati esplicita sul server web, nel CMS e a livello di applicazione, e lascia che il nome host della richiesta scelga solo tra le voci approvate. L'input arbitrario non dovrebbe mai diventare la fonte di link assoluti né una destinazione di reindirizzamento fidata.

Termina con lo stesso segnalibro in ogni contesto approvato: un login, una navigazione interna ordinaria e una richiesta di risorsa. Confronta i nomi host nelle risposte, non solo se la pagina si è caricata. Questo controllo in tre richieste separa un problema di percorso da un'applicazione che genera ancora l'indirizzo sbagliato, e richiede circa un minuto per gruppo di client.