Rozwiązywanie problemów i lista kontrolna

Narzędzia

• Narzędzia deweloperskie → Sieć: loader.js, core.<hash>.js, połączenie WebSocket (zakładka „Wiadomości” lub „Frames” pokazuje init, init_ok, error) albo żądania trybu awaryjnego HTTP (h/auf, …/sse, …/tx).
• Włączenie diagnostyki: data-rc-debug="true" w tagu loadera albo w konsoli localStorage.setItem('rc_debug','1') i przeładowanie strony.
• Konsola: ReactiveChat('getSession'), ReactiveChat('getEndpoint'), ReactiveChat('isOpen'), ReactiveChat.version.

Nie widać launchera

• Brak klucza witryny albo jest nieprawidłowy. Loader przerywa wtedy działanie po cichu. Sprawdź data-rc-site-key (8–64 znaki z A–Z a–z 0–9 _ -) w wykonanym tagu – menedżery tagów i pomocniki frameworków czasem pomijają atrybuty.
• type="module" w tagu script: loader nie znajduje wtedy swojego tagu. Osadź go jako klasyczny skrypt.
• data-rc-hide-launcher="true" albo w koncie ustawiono „Tylko przez własne linki (bez ikony czatu)”.
• Brak koloru marki we fragmencie kodu: bez prawidłowego koloru w data-rc-brand przycisk pojawia się dopiero po nawiązaniu połączenia. Skopiuj fragment kodu z konta ponownie.
• Projekt wstrzymany albo nieznany klucz witryny: serwer odpowiada unknown_site_key (Close 4002); w tej karcie widżet przez dziesięć minut nie próbuje ponownie.
• Rdzeń się nie ładuje: w konsoli widnieje [reactive.chat] core.js …. Często adres blokuje script-src albo bloker reklam – zobacz Własna domena.

Launcher jest, ale żadna wiadomość nie dociera

• Samodzielnie serwowany loader.js bez data-rc-ws-url: widżet szuka serwera czatu w twojej domenie. W zakładce „Sieć” widzisz bezskuteczne połączenia do wss://ws.<deine-domain>/rc_wss/. Rozwiązanie: data-rc-ws-url="wss://ws.reactive.chat/rc_wss/".
• origin_denied, Close 1008: w polu Dozwolone źródła brakuje domeny strony. Wpisuje się domenę strony internetowej, a nie subdomenę czatu.
• Blokada CSP: w konsoli widnieje komunikat CSP dotyczący wss://… albo https://…/rc_wss/h/auf. Dodaj obie formy do connect-src.
• Sieć firmowa bez WebSocket: po dwóch nieudanych próbach widżet przechodzi na tryb awaryjny HTTP. Jeśli i to nie działa, sprawdź proxy, które przerywają żądania krótsze niż 30 sekund albo buforują odpowiedzi (Transport).
• Blokada przez ochronę przed nadużyciami (Close 1008 blocked): typowo za własnym proxy bez ważnego klucza proxy, bo wtedy wszyscy odwiedzający mają ten sam adres.
• Zbyt długa wiadomość: widżet nie wysyła tekstów powyżej limitu planu (1000 albo 4000 znaków).

Zalogowany użytkownik uchodzi za anonimowego

W ramce error widnieje auth_failed z detail.reason:

• no_hash – w identify brakuje userHash.
• no_secret – w projekcie nie skonfigurowano sekretu.
• bad_exp – exp w milisekundach zamiast sekund albo nie jest liczbą całkowitą.
• expired – strona długo otwarta albo zły zegar serwera; obliczaj hash na świeżo przy ładowaniu strony.
• exp_too_far – ponad 24 godziny naprzód.
• bad_hash – nie zgadza się sekret, kolejność (userId + "." + exp) albo kodowanie znaków; kluczem jest sekret jako ciąg znaków, a nie zdekodowane bajty. Z e-mailem adres musi być podpisany dokładnie tak, jak go przekazujesz.

Szczegóły: Identyfikacja odwiedzających.

Dane klientów nie docierają

• Asystent prosi o zalogowanie, choć użytkownik jest zalogowany: brakuje exp albo wygasł – bez exp nie ma danych klientów.
• Testuj połączenie w koncie podaje przyczynę (http_401, zeitueberschreitung, umleitung, adresse_privat …). Podpisywany jest ciąg X-RC-Zeit + "." + roher Body – sprawdzaj go na bajtach, które dotarły, a nie na ponownie zakodowanym JSON.
• W odpowiedzi asystenta brakuje pola: nie zostało udostępnione w koncie albo jest na liście pól, które nigdy nie są przejmowane.

Szczegóły: Endpoint danych klientów.

Webhooki nie docierają

• Czy integracja jest włączona, a zdarzenie wybrane (brak wyboru = wszystkie)? Po włączeniu odczekaj do 15 sekund.
• Twój endpoint odpowiada dłużej niż 10 sekund albo przekierowaniem.
• Twój endpoint raz odpowiedział 410 – to dezaktywuje integrację. Włącz ją ponownie.
• Podpis się nie zgadza: licz go na surowej treści i z X-RC-Timestamp + "." + Body, pamiętaj o prefiksie sha256=.
• W data brakuje treści: jakie pola niesie każde zdarzenie, opisano w Webhookach; niewybrane zdarzenie w ogóle nie przychodzi.

API serwera

• 401 auth_failed: klucz unieważniony, z literówką albo osoba, która go utworzyła, nie jest już administratorem.
• 403 insufficient_scope: zakres nie wystarcza; required_scope podaje wymagany.
• 429: przekroczono 120 zapytań na minutę; respektuj Retry-After.
• 415/413: brakuje Content-Type: application/json albo treść żądania przekracza 64 KiB.

Tekst o ochronie danych się nie pojawia

• Loadera nie ma na stronie albo blokuje go platforma zgód: osadź bezpośrednio datenschutz.js.
• Strona nie jest wpisana jako domena w projekcie albo projekt jest wstrzymany.
• data-rc-privacy-state="error" przy elemencie oznacza nieudane pobranie.

Lista kontrolna przed uruchomieniem

1. Wszystkie domeny strony wpisane w polu Dozwolone źródła.
2. Fragment kodu z konta bez zmian na wszystkich stronach, na których ma się pojawiać czat – także na stronie z polityką prywatności.
3. CSP: script-src z miejscem dostarczania, connect-src z wss:// i https://, img-src dla obrazów.
4. Zgoda: sprawdzone data-rc-consent albo platforma zgód (TCF v2 / consented.eu) – przetestowane ze zgodą i bez niej.
5. Polityka prywatności uzupełniona (<div data-rc-privacy> albo fragment tekstu).
6. Tożsamość: userHash z exp obliczany na serwerze, sekret tylko w środowisku serwera, init_ok.identity.verified ma wartość true.
7. Obszary z poufnym tekstem oznaczone data-rc-private.
8. Przy własnej domenie: wszystkie pięć kroków testu „w porządku”, klucz proxy tylko w konfiguracji proxy, /rc_wss/h/ poza logiem dostępu.
9. Webhooki: sprawdzane podpis i znacznik czasu, duplikaty wykrywane przez X-RC-Delivery, szybka odpowiedź 2xx.
10. Tryb awaryjny HTTP raz przetestowany z data-rc-transport="http".
11. Sprawdzony widok mobilny (poniżej 480 pikseli czat otwiera się na pełnym ekranie) i obsługa z klawiatury.