Komputer riba pejabat harus membuka penanda buku CiviCRM yang sama di mejanya dan sekali lagi dari rumah melalui VPN. Reka bentuk yang tahan berhadapan dengan pengguna ialah satu alamat kanonik, katakan https://crm.example.org/, dengan laluan rangkaian yang diluluskan dari setiap lokasi, dan sijil yang sah untuk nama itu. VPN mengubah cara klien jauh mencapai pelayan. Ia tidak sepatutnya mengubah identiti aplikasi, kerana sebaik sahaja ia berbuat demikian, setiap pautan yang dijana, ubah hala dan panggil balik integrasi menjadi masalah kedua untuk diselesaikan.

Pilih URL sebelum anda memilih laluan

Tuliskan alamat yang dimaksudkan terlebih dahulu, termasuk mana-mana komponen laluan yang diperlukan oleh CMS, dan anggap ia sebagai titik tetap. Segala-galanya dalam buku panduan ini ialah butiran pelaksanaan yang boleh berubah tanpa menyentuhnya: jawapan DNS yang diterima oleh setiap kumpulan, peraturan tembok api yang membenarkan pendengar, dan sama ada trafik tiba melalui terowong atau melalui port suis setempat.

Catat empat nilai bersama-sama dalam pelan akses, kerana ia hanya berfungsi sebagai satu set. URL kanonik. Jawapan yang sepatutnya diterima oleh setiap kumpulan klien untuk nama itu. Laluan dan peraturan akses untuk jawapan itu. Nama hos yang dikonfigurasikan untuk dilayan oleh pelayan web dan sijil. Apabila sesuatu rosak kemudian, elemen yang rosak ialah salah satu daripada empat itu, dan anda akan tahu yang mana satu anda ubah.

Langkah 1: pastikan nama diselesaikan dengan betul untuk kedua-dua kumpulan

Kedua-dua kumpulan harus menerima jawapan peribadi yang benar-benar boleh mereka capai, dan adalah sah untuk jawapan berbeza selagi namanya tidak berbeza. Klien LAN menyelesaikan melalui penyelesai dalaman; klien VPN memerlukan dasar penyelesai yang memberikan mereka zon yang sama dan bukannya membocorkan pertanyaan ke penyelesai awam dan menerima jawapan awam yang tidak dapat mereka gunakan.

Uji nama itu dari setiap konteks dan bukannya menganggap, dan uji laluan secara bebas daripada DNS dengan pilihan resolve curl, yang menetapkan 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 ujian pertama mengembalikan alamat yang klien tidak dapat capai, penghalaan terowong atau senarai terowong terbelah ialah masalahnya. Jika ujian kedua mengembalikan ubah hala ke nama hos yang anda tidak jangkakan, berhenti dan baca pengepala Location, kerana itu masalah aplikasi dan tiada perubahan laluan akan membetulkannya.

Langkah 2: selaraskan pelayan web, sijil dan URL asas CMS

Pendengar mesti dikonfigurasikan untuk melayani nama kanonik, dan sijil mesti meliputinya. Melayari melalui alamat mentah bukan penyelesaian: ia menghasilkan ketidakpadanan nama, boleh merosakkan skop kuki, dan mengajar pengguna untuk mengklik melalui amaran yang kemudiannya perlu anda jelaskan kepada juruaudit.

Di belakang proksi terbalik, pastikan aplikasi tahu permintaan tiba melalui HTTPS. Kebanyakan platform CMS menjana pautan mutlak daripada skema yang dikesan, dan proksi yang menamatkan TLS tanpa memajukan skema asal menghasilkan halaman penuh dengan http:// sumber yang mungkin disekat oleh pelayar. Konfigurasikan proksi dipercayai dan pengepala dimajukan secara eksplisit daripada membiarkan aplikasi meneka.

Kemudian selaraskan URL asas CMS dan CiviCRM. CiviCRM menyimpan URL asas yang ditentukan dan mendedahkan cara yang disokong untuk mengiranya semula: tindakan pentadbiran Bersihkan Cache dan Kemas Kini Laluan, didokumenkan dalam panduan penyelesaian masalah pemasangan CiviCRM. Jalankannya selepas nama kanonik dan tetapan CMS bersetuju, bukan sebelum itu, jika tidak anda hanya akan menyimpan cache nilai yang akan anda ubah.

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

Langkah 3: semak alamat yang dijana oleh CiviCRM

Mencapai halaman hadapan membuktikan sangat sedikit. CiviCRM berjalan di dalam CMS, dan halaman yang penting ialah halaman yang membina URL mereka sendiri: ubah hala log masuk, menu pentadbiran, sumber sambungan, pautan fail yang dimuat naik dan mana-mana panggil balik luaran yang didaftarkan oleh integrasi.

Muatkan papan pemuka, buka rekod kenalan, dan lihat sumber halaman untuk pautan mutlak. Jika ia menunjuk ke nama hos yang hanya boleh dicapai oleh satu kumpulan klien, URL asas masih salah walaupun halaman itu dipaparkan. Jika ia menunjuk ke nama yang betul tetapi skema yang salah, konfigurasi proksi ialah perkara yang perlu diperbaiki.

Di mana alamat itu benar-benar perlu berubah, anggapnya sebagai migrasi aplikasi dan bukan suntingan DNS. Semak URL sumber, cache, pautan yang diterbitkan dan setiap integrasi luaran yang menyimpan alamat lama, kemudian kemas kininya dalam satu tetingkap supaya tiada siapa memegang penanda buku yang separuh berpindah.

Nama hos permintaan bukan keputusan kepercayaan

Jangan pilih URL asas istimewa kerana pengepala permintaan mengandungi rentetan tertentu. PHP mendokumenkan konfigurasi Apache di mana nilai nama pelayan boleh mencerminkan hos yang dibekalkan klien, dan pemboleh ubah alamat pelayan menerangkan pelayan, bukan lokasi pelawat. Kedua-duanya bukan mekanisme kawalan akses, dan membina satu daripadanya ialah cara perkhidmatan peribadi akhirnya melayani kandungan yang salah kepada hos yang salah.

Jika berbilang nama hos benar-benar diperlukan, konfigurasikan senarai benarkan yang eksplisit di pelayan web, CMS dan lapisan aplikasi, dan biarkan nama hos permintaan memilih antara entri yang diluluskan sahaja. Input sewenang-wenangnya tidak sepatutnya menjadi sumber pautan mutlak atau destinasi ubah hala yang dipercayai.

Akhiri dengan penanda buku yang sama dalam setiap konteks yang diluluskan: log masuk, navigasi dalaman biasa, dan satu permintaan sumber. Bandingkan nama hos dalam respons, bukan sekadar sama ada halaman dimuatkan. Semakan tiga permintaan itu memisahkan masalah laluan daripada aplikasi yang masih menjana alamat yang salah, dan mengambil masa kira-kira satu minit setiap kumpulan klien.

Artikel berkaitan