Ofis ve VPN kullanıcıları için tek bir CiviCRM URL'si: kurulum adımları

Bir ofis dizüstü bilgisayarı masasında ve eve gittiğinde VPN üzerinden aynı CiviCRM yer imini açmalıdır. Kullanıcılarla teması atlatan tasarım tek bir kanonik adrestir, diyelim ki https://crm.example.org/, her konumdan onaylanmış bir ağ yolu ve bu ad için geçerli bir sertifikayla. VPN, uzak bir istemcinin sunucuya nasıl ulaştığını değiştirir. Uygulamanın kimliğini asla değiştirmemelidir, çünkü değiştirdiği anda oluşturulan her bağlantı, yönlendirme ve entegrasyon geri çağrısı çözülmesi gereken ikinci bir sorun haline gelir.

Rotayı seçmeden önce URL'yi seçin

Önce amaçlanan adresi, CMS'nin ihtiyaç duyduğu tüm yol bileşenleri dahil yazın ve onu sabit nokta olarak kabul edin. Bu kılavuzdaki diğer her şey, ona dokunmadan değiştirilebilecek bir uygulama ayrıntısıdır: her grubun hangi DNS yanıtını aldığı, hangi güvenlik duvarı kuralının dinleyiciye izin verdiği ve trafiğin tünelden mi yoksa yerel bir anahtar portundan mı geldiği.

Erişim planına dört değeri birlikte kaydedin, çünkü yalnızca bir küme olarak çalışırlar. Kanonik URL. Her istemci grubunun o ad için alması gereken yanıt. O yanıt için rota ve erişim kuralı. Web sunucusu ve sertifikanın hizmet vermek üzere yapılandırıldığı ana bilgisayar adı. Daha sonra bir şey bozulursa, bozuk öğe bu dördünden biridir ve hangisini değiştirdiğinizi bilirsiniz.

Adım 1: adın her iki grup için doğru şekilde çözümlenmesini sağlayın

Her iki grup da gerçekten ulaşabildikleri özel bir yanıt almalıdır ve ad farklı olmadığı sürece yanıtların farklı olması meşrudur. LAN istemcileri dahili çözümleyici üzerinden çözümler; VPN istemcileri, sorguyu genel bir çözümleyiciye sızdırıp kullanamayacakları genel bir yanıt almak yerine onlara aynı bölgeyi veren bir çözümleyici ilkesine ihtiyaç duyar.

Adı her bağlamdan test edin, varsayımda bulunmayın ve yolu DNS'ten bağımsız olarak curl'ün resolve seçeneğiyle test edin; bu seçenek adresi tek bir istek için sabitler:

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

İlk test istemcinin ulaşamayacağı bir adres döndürürse sorun tünel yönlendirmesi veya bölünmüş tünel listesidir. İkinci test beklemediğiniz bir ana bilgisayar adına yönlendirme döndürürse durun ve Location başlığını okuyun, çünkü bu bir uygulama sorunudur ve hiçbir rota değişikliği onu düzeltmez.

Adım 2: web sunucusunu, sertifikayı ve CMS temel URL'sini hizalayın

Dinleyici kanonik ada hizmet verecek şekilde yapılandırılmalı ve sertifika onu kapsamalıdır. Ham adresle gezinmek bir çözüm değildir: ad uyuşmazlığı yaratır, çerez kapsamını bozabilir ve kullanıcılara daha sonra denetçiye açıklamanız gerekecek uyarıları tıklamayı öğretir.

Ters proxy'nin arkasında, uygulamanın isteğin HTTPS üzerinden geldiğini bildiğinden emin olun. Çoğu CMS platformu algılanan şemadan mutlak bağlantılar üretir ve TLS'i özgün şemayı iletmeden sonlandıran bir proxy, tarayıcının engelleyebileceği http:// kaynaklarla dolu bir sayfa üretir. Uygulamanın tahmin etmesine izin vermek yerine güvenilen proxy'yi ve iletilen başlıkları açıkça yapılandırın.

Ardından CMS ve CiviCRM temel URL'sini hizalayın. CiviCRM belirlenen temel URL'sini korur ve onu yeniden hesaplamanın desteklenen bir yolunu sunar: 'Önbellekleri temizle ve yolları güncelle' yönetim eylemi, şurada belgelenmiştir: CiviCRM kurulum sorun giderme kılavuzu. Kanonik ad ve CMS ayarı uyuştuktan sonra çalıştırın, öncesinde değil, aksi halde değiştirmek üzere olduğunuz bir değeri önbelleğe alırsınız.

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

Adım 3: CiviCRM'in ürettiği adresleri kontrol edin

Ana sayfaya ulaşmak çok az şey kanıtlar. CiviCRM bir CMS'in içinde çalışır ve önemli olan sayfalar kendi URL'lerini oluşturanlardır: oturum açma yönlendirmesi, yönetim menüsü, uzantı kaynakları, yüklenen dosya bağlantıları ve bir entegrasyonun kaydettiği herhangi bir dış geri çağrı.

Panoyu yükleyin, bir kişi kaydı açın ve mutlak bağlantılar için sayfa kaynağına bakın. Yalnızca bir istemci grubunun ulaşabildiği bir ana bilgisayar adına işaret ediyorsa, sayfa görüntülenmiş olsa da temel URL hâlâ yanlıştır. Doğru ada ama yanlış şemaya işaret ediyorsa, düzeltilmesi gereken şey proxy yapılandırmasıdır.

Adresin gerçekten değişmesi gereken yerlerde bunu bir DNS düzenlemesi değil, uygulama geçişi olarak ele alın. Kaynak URL'lerini, önbellekleri, yayımlanmış bağlantıları ve eski adresi saklayan her dış entegrasyonu gözden geçirin, ardından kimse yarısı taşınmış bir yer imiyle kalmasın diye hepsini tek bir pencerede güncelleyin.

İstekteki ana bilgisayar adı bir güven kararı değildir

Bir istek başlığı belirli bir dize içeriyor diye ayrıcalıklı bir temel URL seçmeyin. PHP, sunucu adı değerinin istemci tarafından sağlanan bir ana bilgisayarı yansıtabildiği Apache yapılandırmalarını belgeler ve sunucu adresi değişkeni sunucuyu tanımlar, ziyaretçinin konumunu değil. Bunların hiçbiri bir erişim denetimi mekanizması değildir ve bunlardan birini inşa etmek, özel bir hizmetin yanlış ana bilgisayara yanlış içerik sunmaya başlamasının yoludur.

Gerçekten birden çok ana bilgisayar adı gerekiyorsa, web sunucusunda, CMS'de ve uygulama katmanında açık bir izin listesi yapılandırın ve isteğin ana bilgisayar adının yalnızca onaylanmış girdiler arasından seçmesine izin verin. Rastgele girdi hiçbir zaman mutlak bağlantıların kaynağı veya güvenilen bir yönlendirme hedefi olmamalıdır.

Onaylanan her bağlamda aynı yer imiyle bitirin: bir oturum açma, sıradan bir iç gezinme ve bir kaynak isteği. Yanıtlardaki ana bilgisayar adlarını karşılaştırın, yalnızca sayfanın yüklenip yüklenmediğini değil. Bu üç istekli kontrol, bir yol sorununu hâlâ yanlış adres üreten bir uygulamadan ayırır ve istemci grubu başına yaklaşık bir dakika sürer.