Isang URL ng CiviCRM para sa mga gumagamit ng opisina at VPN: mga hakbang sa pag-setup

Ang laptop sa opisina ay dapat magbukas ng parehong bookmark ng CiviCRM sa mesa nito at muli mula sa bahay sa pamamagitan ng VPN. Ang disenyong nakakayanan ang pakikitungo sa mga gumagamit ay isang kanonikal na address, sabihin nating https://crm.example.org/, na may aprubadong landas ng network mula sa bawat lokasyon, at sertipiko na valid para sa pangalang iyon. Binabago ng VPN kung paano naaabot ng isang remote na kliyente ang server. Hindi nito dapat kailanman baguhin ang pagkakakilanlan ng application, dahil sa sandaling gawin nito, ang bawat nabuong link, redirect at integration callback ay nagiging pangalawang problemang dapat lutasin.

Piliin ang URL bago piliin ang ruta

Isulat muna ang nilalayong address, kasama ang anumang bahagi ng landas na kailangan ng CMS, at tratuhin ito bilang fixed point. Ang lahat ng iba pa sa runbook na ito ay detalye ng implementasyon na maaaring magbago nang hindi ito hinahawakan: kung anong sagot ng DNS ang natatanggap ng bawat grupo, kung aling tuntunin ng firewall ang pumapayag sa listener, at kung dumadating ang trapiko sa pamamagitan ng tunnel o ng lokal na port ng switch.

Itala ang apat na halaga nang magkasama sa plano ng access, dahil gumagana lamang ang mga ito bilang isang set. Ang kanonikal na URL. Ang sagot na dapat matanggap ng bawat grupo ng kliyente para sa pangalang iyon. Ang ruta at tuntunin ng access para sa sagot na iyon. Ang hostname na naka-configure na serbisyuhan ng web server at sertipiko. Kapag may nasira sa hinaharap, ang sirang elemento ay isa sa apat na iyon, at malalaman mo kung alin ang binago mo.

Hakbang 1: tiyakin na ang pangalan ay nalulutas nang tama para sa parehong grupo

Dapat makatanggap ang dalawang grupo ng pribadong sagot na talagang maaabot nila, at lehitimo na magkaiba ang mga sagot hangga't hindi nagkakaiba ang pangalan. Ang mga kliyente ng LAN ay naglulutas sa pamamagitan ng panloob na resolver; ang mga kliyente ng VPN ay nangangailangan ng patakaran ng resolver na nagbibigay sa kanila ng parehong zone sa halip na tumulo ang query sa isang pampublikong resolver at makakuha ng pampublikong sagot na hindi nila magagamit.

Subukan ang pangalan mula sa bawat konteksto sa halip na ipagpalagay, at subukan ang landas nang hiwalay sa DNS gamit ang resolve na opsyon ng curl, na nagpapako ng address para sa isang kahilingan:

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

Kung ang unang pagsubok ay nagbabalik ng address na hindi maabot ng kliyente, ang routing ng tunnel o ang listahan ng split-tunnel ang problema. Kung ang ikalawang pagsubok ay nagbabalik ng redirect sa isang hostname na hindi mo inaasahan, huminto at basahin ang header ng Location, dahil problema iyon ng application at walang pagbabago sa ruta ang makakapag-ayos nito.

Hakbang 2: ihanay ang web server, sertipiko at base na URL ng CMS

Ang listener ay dapat naka-configure na serbisyuhan ang kanonikal na pangalan, at dapat itong saklawin ng sertipiko. Ang pag-browse gamit ang hilaw na address ay hindi solusyon: nagdudulot ito ng hindi pagkakatugma ng pangalan, maaaring sirain ang saklaw ng cookie, at nagtuturo sa mga gumagamit na i-click ang mga babala na kakailanganin mong ipaliwanag sa isang auditor sa hinaharap.

