Viens CiviCRM URL biroja un VPN lietotājiem: iestatīšanas soļi

Biroja klēpjdatoram ir jāatver tā pati CiviCRM grāmatzīme gan pie galda, gan mājās caur VPN. Risinājums, kas iztur saskari ar lietotājiem, ir viena kanoniskā adrese, piemēram, https://crm.example.org/, ar apstiprinātu tīkla ceļu no katras vietas un sertifikātu, kas derīgs šim nosaukumam. VPN maina to, kā attālinātais klients sasniedz serveri. Tam nekad nevajadzētu mainīt lietotnes identitāti, jo brīdī, kad tas notiek, katra ģenerētā saite, novirzīšana un integrācijas atzvanīšana kļūst par otru problēmu, kas jārisina.

Izvēlieties URL pirms maršruta izvēles

Vispirms pierakstiet paredzēto adresi, ieskaitot jebkuru ceļa komponentu, kas nepieciešams CMS, un uzskatiet to par fiksēto punktu. Viss pārējais šajā rokasgrāmatā ir ieviešanas detaļa, ko var mainīt, to neaiztiekot: kādu DNS atbildi saņem katra grupa, kurš ugunsmūra noteikums ļauj klausītājam un vai trafiks ierodas pa tuneli vai pa vietējo komutatora portu.

Ierakstiet četras vērtības kopā piekļuves plānā, jo tās darbojas tikai kā kopums. Kanoniskais URL. Atbilde, kas katrai klientu grupai jāsaņem par šo nosaukumu. Maršruts un piekļuves noteikums šai atbildei. Hosts, ko ir konfigurēts apkalpot tīmekļa serveris un sertifikāts. Kad vēlāk kaut kas salūzt, salūzušais elements ir viens no šiem četriem, un jūs zināsiet, kuru mainījāt.

1. solis: panāciet, ka nosaukums abām grupām tiek atrisināts pareizi

Abām grupām jāsaņem privāta atbilde, kuru tās patiešām var sasniegt, un ir pilnīgi pieņemami, ka atbildes atšķiras, ja vien nosaukums neatšķiras. LAN klienti atrisina caur iekšējo resolveri; VPN klientiem nepieciešama resolvera politika, kas dod viņiem to pašu zonu, nevis noplūdina vaicājumu publiskā resolverī un saņem publisku atbildi, ko viņi nevar izmantot.

Pārbaudiet nosaukumu katrā kontekstā, nevis pieņemiet, un pārbaudiet ceļu neatkarīgi no DNS, izmantojot curl resolve opciju, kas piesprauž adresi vienam pieprasījumam:

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

Ja pirmais tests atgriež adresi, kuru klients nevar sasniegt, problēma ir tuneļa maršrutēšana vai sadalītā tuneļa saraksts. Ja otrais tests atgriež novirzīšanu uz hostu, kuru negaidījāt, apstājieties un izlasiet Location galveni, jo tā ir lietotnes problēma un nekāda maršruta maiņa to neizlabos.

2. solis: saskaņojiet tīmekļa serveri, sertifikātu un CMS bāzes URL

Klausītājam jābūt konfigurētam apkalpot kanonisko nosaukumu, un sertifikātam tas jāaptver. Pārlūkošana pēc neapstrādātas adreses nav risinājums: tā rada nosaukuma neatbilstību, var sabojāt sīkfailu tvērumu un māca lietotājiem noklikšķināt cauri brīdinājumiem, kas vēlāk jums būs jāpaskaidro auditoram.

Aiz reversā starpniekservera pārliecinieties, ka lietotne zina, ka pieprasījums ieradās pa HTTPS. Lielākā daļa CMS platformu ģenerē absolūtās saites no noteiktās shēmas, un starpniekserveris, kas pārtrauc TLS, nepārsūtot sākotnējo shēmu, rada lapu ar daudziem http:// resursiem, ko pārlūks var bloķēt. Skaidri konfigurējiet uzticamo starpniekserveri un pārsūtītās galvenes, nevis ļaujiet lietotnei minēt.

Pēc tam saskaņojiet CMS un CiviCRM bāzes URL. CiviCRM saglabā noteikto bāzes URL un piedāvā atbalstītu veidu, kā to pārrēķināt: administratīvo darbību „Notīrīt kešatmiņas un atjaunināt ceļus”, kas dokumentēta CiviCRM instalēšanas problēmu novēršanas rokasgrāmatā. Palaidiet to pēc tam, kad kanoniskais nosaukums un CMS iestatījums sakrīt, nevis pirms tam, citādi jūs vienkārši saglabāsit kešatmiņā vērtību, kuru tūlīt mainīsit.

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

3. solis: pārbaudiet adreses, ko ģenerē CiviCRM

Sasniegt sākumlapu pierāda ļoti maz. CiviCRM darbojas CMS iekšienē, un svarīgākās lapas ir tās, kas veido savus URL: pieteikšanās novirzīšana, administrēšanas izvēlne, paplašinājumu resursi, augšupielādēto failu saites un jebkurš ārējs atzvanīšanas pieprasījums, ko reģistrējusi integrācija.

Ielādējiet informācijas paneli, atveriet kontakta ierakstu un apskatiet lapas avotu, meklējot absolūtās saites. Ja tās norāda uz hostu, kuru var sasniegt tikai viena klientu grupa, bāzes URL joprojām ir nepareizs, lai gan lapa tika parādīta. Ja tās norāda uz pareizo nosaukumu, bet nepareizo shēmu, labojama ir starpniekservera konfigurācija.

Kur adrese patiešām ir jāmaina, uztveriet to kā lietotnes migrāciju, nevis DNS rediģēšanu. Pārskatiet resursu URL, kešatmiņas, publicētās saites un katru ārējo integrāciju, kas glabā veco adresi, pēc tam atjauniniet tās vienā logā, lai nevienam nepaliktu daļēji migrēta grāmatzīme.

Pieprasījuma hosta nosaukums nav uzticēšanās lēmums

Neizvēlieties privileģētu bāzes URL tikai tāpēc, ka pieprasījuma galvenē ir noteikta rakstzīmju virkne. PHP dokumentē Apache konfigurācijas, kurās servera nosaukuma vērtība var atspoguļot klienta nodrošinātu hostu, un servera adreses mainīgais apraksta serveri, nevis apmeklētāja atrašanās vietu. Neviens no tiem nav piekļuves kontroles mehānisms, un viena no tiem būvēšana ir ceļš, kā privāts pakalpojums sāk apkalpot nepareizu saturu nepareizam hostam.

Ja patiešām ir nepieciešami vairāki hosta nosaukumi, konfigurējiet skaidru atļauto sarakstu tīmekļa serverī, CMS un lietotnes slānī, un ļaujiet pieprasījuma hosta nosaukumam izvēlēties tikai starp apstiprinātajiem ierakstiem. Patvaļīgai ievadei nekad nevajadzētu kļūt par absolūto saišu vai uzticama novirzīšanas mērķa avotu.

Pabeidziet ar to pašu grāmatzīmi katrā apstiprinātajā kontekstā: pieteikšanās, parasta iekšējā navigācija un viens resursa pieprasījums. Salīdziniet atbildēs esošos hosta nosaukumus, nevis tikai to, vai lapa ielādējās. Šī trīs pieprasījumu pārbaude atdala ceļa problēmu no lietotnes, kas joprojām ģenerē nepareizo adresi, un aizņem apmēram minūti vienai klientu grupai.