Оффис болон VPN хэрэглэгчдэд зориулсан нэг CiviCRM URL: тохируулах алхмууд

Оффисын зөөврийн компьютер ажлын ширээн дээр ч, гэртээ VPN-ээр ч ижил CiviCRM хавчуурыг нээх ёстой. Хэрэглэгчидтэй харьцахыг даван туулдаг загвар нь нэг каноник хаяг юм, жишээ нь https://crm.example.org/, бүс бүрээс зөвшөөрөгдсөн сүлжээний зам, тухайн нэрэнд хүчинтэй гэрчилгээтэй. VPN нь алсын клиент серверт хэрхэн хүрэхийг өөрчилдөг. Энэ нь аппын таних тэмдгийг хэзээ ч өөрчлөх ёсгүй, учир нь өөрчлөгдсөн тэр мөчид үүсгэсэн холбоос, дахин чиглүүлэлт, интеграцийн callback бүр шийдвэрлэх хоёр дахь асуудал болдог.

Маршрутаа сонгохоос өмнө URL-аа сонго

Зорьсон хаягаа эхлээд бич, CMS-д шаардлагатай замын бүрэлдэхүүнийг оруулаад, түүнийг тогтмол цэг гэж үз. Энэхүү гарын авлагад бусад бүх зүйл нь түүнд хүрэхгүйгээр өөрчлөгдөж болох хэрэгжүүлэлтийн дэлгэрэнгүй мэдээлэл юм: бүлэг бүр ямар DNS хариулт авдаг, аль галт хананы дүрэм сонсогчийг зөвшөөрдөг, мөн хөдөлгөөн туннелээр ирдэг эсэх эсвэл локал свитчийн портоор ирдэг эсэх.

Хандалтын төлөвлөгөөнд дөрвөн утгыг хамт бич, учир нь тэд зөвхөн багц хэлбэрээр ажилладаг. Каноник URL. Тухайн нэрэнд клиент бүлэг бүрийн авах ёстой хариулт. Тухайн хариултын маршрут ба хандалтын дүрэм. Веб сервер болон гэрчилгээ үйлчлэхээр тохируулсан хостын нэр. Дараа нь ямар нэгэн зүйл эвдэрвэл, эвдэрсэн элемент нь тэр дөрвийн нэг бөгөөд аль нэгийг нь өөрчилснөө мэдэх болно.

Алхам 1: хоёр бүлэгт нэр зөв шийдэгдэх боломжийг бүрдүүл

Хоёр бүлэг хоёулаа үнэхээр хүрч чадах хувийн хариулт авах ёстой бөгөөд нэр нь өөрчлөгдөхгүй л бол хариултууд ялгаатай байх нь хууль ёсны юм. LAN клиентүүд дотоод resolver-оор шийддэг; VPN клиентүүдэд ижил бүсийг өгдөг resolver бодлого хэрэгтэй, асуулгыг нийтийн resolver руу алдаж, ашиглах боломжгүй нийтийн хариулт авахын оронд.

Таамаглахын оронд контекст бүрээс нэрийг шалга, мөн curl-ийн resolve сонголтоор DNS-ээс хамааралгүйгээр замыг шалга, энэ нь нэг хүсэлтэд хаягийг бэхэлдэг:

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

Эхний шалгалт клиент хүрч чадахгүй хаяг буцаавал туннелийн маршрут эсвэл split-tunnel жагсаалт нь асуудал юм. Хоёр дахь шалгалт таны хүлээгээгүй хостын нэр рүү дахин чиглүүлэлт буцаавал зогсоод Location толгойг унш, учир нь энэ нь аппын асуудал бөгөөд ямар ч маршрутын өөрчлөлт үүнийг засахгүй.

Алхам 2: веб сервер, гэрчилгээ болон CMS суурь URL-ийг нийцүүл

Сонсогч нь каноник нэрийг үйлчлэхээр тохируулагдсан байх ёстой, гэрчилгээ нь түүнийг хамарсан байх ёстой. Түүхий хаягаар хөтлөх нь шийдэл биш: энэ нь нэрийн зөрүү үүсгэж, күүкийн хүрээг эвдэж болох бөгөөд хэрэглэгчдэд дараа нь аудиторт тайлбарлах шаардлагатай анхааруулгуудыг дарахыг заадаг.

