Satu URL CiviCRM untuk pengguna kantor dan VPN: langkah penyiapan

Laptop kantor seharusnya membuka markah CiviCRM yang sama di mejanya dan lagi dari rumah melalui VPN. Desain yang bertahan saat bersentuhan dengan pengguna adalah satu alamat kanonis, misalnya https://crm.example.org/, dengan jalur jaringan yang disetujui dari setiap lokasi dan sertifikat yang valid untuk nama itu. VPN mengubah cara klien jarak jauh mencapai server. VPN tidak boleh mengubah identitas aplikasi, karena begitu itu terjadi, setiap tautan yang dihasilkan, pengalihan, dan panggilan balik integrasi menjadi masalah kedua yang harus diselesaikan.

Pilih URL sebelum memilih rute

Tuliskan dulu alamat yang dimaksud, termasuk komponen jalur apa pun yang dibutuhkan CMS, dan perlakukan sebagai titik tetap. Semua hal lain dalam panduan ini adalah detail implementasi yang bisa berubah tanpa menyentuhnya: jawaban DNS mana yang diterima setiap kelompok, aturan firewall mana yang mengizinkan pendengar, dan apakah lalu lintas datang melalui terowongan atau port sakelar lokal.

Catat empat nilai bersama di rencana akses, karena semuanya hanya berfungsi sebagai satu set. URL kanonis. Jawaban yang harus diterima setiap kelompok klien untuk nama itu. Rute dan aturan akses untuk jawaban itu. Nama host yang dikonfigurasi untuk dilayani oleh server web dan sertifikat. Ketika sesuatu rusak nanti, elemen yang rusak adalah salah satu dari empat itu, dan Anda akan tahu mana yang Anda ubah.

Langkah 1: pastikan nama terselesaikan dengan benar untuk kedua kelompok

Kedua kelompok harus menerima jawaban privat yang benar-benar bisa mereka capai, dan sah jika jawabannya berbeda selama namanya tidak berbeda. Klien LAN menyelesaikan melalui penyelesai internal; klien VPN memerlukan kebijakan penyelesai yang memberi mereka zona yang sama alih-alih membocorkan kueri ke penyelesai publik dan mendapat jawaban publik yang tidak bisa mereka gunakan.

Uji nama dari setiap konteks alih-alih mengasumsikan, dan uji jalur secara independen dari DNS dengan opsi resolve curl, yang mematok alamat untuk satu permintaan:

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

Jika uji pertama mengembalikan alamat yang tidak bisa dicapai klien, masalahnya ada pada perutean terowongan atau daftar terowongan terpisah. Jika uji kedua mengembalikan pengalihan ke nama host yang tidak Anda duga, berhenti dan baca header Location, karena itu masalah aplikasi dan tidak ada perubahan rute yang akan memperbaikinya.

Langkah 2: selaraskan server web, sertifikat, dan URL dasar CMS

Pendengar harus dikonfigurasi untuk melayani nama kanonis, dan sertifikat harus mencakupnya. Menjelajah dengan alamat mentah bukan solusi: itu menghasilkan ketidakcocokan nama, dapat merusak cakupan cookie, dan mengajari pengguna untuk melewati peringatan yang nanti harus Anda jelaskan kepada auditor.

Di belakang proksi terbalik, pastikan aplikasi tahu bahwa permintaan datang melalui HTTPS. Sebagian besar platform CMS menghasilkan tautan absolut dari skema yang terdeteksi, dan proksi yang mengakhiri TLS tanpa meneruskan skema asli menghasilkan halaman penuh sumber daya http:// yang mungkin diblokir peramban. Konfigurasikan proksi tepercaya dan header yang diteruskan secara eksplisit, alih-alih membiarkan aplikasi menebak.

Lalu selaraskan URL dasar CMS dan CiviCRM. CiviCRM mempertahankan URL dasar yang ditetapkan dan menyediakan cara yang didukung untuk menghitungnya ulang: tindakan administratif Cleanup Caches and Update Paths, yang didokumentasikan dalam panduan pemecahan masalah pemasangan CiviCRM. Jalankan setelah nama kanonis dan pengaturan CMS cocok, bukan sebelumnya, kalau tidak Anda hanya akan menyimpan dalam cache nilai yang akan segera Anda ubah.

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

Langkah 3: periksa alamat yang dihasilkan CiviCRM

Mencapai halaman depan membuktikan sangat sedikit. CiviCRM berjalan di dalam CMS, dan halaman yang penting adalah yang membangun URL sendiri: pengalihan login, menu administrasi, sumber daya ekstensi, tautan berkas yang diunggah, dan panggilan balik eksternal apa pun yang didaftarkan oleh integrasi.

Muat dasbor, buka catatan kontak, dan lihat sumber halaman untuk tautan absolut. Jika tautan menunjuk ke nama host yang hanya bisa dicapai satu kelompok klien, URL dasar masih salah meskipun halaman telah ditampilkan. Jika tautan menunjuk ke nama yang benar tetapi skema yang salah, konfigurasi proksilah yang harus diperbaiki.

Bila alamat benar-benar harus berubah, perlakukan sebagai migrasi aplikasi, bukan penyuntingan DNS. Tinjau URL sumber daya, cache, tautan yang diterbitkan, dan setiap integrasi eksternal yang menyimpan alamat lama, lalu perbarui semuanya dalam satu jendela agar tidak ada yang memegang markah yang baru separuh dimigrasikan.

Nama host permintaan bukan keputusan kepercayaan

Jangan memilih URL dasar istimewa karena header permintaan berisi string tertentu. PHP mendokumentasikan konfigurasi Apache yang nilai nama servernya dapat mencerminkan host yang dipasok klien, dan variabel alamat server menjelaskan server, bukan lokasi pengunjung. Tidak satu pun dari keduanya adalah mekanisme kontrol akses, dan membangunnya dari salah satunya adalah cara layanan privat akhirnya menyajikan konten yang salah ke host yang salah.

Jika beberapa nama host benar-benar diperlukan, konfigurasikan daftar izin eksplisit di server web, CMS, dan lapisan aplikasi, dan biarkan nama host permintaan memilih hanya di antara entri yang disetujui. Masukan arbitrer tidak boleh pernah menjadi sumber tautan absolut atau tujuan pengalihan tepercaya.

Akhiri dengan markah yang sama di setiap konteks yang disetujui: login, navigasi internal biasa, dan satu permintaan sumber daya. Bandingkan nama host dalam respons, bukan hanya apakah halaman dimuat. Pemeriksaan tiga permintaan itu memisahkan masalah jalur dari aplikasi yang masih menghasilkan alamat salah, dan butuh sekitar satu menit per kelompok klien.