Eitt CiviCRM-slóð fyrir skrifstofu- og VPN-notendur: uppsetningarþrep

Fartölva á skrifstofu ætti að opna sama CiviCRM-bókamerki við skrifborðið og aftur heiman frá sér í gegnum VPN. Hönnunin sem lifir af kynni við notendur er ein kanonísk slóð, segjum https://crm.example.org/, með samþykkri netleið frá hverjum stað og skírteini sem gildir fyrir það nafn. VPN breytir því hvernig fjartengd biðlara nær í þjóninn. Það á aldrei að breyta sjálfsmynd forritsins, því á þeirri stundu sem það gerir það verður hver mynduð hlekkur, endurbeining og afturkall samþættingar annað vandamál til að leysa.

Veljið slóðina áður en þið veljið leiðina

Skrifið fyrst niður fyrirhugaða slóð, þar á meðal hvern þann slóðarhluta sem CMS þarf, og meðhöndlið hana sem fastan punkt. Allt annað í þessari handbók er útfærsluatriði sem getur breyst án þess að snerta hana: hvaða DNS-svar hver hópur fær, hvaða eldveggjarregla leyfir hlustandann og hvort umferðin kemur um göng eða um staðbundið rofaport.

Skráið fjögur gildi saman í aðgangsáætlunina, því þau virka aðeins sem mengi. Kanoníska slóðin. Svarið sem hver biðlarahópur á að fá fyrir það nafn. Leiðin og aðgangsreglan fyrir það svar. Hýsilnafnið sem vefþjónninn og skírteinið eru stillt til að þjónusta. Þegar eitthvað bilar síðar er bilaða atriðið eitt af þessum fjórum, og þið vitið hverju þið breyttuð.

Þrep 1: tryggið að nafnið leysist rétt fyrir báða hópa

Báðir hópar eiga að fá einkasvar sem þeir komast í raun og veru í, og það er lögmætt að svörin séu ólík svo framarlega sem nafnið er það ekki. LAN-biðlarar leysa í gegnum innri leysinn; VPN-biðlarar þurfa leysireglu sem gefur þeim sama svæðið í stað þess að leka fyrirspurninni til opinbers leysis og fá opinbert svar sem þeir geta ekki notað.

Prófið nafnið frá hverju samhengi í stað þess að gera ráð fyrir því, og prófið leiðina óháð DNS með resolve-valkosti curl, sem festir slóðina fyrir eina beiðni:

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

Ef fyrsta prófið skilar slóð sem biðlarinn kemst ekki í er vandamálið í leiðsögn ganganna eða listanum yfir klofin göng. Ef annað prófið skilar endurbeiningu á hýsilnafn sem þið áttuð ekki von á, stöðvið og lesið Location-hausinn, því þetta er vandamál í forritinu og engin leiðarbreyting lagar það.

Þrep 2: samræmið vefþjóninn, skírteinið og grunnslóð CMS

Hlustandinn verður að vera stilltur til að þjónusta kanoníska nafnið, og skírteinið verður að ná yfir það. Að vafra á hráu slóðinni er ekki leið fram hjá: það veldur nafnamismun, getur brotið umfang vafrakaka og kennir notendum að smella fram hjá viðvörunum sem þið þurfið síðar að útskýra fyrir endurskoðanda.

Fyrir aftan öfugt milliþjón, gangið úr skugga um að forritið viti að beiðnin kom um HTTPS. Flest CMS-kerfi mynda algjöra hlekki út frá greindu skemanu, og milliþjónn sem lýkur TLS án þess að senda upprunalega skemað áfram myndar síðu fulla af http://-auðlindum sem vafrinn gæti lokað á. Stillið trausta milliþjóninn og áframsendu hausana skýrt, í stað þess að láta forritið giska.

Samræmið síðan grunnslóð CMS og CiviCRM. CiviCRM heldur sínu ákvarðaða grunnslóð og býður upp á studda leið til að endurreikna hana: stjórnunaraðgerðina Cleanup Caches and Update Paths, sem er skjöluð í leiðbeiningum um úrræði við uppsetningu CiviCRM. Keyrið hana eftir að kanoníska nafnið og CMS-stillingin stemma, ekki fyrr, annars skyndiminnið þið bara gildi sem þið eruð að fara að breyta.

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

Þrep 3: athugið slóðirnar sem CiviCRM myndar

Að komast á forsíðuna sannar mjög litla hluti. CiviCRM keyrir inni í CMS, og síðurnar sem skipta máli eru þær sem byggja sínar eigin slóðir: innskráningar-endurbeiningin, stjórnunarvalmyndin, auðlindir viðbóta, hlekkir á upphlaðnar skrár og hvert það ytra afturkall sem samþætting skráir.

Hlaðið mælaborðinu, opnið tengiliðafærslu og skoðið frumkóða síðunnar eftir algjörum hlekkjum. Ef þeir benda á hýsilnafn sem aðeins einn biðlarahópur kemst í er grunnslóðin enn röng þótt síðan hafi birst. Ef þeir benda á rétta nafnið en rangt skema er það milliþjónsstillingin sem þarf að laga.

Þar sem slóðin verður í raun að breytast, meðhöndlið það sem flutning forrits en ekki DNS-breytingu. Farið yfir auðlindaslóðir, skyndiminni, birtar hlekki og hverja ytri samþættingu sem geymir gömlu slóðina, og uppfærið þau síðan í einum glugga svo enginn sitji með hálfflutta bókamerki.

Hýsilnafn beiðni er ekki traustsákvörðun

Veljið ekki sérréttindaslóð vegna þess að beiðnishaus inniheldur ákveðinn streng. PHP skjlar Apache-stillingum þar sem gildi þjónnafns getur endurspeglað hýsil sem biðlarinn leggur til, og breytan fyrir þjónslóð lýsir þjóninum, ekki stað gestgjafans. Hvort tveggja er ekki aðgangsstýringarferli, og að byggja eitt úr þeim er leiðin sem einkaréttarþjónusta endar á að þjónusta ranga efnið á rangan hýsil.

Ef sannarlega þarf margvísleg hýsilnöfn, stillið skýran leyfðan lista á vefþjóninum, í CMS og á forritslaginu, og látið hýsilnafn beiðninnar velja aðeins úr samþykktum færslum. Handahófskennd inntak ættu aldrei að verða uppspretta algjöra hlekkja eða traustur endurbeiningarstaður.

Ljúkið með sama bókamerki í hverju samþykktu samhengi: innskráning, venjuleg innri leiðsögn og ein auðlindabeiðni. Berið saman hýsilnöfnin í svörunum, ekki bara hvort síðan hlaðist. Þessi þriggja beiðna athugun aðgreinir leiðarvandamál frá forriti sem myndar enn röngu slóðina, og hún tekur um það bil mínútu á hvern biðlarahóp.