Урвуу проксины ард апп нь хүсэлт HTTPS-ээр ирснийг мэдэж байгаа эсэхийг шалга. Ихэнх CMS платформууд илрүүлсэн схемээс үнэмлэхүй холбоос үүсгэдэг бөгөөд анхны схемийг дамжуулахгүйгээр TLS-ийг дуусгадаг прокси http:// нөөцөөр дүүрэн хуудас үүсгэдэг бөгөөд хөтөч тэдгээрийг хааж болно. Аппыг таамаглахыг зөвшөөрөхийн оронд итгэмжлэгдсэн прокси болон дамжуулсан толгойг тодорхой тохируул.

Дараа нь CMS болон CiviCRM суурь URL-ийг нийцүүл. CiviCRM тодорхойлсон суурь URL-ээ хадгалж, түүнийг дахин тооцоолох дэмжигдсэн аргыг санал болгодог: 'Кэшийг цэвэрлэж замыг шинэчилэх' административ үйлдэл, үүнийг тайлбарласан нь CiviCRM суулгацын алдаа засах гарын авлагад. Каноник нэр болон CMS тохиргоо нийцсэний дараа ажиллуул, өмнө нь биш, эсрэг тохиолдолд та өөрчлөх гэж буй утгыг кэшлэх болно.

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

Алхам 3: CiviCRM үүсгэдэг хаягуудыг шалга

Нүүр хуудсанд хүрэх нь маш бага зүйг баталдаг. CiviCRM нь CMS-ийн дотор ажилладаг бөгөөд чухал хуудсууд нь өөрийн URL-ийг бүтээдэг хуудсууд юм: нэвтрэх дахин чиглүүлэлт, админ цэс, өргөтгөлийн нөөц, байршуулсан файлын холбоос, интеграцийн бүртгэсэн аливаа гадаад callback.

Хяналтын самбарыг ачаалж, харилцагчийн бичлэг нээж, үнэмлэхүй холбоосын хувьд хуудасны эхийг хар. Хэрэв тэд зөвхөн нэг клиент бүлэг хүрч чадах хостын нэр рүү зааж байвал хуудас гарсан ч суурь URL буруу хэвээр байна. Хэрэв тэд зөв нэр рүү зааж байгаа ч буруу схем рүү зааж байвал прокси тохиргоог засах хэрэгтэй.

Хаяг үнэхээр өөрчлөгдөх ёстой газарт үүнийг DNS засвар гэж биш, аппын шилжилт гэж үз. Нөөцийн URL, кэш, нийтэлсэн холбоос, хуучин хаягийг хадгалдаг аливаа гадаад интеграцийг хянаж, дараа нь хэн ч хагас шилжсэн хавчуур барихгүйн тулд тэдгээрийг нэг цонхонд шинэчил.

Хүсэлтийн хостын нэр нь итгэлцлийн шийдвэр биш

Хүсэлтийн толгойд тодорхой тэмдэгт мөр агуулагддаг учраас онцгой эрхтэй суурь URL-ийг сонгож болохгүй. PHP нь server-name утга клиентээс ирсэн хостыг тусгаж болох Apache тохиргоог баримтжуулдаг бөгөөд server address хувьсагч нь серверийг дүрсэлдэг, зочны байршлыг биш. Эдгээрийн аль нь ч хандалтын хяналтын механизм биш бөгөөд тэдгээрээс нэгийг бүтээх нь хувийн үйлчилгээ буруу хосто буруу агуулга үйлчилдэг болох зам юм.

Хэрэв олон хостын нэр үнэхээр шаардлагатай бол веб сервер, CMS болон аппын түвшинд тодорхой зөвшөөрөгдсөн жагсаалт тохируулж, хүсэлтийн хостын нэр зөвхөн батлагдсан бичлэгүүдийн дундаас сонгогдох болтугай. Дурын оруулга хэзээ ч үнэмлэхүй холбоос эсвэл итгэмжлэгдсэн дахин чиглүүлэлтийн очих газрын эх сурвалж болох ёсгүй.

Батлагдсан контекст бүрт ижил хавчуураар дуусга: нэвтрэлт, энгийн дотоод навигаци, нэг нөөцийн хүсэлт. Хариултууд дахь хостын нэрсийг харьцуул, зөвхөн хуудас ачаалагдсан эсэхийг биш. Тэр гурван хүсэлтийн шалгалт нь замын асуудлыг буруу хаяг үүсгэсэн аппаас ялгаж, клиент бүлэг бүрт ойролцоогоор нэг минут зарцуулдаг.