Մեկ CiviCRM հասցե գրասենյակի և VPN օգտատերերի համար՝ կարգավորման քայլեր

Գրասենյակի նոթբուքը պետք է բացի նույն CiviCRM էջանիշը իր սեղանի մոտ և կրկին տնից VPN-ի միջոցով։ Դիզայնը, որը դիմանում է օգտատերերի հետ շփմանը, մեկ կանոնական հասցե է, ասենք https://crm.example.org/, յուրաքանչյուր վայրից հաստատված ցանցային ուղիով և այդ անվան համար վավեր վկայագրով։ VPN-ը փոխում է, թե ինչպես է հեռավոր հաճախորդը հասնում սերվերին։ Այն երբեք չպետք է փոխի հավելվածի ինքնությունը, քանի որ այն պահին, երբ դա անում է, յուրաքանչյուր գեներացված հղում, վերահասցեավորում և ինտեգրացիայի հետադարձ կանչ դառնում է լուծման ենթակա երկրորդ խնդիր։

Ընտրեք URL-ը նախքան ուղին ընտրելը

Նախ գրեք նախատեսված հասցեն, ներառյալ CMS-ին անհրաժեշտ ցանկացած ուղու բաղադրիչ, և վերաբերվեք դրան որպես ֆիքսված կետ։ Այս ուղեցույցում մնացած ամեն ինչ իրականացման մանրամասնություն է, որը կարող է փոխվել առանց դրան դիպչելու. թե որ DNS պատասխանն է ստանում յուրաքանչյուր խումբը, թե որ firewall կանոնն է թույլատրում լսողին, և արդյոք երթևեկությունը գալիս է թունելով, թե տեղական անջատիչի պորտով։

Միասին գրանցեք չորս արժեք մուտքի պլանում, քանի որ դրանք աշխատում են միայն որպես հավաքածու։ Կանոնական URL-ը։ Այն պատասխանը, որը յուրաքանչյուր հաճախորդ խումբ պետք է ստանա այդ անվան համար։ Այդ պատասխանի ուղին և մուտքի կանոնը։ Այն հոսթանունը, որը վեբ սերվերը և վկայագիրը կարգավորված են սպասարկելու։ Երբ ավելի ուշ ինչ-որ բան կոտրվի, կոտրված տարրը այդ չորսից մեկն է, և դուք կիմանաք, թե որն եք փոխել։

Քայլ 1. ապահովեք, որ անունը ճիշտ լուծվի երկու խմբերի համար

Երկու խմբերն էլ պետք է ստանան մասնավոր պատասխան, որին իսկապես կարող են հասնել, և օրինաչափ է, որ պատասխանները տարբերվեն, քանի դեռ անունը չի տարբերվում։ LAN հաճախորդները լուծում են ներքին լուծիչի միջոցով. VPN հաճախորդներին անհրաժեշտ է լուծիչի քաղաքականություն, որը նրանց տալիս է նույն զոնան, փոխարենը հարցումը հանրային լուծիչ արտահոսելու և հանրային պատասխան ստանալու, որն իրենք չեն կարող օգտագործել։

Փորձարկեք անունը յուրաքանչյուր համատեքստից՝ ենթադրելու փոխարեն, և փորձարկեք ուղին DNS-ից անկախ curl-ի resolve ընտրանքով, որը հասցեն ամրացնում է մեկ հարցման համար:

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

Եթե առաջին փորձարկումը վերադարձնում է հասցե, որին հաճախորդը չի կարող հասնել, խնդիրը թունելի երթուղայնացման կամ բաժանված թունելի ցանկի մեջ է։ Եթե երկրորդ փորձարկումը վերադարձնում է վերահասցեավորում դեպի հոսթանուն, որը չէիք սպասում, կանգ առեք և կարդացեք Location վերնագիրը, քանի որ դա հավելվածի խնդիր է, և ոչ մի ուղու փոփոխություն այն չի շտկի։

Քայլ 2. հավասարեցրեք վեբ սերվերը, վկայագիրը և CMS-ի բազային URL-ը

Լսողը պետք է կարգավորված լինի սպասարկելու կանոնական անունը, և վկայագիրը պետք է ծածկի այն։ Հում հասցեով զննարկումը լուծում չէ. այն առաջացնում է անվան անհամապատասխանություն, կարող է կոտրել cookie-ների շրջանակը և օգտատերերին սովորեցնում է անցնել նախազգուշացումների միջով, որոնք հետագայում ստիպված կլինեք բացատրել աուդիտորին։