Sa likod ng reverse proxy, tiyakin na alam ng application na dumating ang kahilingan sa HTTPS. Karamihan sa mga platform ng CMS ay bumubuo ng ganap na mga link mula sa natukoy na scheme, at ang proxy na nagtatapos ng TLS nang hindi ipinapasa ang orihinal na scheme ay bumubuo ng pahinang puno ng http:// mga resource na maaaring harangin ng browser. I-configure nang tahasan ang pinagkakatiwalaang proxy at mga naipasang header sa halip na hayaang maghula ang application.

Pagkatapos ay ihanay ang base na URL ng CMS at CiviCRM. Pinapanatili ng CiviCRM ang determinadong base na URL nito at nag-aalok ng sinusuportahang paraan upang muling kalkulahin ito: ang administratibong aksyong Linisin ang mga cache at I-update ang mga landas, na nakadokumento sa gabay sa pag-troubleshoot ng pag-install ng CiviCRM. Patakbuhin ito pagkatapos magkasundo ang kanonikal na pangalan at setting ng CMS, hindi bago, kung hindi ay i-cache mo lang ang halagang babaguhin mo.

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

Hakbang 3: suriin ang mga address na nabubuo ng CiviCRM

Ang maabot ang front page ay nagpapatunay ng napakaliit. Tumakbo ang CiviCRM sa loob ng isang CMS, at ang mahahalagang pahina ay ang mga bumubuo ng sarili nilang URL: ang redirect ng login, menu ng administrasyon, mga resource ng extension, mga link ng na-upload na file at anumang panlabas na callback na nakarehistro ng isang integration.

I-load ang dashboard, buksan ang isang talaan ng contact, at tingnan ang source ng pahina para sa ganap na mga link. Kung tumuturo ang mga ito sa isang hostname na isang grupo lamang ng kliyente ang makakaabot, mali pa rin ang base na URL kahit na na-render ang pahina. Kung tumuturo ang mga ito sa tamang pangalan ngunit maling scheme, ang configuration ng proxy ang dapat ayusin.

Kung saan talagang kailangang magbago ang address, tratuhin ito bilang migrasyon ng application at hindi bilang pag-edit ng DNS. Repasuhin ang mga URL ng resource, cache, nailathalang link at bawat panlabas na integration na nag-iimbak ng lumang address, pagkatapos ay i-update ang mga ito sa isang window upang walang maiwang may kalahating migradong bookmark.

Ang hostname ng kahilingan ay hindi desisyon ng pagtitiwala

Huwag pumili ng privileged na base na URL dahil lang may partikular na string sa header ng kahilingan. Idinodokumento ng PHP ang mga configuration ng Apache kung saan ang halaga ng server-name ay maaaring sumalamin sa host na ibinigay ng kliyente, at inilalarawan ng variable ng server address ang server, hindi ang lokasyon ng bisita. Wala sa mga ito ang mekanismo ng access control, at ang pagbuo ng isa mula sa mga ito ay kung paano nagtatapos ang isang pribadong serbisyo sa pagseserbisyo ng maling nilalaman sa maling host.

Kung talagang kailangan ang maraming hostname, i-configure ang tahasang allowlist sa web server, sa CMS at sa layer ng application, at hayaang pumili ang hostname ng kahilingan lamang sa mga aprubadong entry. Ang arbitraryong input ay hindi dapat kailanman maging pinagmulan ng ganap na mga link o pinagkakatiwalaang destinasyon ng redirect.

Tapusin gamit ang parehong bookmark sa bawat aprubadong konteksto: isang login, isang ordinaryong panloob na nabigasyon at isang kahilingan ng resource. Ihambing ang mga hostname sa mga tugon, hindi lamang kung nag-load ang pahina. Ang pagsusuring iyon ng tatlong kahilingan ay naghihiwalay ng problema sa landas mula sa isang application na bumubuo pa rin ng maling address, at tumatagal ng mga isang minuto bawat grupo ng kliyente.