Jeden adres URL CiviCRM dla użytkowników biura i VPN: kroki konfiguracji

Laptop biurowy powinien otwierać tę samą zakładkę CiviCRM przy biurku i ponownie z domu przez VPN. Projekt, który przetrwa kontakt z użytkownikami, to jeden kanoniczny adres, powiedzmy https://crm.example.org/, z zatwierdzoną ścieżką sieciową z każdej lokalizacji i certyfikatem ważnym dla tej nazwy. VPN zmienia sposób, w jaki zdalny klient dociera do serwera. Nigdy nie powinien zmieniać tożsamości aplikacji, bo w chwili, gdy to robi, każdy wygenerowany link, przekierowanie i wywołanie zwrotne integracji staje się drugim problemem do rozwiązania.

Wybierz adres URL, zanim wybierzesz trasę

Najpierw zapisz docelowy adres, w tym każdy komponent ścieżki potrzebny CMS-owi, i traktuj go jako punkt stały. Wszystko inne w tym runbooku to szczegół implementacji, który można zmienić bez dotykania go: jaką odpowiedź DNS otrzymuje każda grupa, która reguła zapory przepuszcza listener i czy ruch przychodzi przez tunel, czy przez lokalny port przełącznika.

Zapisz cztery wartości razem w planie dostępu, bo działają tylko jako zestaw. Kanoniczny adres URL. Odpowiedź, którą każda grupa klientów powinna otrzymać dla tej nazwy. Trasa i reguła dostępu dla tej odpowiedzi. Nazwa hosta, którą mają obsługiwać serwer WWW i certyfikat. Gdy coś później się zepsuje, zepsutym elementem jest jeden z tych czterech i będziesz wiedzieć, który zmieniłeś.

Krok 1: spraw, by nazwa rozwiązywała się poprawnie dla obu grup

Obie grupy powinny otrzymać prywatną odpowiedź, do której naprawdę mogą dotrzeć, i legalne jest, by odpowiedzi się różniły, dopóki nazwa się nie różni. Klienci LAN rozwiązują przez wewnętrzny resolver; klienci VPN potrzebują polityki resolvera, która daje im tę samą strefę, zamiast wyciekać zapytanie do publicznego resolvera i dostawać publiczną odpowiedź, której nie mogą użyć.

Testuj nazwę z każdego kontekstu, zamiast zakładać, i testuj ścieżkę niezależnie od DNS za pomocą opcji resolve curl, która przypina adres do jednego żądania:

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

Jeśli pierwszy test zwraca adres, do którego klient nie może dotrzeć, problemem jest routing tunelu lub lista split-tunnel. Jeśli drugi test zwraca przekierowanie do nazwy hosta, której się nie spodziewałeś, zatrzymaj się i przeczytaj nagłówek Location, bo to problem aplikacji i żadna zmiana trasy go nie naprawi.

Krok 2: dopasuj serwer WWW, certyfikat i bazowy adres URL CMS

Listener musi być skonfigurowany do obsługi kanonicznej nazwy, a certyfikat musi ją obejmować. Przeglądanie po surowym adresie nie jest obejściem: powoduje niezgodność nazwy, może zepsuć zakres plików cookie i uczy użytkowników klikać przez ostrzeżenia, które później będziesz musiał wyjaśnić audytorowi.

Za odwrotnym proxy upewnij się, że aplikacja wie, iż żądanie przyszło przez HTTPS. Większość platform CMS generuje bezwzględne linki na podstawie wykrytego schematu, a proxy, które kończy TLS bez przekazywania oryginalnego schematu, tworzy stronę pełną http:// zasobów, które przeglądarka może zablokować. Skonfiguruj zaufane proxy i przekazywane nagłówki jawnie, zamiast pozwalać aplikacji zgadywać.

Następnie dopasuj bazowy adres URL CMS i CiviCRM. CiviCRM zachowuje ustalony bazowy adres URL i udostępnia obsługiwany sposób jego ponownego obliczenia: akcję administracyjną Wyczyść pamięci podręczne i zaktualizuj ścieżki, opisaną w przewodniku rozwiązywania problemów z instalacją CiviCRM. Uruchom ją, gdy kanoniczna nazwa i ustawienie CMS się zgadzają, a nie wcześniej, inaczej po prostu zapiszesz w pamięci podręcznej wartość, którą zaraz zmienisz.

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

Krok 3: sprawdź adresy generowane przez CiviCRM

Dotarcie do strony głównej dowodzi bardzo niewiele. CiviCRM działa wewnątrz CMS, a strony, które mają znaczenie, to te budujące własne adresy URL: przekierowanie logowania, menu administracyjne, zasoby rozszerzeń, linki do przesłanych plików i każde zewnętrzne wywołanie zwrotne zarejestrowane przez integrację.

Wczytaj pulpit, otwórz rekord kontaktu i przejrzyj źródło strony pod kątem bezwzględnych linków. Jeśli wskazują nazwę hosta, do której dotrzeć może tylko jedna grupa klientów, bazowy adres URL nadal jest zły, mimo że strona się wyświetliła. Jeśli wskazują właściwą nazwę, ale zły schemat, naprawy wymaga konfiguracja proxy.

Tam, gdzie adres naprawdę musi się zmienić, traktuj to jako migrację aplikacji, a nie edycję DNS. Przejrzyj adresy URL zasobów, pamięci podręczne, opublikowane linki i każdą zewnętrzną integrację, która przechowuje stary adres, a potem zaktualizuj je w jednym oknie, żeby nikt nie został z na wpół zmigrowaną zakładką.

Nazwa hosta w żądaniu nie jest decyzją o zaufaniu

Nie wybieraj uprzywilejowanego bazowego adresu URL tylko dlatego, że nagłówek żądania zawiera określony ciąg. PHP dokumentuje konfiguracje Apache, w których wartość nazwy serwera może odzwierciedlać hosta dostarczonego przez klienta, a zmienna adresu serwera opisuje serwer, nie lokalizację odwiedzającego. Żadna z nich nie jest mechanizmem kontroli dostępu, a budowanie go z nich to sposób, w jaki prywatna usługa zaczyna serwować niewłaściwą treść niewłaściwemu hostowi.

Jeśli wiele nazw hostów jest naprawdę potrzebnych, skonfiguruj jawną listę dozwolonych na serwerze WWW, w CMS i w warstwie aplikacji, i pozwól nazwie hosta z żądania wybierać tylko spośród zatwierdzonych wpisów. Dowolne dane wejściowe nigdy nie powinny stawać się źródłem bezwzględnych linków ani zaufanym celem przekierowania.

Zakończ tą samą zakładką w każdym zatwierdzonym kontekście: logowanie, zwykła nawigacja wewnętrzna i jedno żądanie zasobu. Porównaj nazwy hostów w odpowiedziach, a nie tylko to, czy strona się wczytała. Ten test trzech żądań oddziela problem ścieżki od aplikacji, która wciąż generuje zły adres, i zajmuje około minuty na grupę klientów.