Ofis və VPN istifadəçiləri üçün vahid CiviCRM URL-i: quraşdırma addımları

Ofis noutbuku öz masasında və yenidən evdən VPN vasitəsilə eyni CiviCRM əlfəcinini açmalıdır. İstifadəçilərlə təmasda davam edən dizayn vahid kanonik ünvandır, deyək ki https://crm.example.org/, hər lokasiyadan təsdiqlənmiş şəbəkə yolu və bu ad üçün etibarlı sertifikatla. VPN uzaq müştərinin serverə necə çatdığını dəyişir. O, heç vaxt tətbiqin kimliyini dəyişməməlidir, çünki bunu etdiyi anda hər yaradılan keçid, yönləndirmə və inteqrasiya geri çağırışı həll edilməli ikinci problemə çevrilir.

Marşrutu seçməzdən əvvəl URL-i seçin

Nəzərdə tutulan ünvanı əvvəlcə yazın, CMS-in ehtiyac duyduğu istənilən yol komponenti daxil olmaqla, və onu sabit nöqtə kimi qəbul edin. Bu təlimatdakı qalan hər şey ona toxunmadan dəyişə bilən tətbiq detalıdır: hər qrupun hansı DNS cavabını aldığı, hansı firewall qaydasının dinləyiciyə icazə verdiyi və trafikin tunel vasitəsilə yoxsa yerli kommutator portu vasitəsilə gəldiyi.

Giriş planında dörd dəyəri birlikdə qeyd edin, çünki onlar yalnız bir dəst kimi işləyir. Kanonik URL. Hər müştəri qrupunun bu ad üçün almalı olduğu cavab. Bu cavab üçün marşrut və giriş qaydası. Veb serverin və sertifikatın xidmət etmək üçün konfiqurasiya edildiyi host adı. Sonradan nəsə pozulduqda, pozulmuş element həmin dörddən biridir və hansını dəyişdiyinizi biləcəksiniz.

Addım 1: adın hər iki qrup üçün düzgün həll olunmasını təmin edin

Hər iki qrup həqiqətən çata bildikləri şəxsi cavab almalıdır və ad dəyişmədiyi müddətcə cavabların fərqlənməsi qanunidir. LAN müştəriləri daxili həlledici vasitəsilə həll edir; VPN müştəriləri sorğunu açıq həllediciyə sızdırmaq və istifadə edə bilməyəcəkləri açıq cavab almaq əvəzinə onlara eyni zonanı verən həlledici siyasətinə ehtiyac duyur.

Adı hər kontekstdən fərz etmək əvəzinə sınayın və yolu DNS-dən asılı olmayaraq curl-un resolve seçimi ilə yoxlayın, hansı ki ünvanı bir sorğu üçün bərkidir:

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

Birinci test müştərinin çata bilmədiyi bir ünvan qaytarırsa, problem tunel marşrutlaşdırması və ya bölünmüş tunel siyahısıdır. İkinci test gözləmədiyiniz host adına yönləndirmə qaytarırsa, dayanın və Location başlığını oxuyun, çünki bu tətbiq məsələsidir və heç bir marşrut dəyişikliyi onu düzəltməyəcək.

Addım 2: veb serveri, sertifikatı və CMS əsas URL-ini uyğunlaşdırın

Dinləyici kanonik ada xidmət etmək üçün konfiqurasiya edilməli və sertifikat onu əhatə etməlidir. Xam ünvanla gəzmək həll yolu deyil: ad uyğunsuzluğu yaradır, kuki əhatəsini poza bilər və istifadəçilərə sonradan auditə izah etməli olacağınız xəbərdarlıqları keçməyi öyrədir.

Əks proxy arxasında tətbiqin sorğunun HTTPS ilə gəldiyini bildiyinə əmin olun. Əksər CMS platformaları aşkar edilən sxemdən mütləq keçidlər yaradır və orijinal sxemi ötürmədən TLS-i sonlandıran proxy brauzerin bloklaya biləcəyi http:// resursları ilə dolu səhifə yaradır. Etibarlı proxy və ötürülən başlıqları tətbiqin təxmin etməsinə imkan vermək əvəzinə açıq şəkildə konfiqurasiya edin.

Sonra CMS və CiviCRM əsas URL-ini uyğunlaşdırın. CiviCRM müəyyən edilmiş əsas URL-ini saxlayır və onu yenidən hesablamaq üçün dəstəklənən üsul təqdim edir: CiviCRM quraşdırma problemlərinin həlli təlimatında sənədləşdirilmiş inzibati Cleanup Caches and Update Paths əməliyyatı. Onu kanonik ad və CMS parametri razılaşdıqdan sonra işə salın, əvvəl yox, əks halda dəyişmək üzrə olduğunuz dəyəri sadəcə keşləyəcəksiniz.

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

Addım 3: CiviCRM-in yaratdığı ünvanları yoxlayın

Ana səhifəyə çatmaq çox az şey sübut edir. CiviCRM CMS-in içində işləyir və əhəmiyyətli səhifələr öz URL-lərini quranlardır: giriş yönləndirməsi, idarəetmə menyusu, genişləndirmə resursları, yüklənmiş fayl keçidləri və inteqrasiyanın qeydiyyatdan keçirdiyi istənilən xarici geri çağırış.

İdarəetmə panelini yükləyin, kontakt qeydini açın və mütləq keçidlər üçün səhifə mənbəyinə baxın. Əgər onlar yalnız bir müştəri qrupunun çata biləcəyi host adına işarə edirsə, səhifə göstərilsə də əsas URL hələ də səhvdir. Əgər onlar düzgün ada amma səhv sxemə işarə edirsə, düzəldilməli olan proxy konfiqurasiyasıdır.

Ünvan həqiqətən dəyişməlidirsə, ona DNS düzəlişi kimi yox, tətbiq miqrasiyası kimi baxın. Resurs URL-lərini, keşləri, dərc edilmiş keçidləri və köhnə ünvanı saxlayan hər xarici inteqrasiyanı nəzərdən keçirin, sonra onları bir pəncərədə yeniləyin ki, heç kim yarım miqrasiya olunmuş əlfəcin tutmasın.

Sorğu host adı etimad qərarı deyil

Sorğu başlığında müəyyən sətir olduğu üçün imtiyazlı əsas URL seçməyin. PHP, server adı dəyərinin müştərinin təqdim etdiyi hostu əks etdirə biləcəyi Apache konfiqurasiyalarını sənədləşdirir və server ünvanı dəyişəni serveri təsvir edir, ziyarətçinin yerini yox. Bunların heç biri giriş nəzarəti mexanizmi deyil və onlardan birini qurmaq şəxsi xidmətin səhv məzmunu səhv hosta təqdim etməsi ilə bitən yoldur.

Birdən çox host adı həqiqətən tələb olunursa, veb serverdə, CMS-də və tətbiq qatında açıq icazə siyahısı konfiqurasiya edin və sorğu host adının yalnız təsdiqlənmiş girişlər arasından seçməsinə icazə verin. İxtiyari giriş heç vaxt mütləq keçidlərin mənbəyi və ya etibarlı yönləndirmə təyinatı olmamalıdır.

Hər təsdiqlənmiş kontekstdə eyni əlfəcinlə bitirin: giriş, adi daxili naviqasiya və bir resurs sorğusu. Cavablardakı host adlarını müqayisə edin, yalnız səhifənin yüklənməsini yox. Bu üç sorğu yoxlaması yol problemini hələ də səhv ünvan yaradan tətbiqdən ayırır və hər müştəri qrupu üçün təxminən bir dəqiqə çəkir.