URL moja ya CiviCRM kwa watumiaji wa ofisi na VPN: hatua za usanidi

Kompyuta ya mkononi ya ofisi inapaswa kufungua alama sawa ya CiviCRM kwenye dawati lake na tena kutoka nyumbani kupitia VPN. Muundo unaostahimili mwingiliano na watumiaji ni anwani moja ya kawaida, tuseme https://crm.example.org/, ukiwa na njia ya mtandao iliyoidhinishwa kutoka kila eneo, na cheti halali kwa jina hilo. VPN hubadilisha jinsi mteja wa mbali anavyofikia seva. Haipaswi kamwe kubadilisha utambulisho wa programu, kwa sababu wakati inapofanya hivyo, kila kiungo kilichotengenezwa, uelekezaji upya na mwito wa kurudi wa muunganisho huwa tatizo la pili la kutatua.

Chagua URL kabla ya kuchagua njia

Kwanza andika anwani inayokusudiwa, ikiwa ni pamoja na sehemu yoyote ya njia ambayo CMS inahitaji, na uichukulie kama sehemu isiyobadilika. Kila kitu kingine katika mwongozo huu ni maelezo ya utekelezaji yanayoweza kubadilika bila kuigusa: jibu la DNS ambalo kila kikundi hupokea, kanuni ya firewall inayomruhusu msikilizaji, na ikiwa trafiki hufika kupitia handaki au kupitia bandari ya swichi ya ndani.

Rekodi thamani nne pamoja katika mpango wa ufikiaji, kwa sababu hufanya kazi tu kama seti moja. URL ya kawaida. Jibu ambalo kila kikundi cha wateja linapaswa kupokea kwa jina hilo. Njia na kanuni ya ufikiaji ya jibu hilo. Jina la mwenyeji ambalo seva ya wavuti na cheti vimeundwa kuhudumia. Kitu kikiharibika baadaye, kipengele kilichoharibika ni kimoja cha hizo nne, na utajua ni kipi ulichobadilisha.

Hatua ya 1: hakikisha jina linatatuliwa kwa usahihi kwa vikundi vyote viwili

Vikundi vyote viwili vinapaswa kupokea jibu la faragha ambalo wanaweza kufikia kweli, na ni halali majibu kutofautiana mradi jina halitofautiani. Wateja wa LAN hutatua kupitia kitatuzi cha ndani; wateja wa VPN wanahitaji sera ya kitatuzi inayowapa eneo lile lile badala ya kuvujisha swali kwa kitatuzi cha umma na kupata jibu la umma wasiloweza kutumia.

Jaribu jina kutoka kwa kila mazingira badala ya kudhani, na jaribu njia bila kutegemea DNS kwa chaguo la resolve la curl, ambalo hubandika anwani kwa ombi moja:

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

Ikiwa jaribio la kwanza linarudisha anwani ambayo mteja hawezi kuifikia, tatizo ni uelekezaji wa handaki au orodha ya split-tunnel. Ikiwa jaribio la pili linarudisha uelekezaji upya kwa jina la mwenyeji usilokutarajia, simama na usome kichwa cha Location, kwa sababu hilo ni tatizo la programu na hakuna mabadiliko ya njia yatakayolirekebisha.

Hatua ya 2: oanisha seva ya wavuti, cheti na URL ya msingi ya CMS

Msikilizaji lazima awe ameundwa kuhudumia jina la kawaida, na cheti lazima lifunike. Kuvinjari kwa anwani mbichi si suluhisho: huzalisha kutofautiana kwa jina, kunaweza kuvunja wigo wa vidakuzi, na huwafundisha watumiaji kubofya kupitia maonyo ambayo baadaye utalazimika kueleza kwa mkaguzi.

