Një URL CiviCRM për përdoruesit e zyrës dhe VPN: hapat e konfigurimit

Një laptop zyre duhet të hapë të njëjtën faqerojtës CiviCRM në tavolinë dhe përsëri nga shtëpia përmes VPN. Dizajni që i bën ballë kontaktit me përdoruesit është një adresë kanonike, të themi https://crm.example.org/, me një rrugë rrjeti të miratuar nga çdo vendndodhje dhe një certifikatë të vlefshme për atë emër. VPN ndryshon mënyrën se si një klient në distancë arrin serverin. Nuk duhet të ndryshojë kurrë identitetin e aplikacionit, sepse në momentin që e bën, çdo lidhje e gjeneruar, ridrejtim dhe kthim thirrjeje integrimi bëhet një problem i dytë për t'u zgjidhur.

Zgjidhni URL-në përpara se të zgjidhni rrugën

Fillimisht shkruani adresën e synuar, duke përfshirë çdo komponentë të rrugës që CMS kërkon, dhe trajtojeni si pikë fikse. Çdo gjë tjetër në këtë manual është një detaj zbatimi që mund të ndryshojë pa e prekur atë: cila përgjigje DNS merr secili grup, cili rregull muri zjarri lejon dëgjuesin dhe nëse trafiku vjen përmes një tuneli apo përmes një porte lokale komutatori.

Regjistroni katër vlera së bashku në planin e aksesit, sepse funksionojnë vetëm si një grup. URL-ja kanonike. Përgjigja që duhet të marrë secili grup klientësh për atë emër. Rruga dhe rregulli i aksesit për atë përgjigje. Emri i hostit që serveri web dhe certifikata janë konfiguruar të shërbejnë. Kur diçka prishet më vonë, elementi i prishur është një nga ata katër dhe do ta dini cilin keni ndryshuar.

Hapi 1: bëni që emri të zgjidhet saktë për të dy grupet

Të dy grupet duhet të marrin një përgjigje private që mund ta arrijnë vërtet, dhe është e ligjshme që përgjigjet të ndryshojnë për sa kohë emri nuk ndryshon. Klientët LAN zgjidhin përmes zgjidhësit të brendshëm; klientët VPN kanë nevojë për një politikë zgjidhësi që u jep të njëjtën zonë në vend që ta rrjedhë pyetjen te një zgjidhës publik dhe të marrë një përgjigje publike që nuk mund ta përdorin.

Testoni emrin nga çdo kontekst në vend që të supozoni, dhe testoni rrugën në mënyrë të pavarur nga DNS me opsionin resolve të curl, që e fikson adresën për një kërkesë:

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

Nëse testi i parë kthen një adresë që klienti nuk mund ta arrijë, problemi është rrugëtimi i tunelit ose lista e split-tunnel. Nëse testi i dytë kthen një ridrejtim drejt një emri hosti që nuk e prisnit, ndaloni dhe lexoni kokën Location, sepse ky është një problem i aplikacionit dhe asnjë ndryshim rruge nuk e rregullon.

Hapi 2: rreshtoni serverin web, certifikatën dhe URL-në bazë të CMS

Dëgjuesi duhet të jetë i konfiguruar të shërbejë emrin kanonik, dhe certifikata duhet ta mbulojë. Shfletimi sipas adresës së papërpunuar nuk është zgjidhje: prodhon mospërputhje emri, mund të prishë shtrirjen e cookies dhe i mëson përdoruesit të klikojnë përmes paralajmërimeve që më vonë do t'ju duhet t'i shpjegoni një audituesi.

Pas një proxy të kundërt, sigurohuni që aplikacioni e di se kërkesa erdhi përmes HTTPS. Shumica e platformave CMS gjenerojnë lidhje absolute nga skema e zbuluar, dhe një proxy që e përfundon TLS pa e përcjellë skemën origjinale prodhon një faqe plot me http:// burime që shfletuesi mund t'i bllokojë. Konfiguroni në mënyrë eksplicite proxin e besuar dhe kokët e përcjella, në vend që ta lini aplikacionin të hamendësojë.

Më pas rreshtoni URL-në bazë të CMS dhe CiviCRM. CiviCRM mban URL-në bazë të përcaktuar dhe ofron një mënyrë të mbështetur për ta rillogaritur: veprimin administrativ Pastro cache-t dhe përditëso shtigjet, të dokumentuar në udhëzuesin e zgjidhjes së problemeve të instalimit të CiviCRM. Ekzekutojeni pasi emri kanonik dhe konfigurimi i CMS të përputhen, jo përpara, përndryshe thjesht do të ruani në cache një vlerë që jeni gati ta ndryshoni.

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

Hapi 3: kontrolloni adresat që gjeneron CiviCRM

Arritja e faqes kryesore provon shumë pak. CiviCRM ekzekutohet brenda një CMS, dhe faqet që kanë rëndësi janë ato që ndërtojnë URL-të e tyre: ridrejtimi i hyrjes, menyja e administrimit, burimet e shtojcave, lidhjet e skedarëve të ngarkuar dhe çdo kthim thirrjeje të jashtme që regjistron një integrim.

Ngarkoni panelin, hapni një regjistrim kontakti dhe shikoni burimin e faqes për lidhje absolute. Nëse ato tregojnë një emër hosti që vetëm një grup klientësh mund ta arrijë, URL-ja bazë është ende e gabuar edhe pse faqja u shfaq. Nëse tregojnë emrin e saktë por skemën e gabuar, konfigurimi i proxit është ai që duhet rregulluar.

Aty ku adresa vërtet duhet të ndryshojë, trajtojeni si një migrim aplikacioni dhe jo si një redaktim DNS. Rishikoni URL-të e burimeve, cache-t, lidhjet e publikuara dhe çdo integrim të jashtëm që ruan adresën e vjetër, pastaj përditësojini në një dritare të vetme që askush të mos mbetet me një faqerojtës gjysmë të migruar.

Emri i hostit në një kërkesë nuk është një vendim besimi

Mos zgjidhni një URL bazë të privilegjuar vetëm sepse një kokë e kërkesës përmban një varg të caktuar. PHP dokumenton konfigurime Apache në të cilat vlera e emrit të serverit mund të pasqyrojë një host të furnizuar nga klienti, dhe ndryshorja e adresës së serverit përshkruan serverin, jo vendndodhjen e vizitorit. Asnjëra prej tyre nuk është mekanizëm kontrolli aksesi, dhe ndërtimi i njërit prej tyre është mënyra se si një shërbim privat përfundon duke i shërbyer përmbajtjen e gabuar hostit të gabuar.

Nëse vërtet kërkohen disa emra hostesh, konfiguroni një listë lejimi të qartë në serverin web, në CMS dhe në shtresën e aplikacionit, dhe lëreni emrin e hostit të kërkesës të zgjedhë vetëm midis hyrjeve të miratuara. Inputi arbitrar nuk duhet të bëhet kurrë burimi i lidhjeve absolute ose destinacion i besuar ridrejtimi.

Përfundoni me të njëjtin faqerojtës në çdo kontekst të miratuar: një hyrje, një navigim normal i brendshëm dhe një kërkesë burimi. Krahasoni emrat e hosteve në përgjigje, jo vetëm nëse faqja u ngarkua. Ai test me tre kërkesa e ndan një problem rruge nga një aplikacion që ende gjeneron adresën e gabuar, dhe zgjat rreth një minutë për grup klientësh.