Unu CiviCRM-adreso por oficejaj kaj VPN-uzantoj: agordaj paŝoj

Oficeja tekokomputilo devus malfermi la saman CiviCRM-legosignon ĉe sia skribotablo kaj denove hejme tra la VPN. La dezajno, kiu postvivas kontakton kun uzantoj, estas unu kanonika adreso, ekzemple https://crm.example.org/, kun aprobita retvojo el ĉiu loko kaj atestilo valida por tiu nomo. La VPN ŝanĝas kiel fora kliento atingas la servilon. Ĝi neniam devus ŝanĝi la identecon de la aplikaĵo, ĉar en la momento, kiam ĝi faras tion, ĉiu generita ligilo, alidirektado kaj integriĝa revokado fariĝas dua problemo solvenda.

Elektu la URL antaŭ ol elekti la itineron

Unue skribu la celatan adreson, inkluzive de ajna vojparto, kiun la CMS bezonas, kaj traktu ĝin kiel la fiksan punkton. Ĉio alia en ĉi tiu manlibro estas efektiviga detalo, kiu povas ŝanĝiĝi sen tuŝi ĝin: kiun DNS-respondon ricevas ĉiu grupo, kiu fajroŝirma regulo permesas la aŭskultanton, kaj ĉu la trafiko alvenas tra tunelo aŭ tra loka ŝaltila pordo.

Notu kvar valorojn kune en la alirplano, ĉar ili funkcias nur kiel aro. La kanonika URL. La respondo, kiun ĉiu klientgrupo devus ricevi por tiu nomo. La itinero kaj alirregulo por tiu respondo. La gastignomo, kiun la retservilo kaj atestilo estas agorditaj servi. Kiam io rompiĝos poste, la rompita elemento estos unu el tiuj kvar, kaj vi scios, kiun vi ŝanĝis.

Paŝo 1: certigu, ke la nomo solviĝas ĝuste por ambaŭ grupoj

Ambaŭ grupoj devus ricevi privatan respondon, kiun ili povas efektive atingi, kaj estas legitime, ke la respondoj malsimilu, kondiĉe ke la nomo ne malsimilu. LAN-klientoj solvas per la interna solvilo; VPN-klientoj bezonas solvilan politikon, kiu donas al ili la saman zonon anstataŭ liki la konsulton al publika solvilo kaj ricevi publikan respondon, kiun ili ne povas uzi.

Testu la nomon el ĉiu kunteksto anstataŭ supozi, kaj testu la vojon sendepende de DNS per la resolve-opcio de curl, kiu fiksas la adreson por unu peto:

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

Se la unua testo redonas adreson, kiun la kliento ne povas atingi, la problemo estas la tunela enkursigado aŭ la listo de dividita tunelo. Se la dua testo redonas alidirektadon al gastignomo, kiun vi ne atendis, haltu kaj legu la Location-kapon, ĉar tio estas aplikaĵa problemo kaj neniu itinera ŝanĝo riparos ĝin.

Paŝo 2: vicigu la retservilon, atestilon kaj CMS-bazan URL

La aŭskultanto devas esti agordita por servi la kanonikan nomon, kaj la atestilo devas kovri ĝin. Retumado per la kruda adreso ne estas solvo: ĝi produktas nommiskongruon, povas rompi la kuketan amplekson, kaj instruas al uzantoj klaki tra avertoj, kiujn vi poste devos klarigi al revizoro.

Malantaŭ inversa prokura servilo certigu, ke la aplikaĵo scias, ke la peto alvenis per HTTPS. Plej multaj CMS-platformoj generas absolutajn ligilojn el la detektita skemo, kaj prokura servilo, kiu finas TLS sen plusendi la originan skemon, produktas paĝon plenan de http://-risurcoj, kiujn la retumilo povas bloki. Agordu la fidatajn prokuran servilon kaj plusenditajn kapojn eksplicite anstataŭ lasi la aplikaĵon diveni.

Poste vicigu la bazan URL de CMS kaj CiviCRM. CiviCRM konservas sian difinitan bazan URL kaj proponas subtenatan manieron rekalkuli ĝin: la administra ago Cleanup Caches and Update Paths, dokumentita en la gvidilo pri problemoj pri CiviCRM-instalado. Rulu ĝin post kiam la kanonika nomo kaj la CMS-agordo kongruas, ne antaŭe, alie vi simple kaŝmemoros valoron, kiun vi baldaŭ ŝanĝos.

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

Paŝo 3: kontrolu la adresojn, kiujn CiviCRM generas

Atingi la ĉefpaĝon pruvas tre malmulte. CiviCRM funkcias ene de CMS, kaj la paĝoj, kiuj gravas, estas tiuj, kiuj konstruas proprajn URL-ojn: la ensaluta alidirektado, la administra menuo, etendaĵaj risurcoj, ligoj al alŝutitaj dosieroj kaj ajna ekstera revokado registrita de integriĝo.

Ŝargu la panelon, malfermu kontakton kaj rigardu la fonton de la paĝo por absolutaj ligiloj. Se ili montras al gastignomo, kiun nur unu klientgrupo povas atingi, la baza URL ankoraŭ malĝustas, kvankam la paĝo bildiĝis. Se ili montras al la ĝusta nomo sed la malĝusta skemo, la prokura agordo estas tio, kion oni devas ripari.

Kie la adreso vere devas ŝanĝiĝi, traktu ĝin kiel aplikaĵan migradon, ne kiel DNS-redakton. Revizuu risursajn URL-ojn, kaŝmemorojn, publikigitajn ligilojn kaj ĉiun eksteran integriĝon, kiu konservas la malnovan adreson, poste ĝisdatigu ilin en unu fenestro, por ke neniu tenu duonmigritan legosignon.

Petgastignomo ne estas fida decido

Ne elektu privilegian bazan URL ĉar petkapaĵo enhavas apartan ĉenon. PHP dokumentas Apache-agordojn, en kiuj la servilnoma valoro povas speguli gastignomon liveritan de la kliento, kaj la serviladresa variablo priskribas la servilon, ne la lokon de la vizitanto. Neniu el ili estas alirkontrola mekanismo, kaj konstrui unu el ili estas la maniero, kiel privata servo finas servante la malĝustan enhavon al la malĝusta gastignomo.

Se pluraj gastignomoj vere necesas, agordu eksplicitan permesliston ĉe la retservilo, la CMS kaj la aplikaĵa tavolo, kaj lasu la petgastignomon elekti nur inter aprobitaj eroj. Propravola enigo neniam devus fariĝi la fonto de absolutaj ligiloj aŭ fidata alidirektada celo.

Finu per la sama legosigno en ĉiu aprobita kunteksto: ensaluto, ordinara interna navigado kaj unu risurca peto. Komparu la gastignomojn en la respondoj, ne nur ĉu la paĝo ŝargiĝis. Tiu kontrolo de tri petoj apartigas vojproblemon de aplikaĵo, kiu ankoraŭ generas la malĝustan adreson, kaj ĝi daŭras proksimume unu minuton por klientgrupo.