Nyuma ya proksi ya kinyume, hakikisha programu inajua ombi lilifika kwa HTTPS. Majukwaa mengi ya CMS huzalisha viungo kamili kutoka kwa mpango uliogunduliwa, na proksi inayomaliza TLS bila kupeleka mpango asili huzalisha ukurasa uliojaa http:// rasilimali ambazo kivinjari kinaweza kuzuia. Sanidi proksi inayoaminika na vichwa vilivyopelekwa kwa uwazi badala ya kuiacha programu ikisie.

Kisha oanisha URL ya msingi ya CMS na CiviCRM. CiviCRM huhifadhi URL yake ya msingi iliyoamuliwa na hutoa njia inayotumika kuhesabu upya: kitendo cha usimamizi Safisha akiba na sasisha njia, kilichoandikwa katika mwongozo wa utatuzi wa matatizo ya usanidi wa CiviCRM. Iendeshe baada ya jina la kawaida na mpangilio wa CMS kukubaliana, si kabla, vinginevyo utahifadhi kwenye akiba thamani ambayo uko karibu kuibadilisha.

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

Hatua ya 3: angalia anwani ambazo CiviCRM huzalisha

Kufikia ukurasa wa mbele kunathibitisha kidogo sana. CiviCRM huendeshwa ndani ya CMS, na kurasa muhimu ni zile zinazojenga URL zao wenyewe: uelekezaji upya wa kuingia, menyu ya usimamizi, rasilimali za viendelezi, viungo vya faili zilizopakiwa na mwito wowote wa nje wa kurudi uliosajiliwa na muunganisho.

Pakia dashibodi, fungua rekodi ya mwasiliani, na uangalie chanzo cha ukurasa kwa viungo kamili. Ikiwa vinaelekeza kwa jina la mwenyeji ambalo kikundi kimoja tu cha wateja kinaweza kufikia, URL ya msingi bado si sahihi ingawa ukurasa ulionyeshwa. Ikiwa vinaelekeza kwa jina sahihi lakini mpango usio sahihi, usanidi wa proksi ndio unaopaswa kurekebishwa.

Mahali ambapo anwani kwa kweli inapaswa kubadilika, ichukulie kama uhamishaji wa programu na si uhariri wa DNS. Kagua URL za rasilimali, akiba, viungo vilivyochapishwa na kila muunganisho wa nje unaohifadhi anwani ya zamani, kisha visasishe katika dirisha moja ili mtu yeyote asibaki na alama iliyohamishwa nusu.

Jina la mwenyeji kwenye ombi si uamuzi wa uaminifu

Usichague URL ya msingi yenye upendeleo kwa sababu kichwa cha ombi kina mfuatano fulani. PHP huandika usanidi wa Apache ambapo thamani ya jina la seva inaweza kuakisi mwenyeji aliyetolewa na mteja, na kigezo cha anwani ya seva kinaelezea seva, si eneo la mgeni. Hakuna kimoja wapo kilicho utaratibu wa kudhibiti ufikiaji, na kujenga kimoja kutoka kwao ndio njia ambayo huduma ya faragha huishia kuhudumia maudhui yasiyofaa kwa mwenyeji asiye sahihi.

Ikiwa majina mengi ya wenyeji yanahitajika kwa kweli, sanidi orodha ya ruhusa iliyo wazi kwenye seva ya wavuti, CMS na safu ya programu, na uache jina la mwenyeji la ombi lichague tu kati ya maingizo yaliyoidhinishwa. Ingizo la kiholela kamwe linapaswa kuwa chanzo cha viungo kamili au lengo la uelekezaji upya linaloaminika.

Maliza na alama ile ile katika kila mazingira yaliyoidhinishwa: kuingia, urambazaji wa kawaida wa ndani na ombi moja la rasilimali. Linganisha majina ya wenyeji katika majibu, si tu ikiwa ukurasa ulipakiwa. Ukaguzi huo wa maombi matatu hutenganisha tatizo la njia na programu ambayo bado inazalisha anwani isiyo sahihi, na huchukua kama dakika moja kwa kila kikundi cha wateja.