Własne webhooki

Webhooki niestandardowe pozwalają zamienić dowolne API HTTP, które już prowadzisz, w narzędzie, którego bot użyje w trakcie rozmowy — sprawdzenie statusu zamówienia, wyszukanie klienta, otwarcie zgłoszenia w systemie wsparcia albo cokolwiek innego, co potrafi Twój backend przez HTTP. W przeciwieństwie do gotowych integracji (Calendly, PrestaShop) to samoobsługowy sposób podłączenia własnych systemów, bez udziału inżynierów Fibly — wymaga jednak dewelopera po Twojej stronie, który zbuduje odbierający endpoint i — w zakresie opisanym w tym przewodniku — zweryfikuje, że wywołanie rzeczywiście pochodzi od Fibly.

Kiedy jej użyć

Sięgnij po webhook niestandardowy, gdy chcesz, aby bot wywołał system, dla którego nie ma dedykowanej integracji Fibly: własne API zarządzania zamówieniami, wewnętrzny system zgłoszeń, backend rezerwacji, CRM — cokolwiek dostępnego przez HTTPS. Jeśli dane lub akcja pasują już do istniejącej integracji (Calendly, PrestaShop), użyj jej zamiast tego — nie wymaga żadnego kodu po Twojej stronie.

Budowanie połączenia

Połączenie to jedna z Twoich usług backendowych: jej adres bazowy i statyczne dane uwierzytelniające, których bot używa do jej wywoływania. Każde zdefiniowane narzędzie należy do jakiegoś połączenia i wywołuje ścieżkę względem jego adresu bazowego.