Հակադարձ պրոքսիի հետևում համոզվեք, որ հավելվածը գիտի՝ հարցումը եկել է HTTPS-ով։ CMS հարթակների մեծ մասը բացարձակ հղումներ է գեներացնում հայտնաբերված սխեմայից, և պրոքսին, որը դադարեցնում է TLS-ը առանց սկզբնական սխեման փոխանցելու, ստեղծում է էջ՝ լի http:// ռեսուրսներով, որոնք զննարկիչը կարող է արգելափակել։ Կարգավորեք վստահելի պրոքսին և փոխանցվող վերնագրերը բացահայտորեն, փոխարենը թույլ տալու հավելվածին գուշակել։

Այնուհետև հավասարեցրեք CMS-ի և CiviCRM-ի բազային URL-ը։ CiviCRM-ը պահպանում է իր որոշված բազային URL-ը և առաջարկում է աջակցվող ձև՝ այն վերահաշվարկելու համար. Cleanup Caches and Update Paths ադմինիստրատիվ գործողությունը, որը փաստագրված է CiviCRM-ի տեղադրման խնդիրների լուծման ուղեցույցում։ Գործարկեք այն այն բանից հետո, երբ կանոնական անունը և CMS-ի կարգավորումը համընկնեն, ոչ դրանից առաջ, այլապես պարզապես քեշեք մի արժեք, որը պատրաստվում եք փոխել։

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

Քայլ 3. ստուգեք այն հասցեները, որոնք գեներացնում է CiviCRM-ը

Գլխավոր էջին հասնելը շատ քիչ բան է ապացուցում։ CiviCRM-ը աշխատում է CMS-ի ներսում, և կարևոր են այն էջերը, որոնք իրենք են կառուցում իրենց URL-երը. մուտքի վերահասցեավորումը, ադմինիստրացիայի ընտրացանկը, ընդլայնումների ռեսուրսները, վերբեռնված ֆայլերի հղումները և ինտեգրացիայի կողմից գրանցված ցանկացած արտաքին հետադարձ կանչ։

Բեռնեք վահանակը, բացեք կոնտակտի գրառում և դիտեք էջի սկզբնաղբյուրը՝ բացարձակ հղումների համար։ Եթե դրանք ցույց են տալիս հոսթանվան, որին կարող է հասնել միայն մեկ հաճախորդ խումբ, ապա բազային URL-ը դեռ սխալ է, թեև էջը ցուցադրվել է։ Եթե դրանք ցույց են տալիս ճիշտ անվան, բայց սխալ սխեմային, պրոքսիի կարգավորումն է, որ պետք է ուղղել։

Երբ հասցեն իսկապես պետք է փոխվի, դիտարկեք դա որպես հավելվածի միգրացիա, ոչ որպես DNS-ի խմբագրում։ Վերանայեք ռեսուրսների URL-ները, քեշերը, հրապարակված հղումները և յուրաքանչյուր արտաքին ինտեգրացիա, որը պահպանում է հին հասցեն, ապա թարմացրեք դրանք մեկ պատուհանում, որպեսզի ոչ ոքի մոտ կիսով չափ միգրացված էջանիշ չմնա։

Հարցման հոսթանունը վստահության որոշում չէ

Մի ընտրեք արտոնյալ բազային URL միայն այն պատճառով, որ հարցման վերնագիրը պարունակում է որոշակի տող։ PHP-ն փաստագրում է Apache-ի կոնֆիգուրացիաներ, որտեղ սերվերի անվան արժեքը կարող է արտացոլել հաճախորդի տրամադրած հոսթը, իսկ սերվերի հասցեի փոփոխականը նկարագրում է սերվերը, ոչ այցելուի գտնվելու վայրը։ Դրանցից ոչ մեկը մուտքի վերահսկման մեխանիզմ չէ, և դրանցից մեկը կառուցելը այն ճանապարհն է, որով մասնավոր ծառայությունը վերջում սխալ բովանդակություն է մատուցում սխալ հոսթին։

Եթե իսկապես պահանջվում են մի քանի հոսթանուններ, սահմանեք բացահայտ թույլատրված ցանկ վեբ սերվերում, CMS-ում և հավելվածի շերտում, և թույլ տվեք հարցման հոսթանվանը ընտրել միայն հաստատված գրառումներից։ Կամայական մուտքը երբեք չպետք է դառնա բացարձակ հղումների աղբյուր կամ վստահելի վերահասցեավորման նպատակակետ։

Ավարտեք նույն էջանիշով յուրաքանչյուր հաստատված համատեքստում. մուտք, սովորական ներքին նավիգացիա և մեկ ռեսուրսի հարցում։ Համեմատեք պատասխանների հոսթանունները, ոչ միայն այն, թե արդյոք էջը բեռնվել է։ Երեք հարցման այս ստուգումը առանձնացնում է ուղու խնդիրը հավելվածից, որը դեռ սխալ հասցե է գեներացնում, և տևում է մոտ մեկ րոպե յուրաքանչյուր հաճախորդ խմբի համար։