Konfiguracja - PrestaShop

Gdzie jest konfiguracja

Wszystko jest na jednym ekranie: Moduły → Menedżer modułów → DockRay → Konfiguruj. Na górze stoją dwie pigułki statusu - czy poświadczenia są kompletne i jak zakończył się ostatni test połączenia, razem z datą.

Kopia sklepu na serwerze testowym

To najczęstsza pułapka w PrestaShopie: sklep skopiowany na staging zabiera ze sobą bazę, a z nią poświadczenia projektu - i oba środowiska zaczynają raportować do jednego projektu. Nadpisz sam klucz stałą w app/config/parameters.php, który nie jest częścią zrzutu bazy:

define('_DOCKRAY_PRIVATE_KEY_', 'klucz-prywatny-projektu-testowego');

Stała wygrywa nad wartością zapisaną w tabeli configuration.

Źródło konfiguracji

Przełącznik Źródło konfiguracji rozstrzyga, jak stałe i formularz współpracują: Auto (domyślne - zdefiniowana stała wygrywa dla swojego pola, resztę bierzemy z formularza), Tylko stałe i Tylko ten formularz. Ostatnia opcja przydaje się, gdy wspólny plik parametrów zaszywa domyślny projekt, a jeden sklep z wielosklepu ma raportować do własnego.

Pozostałe stałe działają tak samo: _DOCKRAY_TOKEN_, _DOCKRAY_URL_, _DOCKRAY_ENVIRONMENT_, _DOCKRAY_RELEASE_, _DOCKRAY_TRACES_SAMPLE_RATE_, _DOCKRAY_SEND_CUSTOMER_, _DOCKRAY_SEND_DEFAULT_PII_, _DOCKRAY_JS_ERRORS_ i _DOCKRAY_JS_SAMPLE_RATE_.

Środowiska

Każde środowisko powinno raportować pod jednoznaczną nazwą - production, staging, preview. Nazwa jest kolumną w panelu i filtrem na liście błędów, więc bez niej awaria z produkcji wygląda dokładnie tak samo jak błąd wywołany w testach. Środowisko lokalne zostaw bez poświadczeń: bez tokenu i klucza integracja ładuje się i milczy, więc nie musisz jej wyłączać osobnym warunkiem.

Dane klienta i prywatność

Dwa przełączniki, oba domyślnie wyłączone i celowo rozdzielone. Dołącz zalogowanego klienta wysyła identyfikator i adres e-mail - pomaga odtworzyć ścieżkę zamówienia, ale wprowadza dane osobowe do monitoringu. Wysyłaj adres IP i user agenta to osobna decyzja, bo dotyczy także gości. Włączaj je świadomie i wpisz to do swojej polityki prywatności.

Błędy JavaScript w sklepie

Domyślnie wyłączone. Po włączeniu moduł ładuje na froncie mały kolektor, który raportuje window.onerror i nieobsłużone odrzucenia obietnic do sklepu, a nie do panelu: uwierzytelnienie z przeglądarki oznaczałoby opublikowanie klucza prywatnego w źródle strony. Sklep przekazuje każdy błąd dalej własnym kluczem.

Odbiornikiem jest front controller modułu (index.php?fc=module&module=dockray&controller=browsererror), pilnowany tokenem PrestaShopu, limitem 16 kB na ciało i 20 zgłoszeniami na adres IP na minutę. Odpowiada 202 niezależnie od tego, czy zgłoszenie przyjął. Sam kolektor też się ogranicza: jedno zgłoszenie na odrębny błąd na odsłonę i najwyżej dziesięć na odsłonę, z odsianym ResizeObserver loop i Script error. z obcej domeny.

Z własnego kodu na froncie:

DockRay.captureException(error);
DockRay.captureMessage('Checkout step skipped');

Ręczne raportowanie z PHP

use Dock\Ray\PrestaShop\Reporter;

try {
    $this->syncStock();
} catch (\Throwable $exception) {
    Reporter::report($exception);

    throw $exception;
}

Reporter::report() nigdy nie rzuca wyjątku, więc można je wywołać także w obsłudze błędu, z której właśnie raportujesz.

Ochrona klucza prywatnego

Klucz prywatny jest sekretem projektu, a nie identyfikatorem. Trzymaj go w zmiennych środowiskowych, w menedżerze sekretów albo w konfiguracji serwera - nigdy w repozytorium, w logach, na zrzucie ekranu ani w kodzie wysyłanym do przeglądarki. Jeden projekt może mieć wiele kluczy, więc produkcja i środowisko testowe powinny dostać osobne: każdy odwołuje się niezależnie, bez przerywania raportowania z pozostałych. Podejrzenie ujawnienia klucza jest wystarczającym powodem, aby go odwołać i wygenerować nowy.

Kiedy zdarzenia wychodzą

Po odpowiedzi. Moduł kolejkuje zdarzenia w czasie żądania i wysyła je z uchwytu zamknięcia, gdy PHP-FPM zamknął już połączenie z przeglądarką. Wolno odpowiadający panel nie kosztuje kupującego ani milisekundy.