1. Otwórz Ustawienia → Integracje, znajdź kartę Webhooki niestandardowe i kliknij Zarządzaj.
2. Kliknij Dodaj połączenie.
3. Uzupełnij:
   • Nazwa — etykieta na Twój własny użytek (np. „API sprawdzania zamówień").
   • Adres URL bazowy — główny adres Twojego API, np. https://api.example.com. Musi to być publicznie dostępny adres HTTPS — adresy lokalne lub prywatne oraz ruch nieszyfrowany (inny niż HTTPS) są odrzucane.
   • Uwierzytelnianie — sposób, w jaki Fibly uwierzytelnia się w Twoim API:
     • Brak uwierzytelniania — żadne dane nie są wysyłane.
     • Basic auth — nazwa użytkownika i hasło, wysyłane jako nagłówek Authorization: Basic.
     • Token typu Bearer — pojedynczy token, wysyłany jako Authorization: Bearer <token>.
   • Wysyłaj token weryfikacyjny — domyślnie wyłączone. Włącz to ustawienie, jeśli chcesz, aby Fibly wysyłało podpisany nagłówek X-Fibly-Verification przy każdym wywołaniu na tym połączeniu (zobacz Weryfikacja wywołującego poniżej). Gdy jest wyłączone, Fibly nigdy nie dołącza tego nagłówka.
4. Zapisz. Pole hasła/tokena jest tylko do zapisu: po zapisaniu nie jest już nigdy pokazywane w panelu.

Pierwsze utworzone połączenie automatycznie generuje też klucz podpisujący Twojego obszaru roboczego (zobacz Weryfikacja wywołującego poniżej).

Budowanie narzędzia

W ramach połączenia dodaj jedno lub więcej narzędzi — każde odpowiada jednemu wywołaniu HTTP:

1. Kliknij Dodaj narzędzie na stronie połączenia.
2. Uzupełnij:
   • Nazwa narzędzia — identyfikator, którego agent używa wewnętrznie do wywołania tego narzędzia, np. get_order_status. Tylko litery, cyfry i podkreślenia, unikalny we wszystkich Twoich połączeniach.
   • Metoda HTTP — GET, POST, PUT, PATCH lub DELETE.
   • Ścieżka — względem adresu bazowego połączenia, np. /orders/{order_ref}. Ujmij fragment w { }, aby odwołać się do parametru (zobacz niżej) — zostanie podstawiony wartością argumentu i zakodowany do URL przed wywołaniem.
   • Opis — podpowiedź, którą model AI czyta, aby zdecydować, kiedy i jak wywołać to narzędzie. Opisz, co robi i kiedy jest przydatne; model nigdy nie pokazuje tego tekstu klientowi.
   • Parametry — argumenty, które model może uzupełnić. Dla każdego dodaj nazwę, typ (String, Number, Integer, Boolean lub Enum z ustaloną listą wartości), czy jest wymagany, oraz opis.
   • Wymaga potwierdzenia — zobacz niżej.
   • Wymaga weryfikacji tożsamości — zobacz niżej.
3. Edytor narzędzia ma przełącznik Angielski/Polski: opis narzędzia i opis każdego parametru są lokalizowane, dzięki czemu model rozumuje w języku, w jakim toczy się rozmowa. Angielski opis jest wymagany; pozostałe języki, jeśli puste, spadają do niego.
4. Zapisz i włącz przełącznik Włączone, gdy narzędzie ma być dostępne dla bota na żywo.

Jak agent wywołuje Twój webhook

Gdy model zdecyduje się użyć narzędzia, Fibly buduje i wysyła za Ciebie żądanie HTTP:

• Każdy znacznik {nazwa} w ścieżce jest podstawiany wartością odpowiadającego argumentu (zakodowaną do URL).
• Pozostałe argumenty trafiają do query string dla GET/DELETE, albo do treści JSON dla POST/PUT/PATCH.
• Uwierzytelnianie Twojego połączenia (Basic/Bearer) jest stosowane automatycznie.
• Jeśli ustawienie połączenia Wysyłaj token weryfikacyjny jest włączone, dołączany jest podpisany nagłówek X-Fibly-Verification — zobacz kolejną sekcję. Domyślnie jest wyłączone, więc dopóki go nie włączysz, Twój webhook w ogóle nie otrzyma tego nagłówka.
• Wywołanie ma stały limit czasu ok. 10 sekund, a Fibly nie podąża za przekierowaniami — jeśli Twoje API przekierowuje (30x), zaktualizuj adres bazowy połączenia zamiast polegać na przekierowaniu.

Co widzi agent w odpowiedzi

• Odpowiedź 2xx z treścią JSON trafia do modelu jako dane strukturalne, których może użyć w odpowiedzi. 2xx z treścią inną niż JSON jest przekazywane jako zwykły tekst.
• Odpowiedź inna niż 2xx, przekroczenie limitu czasu lub błąd połączenia są traktowane jako niepowodzenie narzędzia — model dowiaduje się, że wywołanie się nie powiodło, i odpowiednio dostosowuje odpowiedź (w tym przypadku nie widzi Twojego surowego kodu statusu ani treści).

Projektuj odpowiedzi sukcesu swojego webhooka tak, by były małe i bezpośrednio użyteczne — to, co zwrócisz w treści JSON 2xx, jest tym, czego model używa do odpowiedzi klientowi.

Weryfikacja wywołującego (X-Fibly-Verification)

Włącz Wysyłaj token weryfikacyjny na połączeniu (domyślnie wyłączone — zobacz Budowanie połączenia wyżej), a każde wywołanie na tym połączeniu będzie nieść podpisany token JWT w nagłówku X-Fibly-Verification. To część, którą musi zaimplementować Twój deweloper, i ma znaczenie nawet jeśli Twoje API wymaga też własnych danych uwierzytelniających Basic/Bearer: te dane dowodzą jedynie, że żądanie przyszło skądś z backendu Fibly; podpisany token dowodzi, że przyszło z konkretnego, skonfigurowanego połączenia Twojego obszaru roboczego, i niesie kontekst rozmowy oraz klienta potrzebny do podjęcia decyzji autoryzacyjnych. Gdy włączysz ten przełącznik, Fibly zacznie dołączać nagłówek do każdego wywołania na tym połączeniu — weryfikacja go po Twojej stronie to osobny krok, opisany niżej; dopóki go nie zaimplementujesz, nagłówek po prostu dociera nieużywany.

Po co to istnieje. Fibly nie zna Twojego modelu danych, więc nie może sprawdzić na przykład, czy zamówienie, o które pyta klient, rzeczywiście do niego należy. To, co może zrobić, to przekazać Ci kryptograficznie podpisane, odporne na manipulację oświadczenie o tym, kim jest odwiedzający (na tyle, na ile sięga własna weryfikacja Fibly) i do jakiej rozmowy należy wywołanie — tak, aby Twój serwer mógł sam wykonać tę weryfikację własności.

Endpoint JWKS

Fibly generuje dla Twojego obszaru roboczego parę kluczy RSA-2048 przy pierwszym utworzeniu połączenia. Klucz prywatny nigdy nie opuszcza Fibly; klucz publiczny jest publikowany pod endpointem JWKS Twojego obszaru roboczego — publicznym, niewymagającym uwierzytelnienia adresem URL, który zwraca Twoje aktywne (i niedawno zrotowane) klucze publiczne w standardowym formacie JWKS {"keys": [...]}.

Skopiuj swój adres URL JWKS z panelu — nie próbuj go samodzielnie budować. Jest on stały dla Twojego obszaru roboczego i widoczny obok ID klucza oraz ID połączenia w panelu Klucze podpisujące, tuż przy przycisku Pobierz klucz publiczny (PEM) oraz akcji Rotuj klucz. Skopiuj adres URL JWKS do stałej JWKS_URL, a ID połączenia do stałej CONNECTION_ID w przykładach kodu poniżej — obie wartości powinny być zaszytą na stałe konfiguracją po stronie Twojego serwera, a nie czymś wyliczanym z żądania. Rotacja od razu zaczyna podpisywać nowe tokeny nowym kluczem, ale poprzedni klucz pozostaje publikowany w JWKS przez krótkie okno zakładki, tak aby tokeny już będące w drodze nadal się weryfikowały — pobieraj klucze po kid i nie zaszywaj na stałe treści jednego klucza, w przeciwnym razie rotacja zepsuje Twoją weryfikację.

Tabela roszczeń (claims)

Token to zwarty JWS, algorytm RS256, z identyfikatorem klucza podpisującego w nagłówku JWT jako kid. Jego treść (payload):

Transkrypt rozmowy nigdy nie jest w nim zawarty — tylko metadane rozmowy/klienta.

Dane kanału (channel_data)

channel_data niesie kontekst właściwy dla kanału, na którym toczyła się rozmowa. Obecny jest tylko jeden klucz — ten odpowiadający roszczeniu channel — odczytaj go jako claims["channel_data"][claims["channel"]], zamiast sprawdzać kształt dla każdego kanału z osobna:

Tylko kanał chat niesie adres IP, user agent, przeglądarkę/system operacyjny oraz geolokalizację — te dane pochodzą z sesji przeglądarki odwiedzającego na Twojej stronie, której nie ma dla pozostałych kanałów. Każde pole, którego Fibly nie ma dla danego wywołania, ma wartość null zamiast być pominięte, więc kształt dla danego kanału jest zawsze taki sam.

channel_data to dane osobowe. Adres IP, odcisk przeglądarki/systemu operacyjnego, e-mail, numer telefonu oraz identyfikatory Messenger/Instagram to w większości reżimów ochrony danych dane osobowe. Przetwarzaj, przechowuj i loguj je odpowiednio — i nie przekazuj ich dalej tam, gdzie nie przekazałbyś reszty danych kontaktowych klienta.

Roszczenie email nie jest automatycznie zweryfikowane. Odzwierciedla e-mail, jaki Fibly ma zapisany dla klienta, niezależnie od tego, czy został udowodniony. Zanim zaufasz roszczeniu email w czymkolwiek istotnym, sprawdź, czy email_verified ma wartość true. Jeśli Twoje narzędzie ma włączone Wymaga weryfikacji tożsamości w panelu, Fibly gwarantuje, że email_verified jest true, zanim Twój webhook zostanie w ogóle wywołany dla tego narzędzia — zobacz kolejną sekcję.

Weryfikacja tokena, krok po kroku

1. Odczytaj nagłówek X-Fibly-Verification z przychodzącego żądania. Jeśli go brakuje, potraktuj wywołanie jako niezweryfikowane — zdecyduj o własnej polityce (odrzuć je albo udostępnij tylko dane nieistotne z punktu widzenia prywatności).
2. Pobierz (i cache'uj) swój stały adres JWKS — ten skopiowany z panelu Klucze podpisujące, a nie wyliczony samodzielnie — i z nagłówka tokena wybierz klucz, którego kid pasuje.
3. Zweryfikuj podpis RS256 tokena względem tego klucza.
4. Zwaliduj exp (nie wygasł), iss (równa się "fibly") oraz aud (równa się ID połączenia tego połączenia, również skopiowanemu z panelu Klucze podpisujące). Sprawdzaj aud zawsze, nie tylko wtedy, gdy chcesz „przypiąć” weryfikację — to on powstrzymuje token podpisany dla innego połączenia przed zweryfikowaniem się tutaj. Opcjonalnie sprawdź też, czy roszczenie tenant_id równa się Twojemu id obszaru roboczego, jako dodatkowe zabezpieczenie.
5. Dopiero gdy podpis i standardowe roszczenia się zgadzają, zaufaj reszcie treści.
6. Wykonaj własną weryfikację własności zasobu na podstawie zweryfikowanych roszczeń — Fibly nie zna Twojego modelu danych i nie może zrobić tego za Ciebie.

Ponieważ zrotowany klucz pozostaje ważny przez krótkie okno zakładki, klient JWKS powinien cache'ować odpowiedzi na krótko i pobierać je ponownie przy nierozpoznanym kid, zamiast cache'ować jeden klucz na stałe.

Uwaga dotycząca bezpieczeństwa: nigdy nie pozwól tokenowi wskazać, którym kluczem go zweryfikować. Odczytanie tenant_id (lub dowolnego innego roszczenia) z niezweryfikowanego tokena i użycie go do zbudowania adresu URL JWKS, który następnie pobierasz, jest niebezpieczne — token podpisany kluczem innego tenanta Fibly zostałby pobrany i zweryfikowany względem JWKS tego tenanta, pozwalając komukolwiek, kto potrafi zdobyć podpisany token z własnego (kontrolowanego przez atakującego) obszaru roboczego, podszyć się pod wywołania Twojego webhooka. Zawsze weryfikuj względem jednego, stałego adresu URL JWKS skopiowanego z panelu Klucze podpisujące Twojego połączenia — nigdy adresu zbudowanego na podstawie samego tokena.

Przykład: narzędzie statusu zamówienia

Załóżmy, że budujesz narzędzie get_order_status: GET /orders/{order_ref} na połączeniu Twojego API zamówień, z jednym wymaganym parametrem order_ref typu string i włączonym Wymaga weryfikacji tożsamości. Połączenie ma też włączone Wysyłaj token weryfikacyjny — bez tego nagłówek X-Fibly-Verification w ogóle by nie dotarł, a kroki 3-4 poniżej nie byłyby możliwe.

1. Klient pyta „gdzie jest moje zamówienie 12345?". Model ma order_ref="12345", ale odwiedzający nie zweryfikował jeszcze e-maila w tej rozmowie. Ponieważ narzędzie wymaga weryfikacji, Fibly w ogóle nie wywołuje Twojego webhooka — zwraca modelowi status verification_required, a ten prosi klienta o weryfikację e-maila (własny mechanizm linku magicznego Fibly) i ponawia próbę po jej ukończeniu.
2. Po weryfikacji Fibly wywołuje:

   GET https://api.example.com/orders/12345
   Authorization: Bearer <token Twojego połączenia>
   X-Fibly-Verification: <jwt>
   

3. Twój serwer weryfikuje JWT tak jak opisano wyżej. Ponieważ to narzędzie wymaga weryfikacji, email_verified jest gwarantowane jako true, a email to zweryfikowany adres odwiedzającego, np. [email protected].
4. Twój serwer wyszukuje zamówienie 12345 we własnej bazie danych i porównuje e-mail jego właściciela ze zweryfikowanym email z tokena. Jeśli się zgadzają, zwróć status:

   { "order_ref": "12345", "status": "shipped" }
   

   Jeśli się nie zgadzają — albo zamówienie nie istnieje — zwróć 404, a nie 403: 403 potwierdziłby atakującemu, że zamówienie 12345 w ogóle istnieje.

Przykłady kodu: weryfikacja tokena

Każdy z poniższych przykładów odczytuje nagłówek, pobiera JWKS (z cache'owaniem), weryfikuje podpis RS256 po kid, sprawdza exp/iss/aud i wykonuje tę samą weryfikację własności e-maila co w przykładzie wyżej. Podmień JWKS_URL i CONNECTION_ID na wartości widoczne w panelu Klucze podpisujące tego połączenia — obie to zaszyta na stałe konfiguracja, nigdy niewyliczana z tokena (zobacz uwagę o bezpieczeństwie wyżej).

import jwt
from jwt import PyJWKClient

# Skopiuj obie wartości z panelu Klucze podpisujące tego połączenia i zaszyj je na
# stałe jako konfigurację — nigdy nie wyznaczaj JWKS_URL na podstawie roszczenia z
# (niezweryfikowanego) tokena, bo token podpisany kluczem innego tenanta mógłby się
# tu zweryfikować.
JWKS_URL = "https://app.fibly.io/api/tool-integrations/custom-webhooks/<id-Twojego-obszaru-roboczego>/jwks.json"  # skopiuj z panelu
CONNECTION_ID = "c1a2e3f4-5678-4abc-9def-0123456789ab"  # „ID połączenia” w panelu Klucze podpisujące

# PyJWKClient cache'uje odpowiedź JWKS i pobiera ją ponownie przy nieznanym `kid`.
_jwks_client = PyJWKClient(JWKS_URL, cache_keys=True)

def verify_fibly_token(token: str) -> dict:
    signing_key = _jwks_client.get_signing_key_from_jwt(token)
    claims = jwt.decode(
        token,
        signing_key.key,
        algorithms=["RS256"],
        audience=CONNECTION_ID,
        issuer="fibly",
        options={"require": ["exp", "iat", "iss", "aud"]},
    )
    return claims


def handle_get_order_status(order_ref: str, headers: dict) -> tuple[dict, int]:
    token = headers.get("X-Fibly-Verification", "")
    if not token:
        return {"error": "missing verification token"}, 401
    try:
        claims = verify_fibly_token(token)
    except Exception:
        return {"error": "invalid verification token"}, 401

    order = get_order(order_ref)  # Twoje własne wyszukiwanie
    if order is None:
        return {"error": "not found"}, 404

    verified_email = (claims.get("email") or "").lower()
    if not claims.get("email_verified") or order.customer_email.lower() != verified_email:
        return {"error": "not found"}, 404  # 404, nie 403 — nie potwierdzaj istnienia zamówienia

    return {"order_ref": order_ref, "status": order.status}, 200

import { createRemoteJWKSet, jwtVerify } from 'jose';

// Skopiuj obie wartości z panelu Klucze podpisujące tego połączenia i zaszyj je na
// stałe jako konfigurację — nigdy nie wyznaczaj JWKS_URL na podstawie roszczenia z
// (niezweryfikowanego) tokena, bo token podpisany kluczem innego tenanta mógłby się
// tu zweryfikować.
const JWKS_URL = new URL(
  'https://app.fibly.io/api/tool-integrations/custom-webhooks/<id-Twojego-obszaru-roboczego>/jwks.json', // skopiuj z panelu
);
const CONNECTION_ID = 'c1a2e3f4-5678-4abc-9def-0123456789ab'; // „ID połączenia” w panelu Klucze podpisujące

// createRemoteJWKSet cache'uje odpowiedź i pobiera ją ponownie przy nierozpoznanym `kid`.
const jwks = createRemoteJWKSet(JWKS_URL);

async function verifyFiblyToken(token) {
  const { payload } = await jwtVerify(token, jwks, {
    issuer: 'fibly',
    audience: CONNECTION_ID,
    algorithms: ['RS256'],
  });
  return payload;
}

app.get('/orders/:ref', async (req, res) => {
  const token = req.header('X-Fibly-Verification');
  if (!token) return res.status(401).json({ error: 'missing verification token' });

  let claims;
  try {
    claims = await verifyFiblyToken(token);
  } catch {
    return res.status(401).json({ error: 'invalid verification token' });
  }

  const order = await getOrder(req.params.ref); // Twoje własne wyszukiwanie
  if (!order) return res.status(404).json({ error: 'not found' });

  const verifiedEmail = (claims.email || '').toLowerCase();
  if (!claims.email_verified || order.customerEmail.toLowerCase() !== verifiedEmail) {
    return res.status(404).json({ error: 'not found' }); // 404, nie 403
  }

  res.json({ order_ref: req.params.ref, status: order.status });
});

<?php
use Firebase\JWT\JWT;
use Firebase\JWT\JWK;

// Skopiuj obie wartości z panelu Klucze podpisujące tego połączenia i zaszyj je na
// stałe jako konfigurację — nigdy nie wyznaczaj JWKS_URL na podstawie roszczenia z
// (niezweryfikowanego) tokena, bo token podpisany kluczem innego tenanta mógłby się
// tu zweryfikować.
const JWKS_URL = 'https://app.fibly.io/api/tool-integrations/custom-webhooks/<id-Twojego-obszaru-roboczego>/jwks.json'; // skopiuj z panelu
const CONNECTION_ID = 'c1a2e3f4-5678-4abc-9def-0123456789ab'; // „ID połączenia” w panelu Klucze podpisujące

function verify_fibly_token(string $token): array
{
    // W produkcji cache'uj tę odpowiedź zamiast pobierać ją przy każdym żądaniu.
    $jwks = json_decode(file_get_contents(JWKS_URL), true);
    $keys = JWK::parseKeySet($jwks);

    // JWT::decode weryfikuje podpis RS256 (dobierając klucz po `kid`) i
    // automatycznie egzekwuje `exp`; `iss`/`aud` sprawdzamy jawnie poniżej.
    $claims = (array) JWT::decode($token, $keys);

    if (($claims['iss'] ?? null) !== 'fibly') {
        throw new \RuntimeException('unexpected issuer');
    }
    if (($claims['aud'] ?? null) !== CONNECTION_ID) {
        throw new \RuntimeException('unexpected audience');
    }
    return $claims;
}

// GET /orders/{ref}
$token = $_SERVER['HTTP_X_FIBLY_VERIFICATION'] ?? '';
if ($token === '') {
    http_response_code(401);
    echo json_encode(['error' => 'missing verification token']);
    exit;
}

try {
    $claims = verify_fibly_token($token);
} catch (\Throwable $e) {
    http_response_code(401);
    echo json_encode(['error' => 'invalid verification token']);
    exit;
}

$order = get_order($_GET['ref'] ?? ''); // Twoje własne wyszukiwanie
if (!$order) {
    http_response_code(404);
    echo json_encode(['error' => 'not found']);
    exit;
}

$verifiedEmail = strtolower($claims['email'] ?? '');
$emailVerified = !empty($claims['email_verified']);
if (!$emailVerified || strtolower($order['customer_email']) !== $verifiedEmail) {
    http_response_code(404); // 404, nie 403 — nie potwierdzaj istnienia zamówienia
    echo json_encode(['error' => 'not found']);
    exit;
}

echo json_encode(['order_ref' => $order['ref'], 'status' => $order['status']]);

Weryfikacja tożsamości i potwierdzenie

Dwa niezależne przełączniki, ustawiane per narzędzie, kontrolują, jak ostrożnie narzędzie jest wywoływane:

Weryfikacja tożsamości (requires_verification)

Włącz Wymaga weryfikacji tożsamości dla narzędzia, które zwraca prywatne dane (szczegóły zamówienia, informacje o koncie, cokolwiek powiązanego z jednym klientem). Gdy jest włączona, agent może wywołać Twój webhook dopiero, gdy odwiedzający udowodni, że jest właścicielem swojego e-maila — albo przez własny link weryfikacyjny Fibly, albo dlatego że rozmowa przyszła kanałem zweryfikowanego e-maila. Do tego czasu wywołanie narzędzia zwraca modelowi status verification_required, który prosi klienta o weryfikację i ponawia próbę — Twój webhook nigdy nie jest wywoływany dla niezweryfikowanej próby.

To dowodzi jedynie, że wywołujący kontroluje jakiś adres e-mail. Nie dowodzi, że konkretny żądany zasób (np. to konkretne zamówienie) należy do niego — ta weryfikacja zawsze należy do Ciebie, na podstawie zweryfikowanych roszczeń email/customer_id w tokenie, jak pokazano w przykładzie powyżej.

Potwierdzenie (requires_confirmation)

Włącz Wymaga potwierdzenia dla narzędzia, które coś zmienia (tworzy zgłoszenie, anuluje zamówienie, cokolwiek, czego nie chcesz uruchamiać po cichu). Gdy jest włączona, widget zatrzymuje się i prosi klienta o wyraźne zatwierdzenie konkretnego wywołania, zanim dotrze ono do Twojego webhooka. Gdy jest wyłączona, narzędzie uruchamia się natychmiast, gdy tylko model zdecyduje się go użyć — odpowiednie dla odczytów bez skutków ubocznych.

Testowanie narzędzia

Zanim włączysz narzędzie dla prawdziwych rozmów, otwórz je w edytorze i skorzystaj z panelu Przetestuj to narzędzie: wprowadź przykładowe argumenty jako JSON, a następnie kliknij Uruchom test. Wysyła to prawdziwe wywołanie dokładnie tą samą ścieżką, którą przechodzi ruch produkcyjny — sprawdzone pod kątem SSRF, z dołączonym rzeczywistym tokenem X-Fibly-Verification, jeśli ustawienie połączenia Wysyłaj token weryfikacyjny jest włączone — i pokazuje zwrócony status oraz odpowiedź od razu w panelu, dzięki czemu możesz potwierdzić, że webhook jest poprawnie podłączony, zanim go włączysz.

Lista kontrolna bezpieczeństwa

• Zawsze weryfikuj podpis. Nigdy nie ufaj roszczeniom w X-Fibly-Verification, dopóki podpis RS256 nie zostanie potwierdzony względem Twojego JWKS.
• Sprawdzaj exp. Odrzucaj wygasłe tokeny; większość bibliotek JWT robi to automatycznie po dekodowaniu z weryfikacją.
• Sam egzekwuj własność zasobu. Fibly potwierdza, kim jest zweryfikowany odwiedzający; nie zna Twojego modelu danych, więc nie może potwierdzić, że rekord, o który pyta, do niego należy.
• Nie ufaj samemu email. Traktuj go jako zweryfikowany dopiero, gdy email_verified ma wartość true.
• Używaj HTTPS na swoim endpoincie — Fibly tego wymaga (poza własnym środowiskiem deweloperskim obszaru roboczego, które i tak nie jest dostępne z internetu).
• Chroń sekret swojego połączenia. Traktuj dane Basic/Bearer jak hasło; Fibly szyfruje je w spoczynku i nigdy nie wyświetla ponownie po zapisaniu.
• Preferuj 404 zamiast 403, gdy weryfikacja własności się nie powiedzie, aby nie potwierdzać wywołującemu, że dany zasób w ogóle istnieje.

Powiązane artykuły

• Przegląd narzędzi: wszystkie narzędzia, z których może korzystać bot.
• Rozmowy: zobacz akcje wykonane przez bota, w tym wywołania narzędzi niestandardowych.