Question 1

Webhook node-unda test və produksiya URL-ləri niyə ayrıdır?

Accepted Answer

Mexanizmi izah et, sonra bunun praktikada hansı səhvə səbəb olduğunu de. "Ayrılığın səbəbi odur ki, qurma və produksiya iki fərqli rejimdir. Test URL yalnız sən kanvasda "Listen for test event" düyməsini basanda qeydiyyatdan keçir və gələn datanı birbaşa kanvasda göstərir — bu, workflow-u qurarkən lazımdır. Production URL isə workflow yayımlananda qeydiyyata düşür və gələn datanı kanvasda göstərmir; onu icra tarixçəsindən görürsən. Bu, praktikada ən çox rast gəlinən səhvin də mənbəyidir: adam test URL-ini xarici sistemə verir, o gün işləyir, ertəsi gün işləmir. Səbəb — test dinləyicisi yalnız o an aktiv idi. Mənim qaydam: xarici sistemə ünvan verməzdən əvvəl workflow-u yayımlayıb produksiya URL-ini kopyalamaq."

Question 2

Webhook-la qəbul etdiyin hadisələrdə dublikatların qarşısını necə alarsan?

Accepted Answer

Dublikatın haradan gəldiyini izah etməklə başla — bu, problemi anladığını göstərir. "Dublikatlar əsasən iki səbəbdən yaranır: göndərən sistem cavabı gec alıb sorğunu təkrar göndərir, ya da onun özündə at-least-once çatdırılma zəmanəti var. Üç səviyyədə həll edirəm: 1. Sürətli cavab — emal uzundursa Respond: Immediately seçirəm ki, göndərən timeout-a düşməsin. Bu, dublikatların böyük hissəsini kökündən aradan qaldırır. 2. İdempotentlik açarı — hadisənin unikal ID-sini götürürəm (çox vaxt header-də və ya body-də olur) və emal etməzdən əvvəl "bu ID artıq varmı?" yoxlayıram. Yazma əməliyyatını mümkünsə upsert edirəm. 3. Emal olunmuş ID-lərin saxlanması — Data Table və ya verilənlər bazasında qısa müddətli qeyd saxlayıram. Əsas prinsip: webhook qəbul edən sistemi idempotent qurmaq lazımdır, çünki eyni hadisənin iki dəfə gəlməsi anomaliya deyil, normal haldır."

Question 3

İnternetə açıq webhook-u necə qorursan?

Accepted Answer

Təhlükəsizlik sualında qatlar üzrə danışmaq ən güclü strukturdur. "Birinci qat — autentifikasiya. Webhook node Basic, Header və JWT auth dəstəkləyir. Açıq internetdə "None" heç vaxt qəbul edilməzdir: URL-in təsadüfi olması sirr sayılmır, çünki loglara, proxy-lərə və brauzer tarixçəsinə düşür. İkinci qat — imza yoxlaması. Bir çox servis (ödəniş sistemləri, GitHub və s.) body-ni gizli açarla imzalayıb header-də göndərir. Bunu yoxlamaq autentifikasiyadan güclüdür, çünki həm göndərəni, həm də məzmunun dəyişdirilmədiyini təsdiqləyir. Üçüncü qat — girişin məhdudlaşdırılması. Mümkünsə göndərənin IP diapazonuna icazə verib qalanını bağlayıram. Dördüncü qat — datanın etibarsız sayılması. Gələn body-ni heç vaxt olduğu kimi verilənlər bazasına və ya sorğuya qoymuram; sahələri yoxlayıb gözlənilən tipə salıram. Əlavə olaraq body ölçüsünə limit var — self-hosted-də bunu konfiqurasiya ilə tənzimləmək mümkündür."

Parametr	Nə edir	Praktik qeyd
Test URL / Production URL	İki ayrı ünvan: biri qurarkən, biri yayımlanandan sonra	Test URL yalnız "Listen for test event" aktiv olanda cavab verir
HTTP Method	Hansı metodu qəbul edəcəyi	Göndərən sistemin nə göndərdiyini yoxla — uyuşmazlıq 404 verir
Path	URL-in son hissəsi; standart olaraq təsadüfi generasiya olunur	`/:variable` şəklində marşrut parametrləri dəstəklənir
Authentication	Basic auth, Header auth, JWT auth və ya heç biri	Açıq internetdə duran webhook mütləq autentifikasiya tələb etməlidir
Respond	Dərhal / son node bitəndə / Respond to Webhook node ilə / axın (streaming)	Uzun emal varsa "dərhal" seç — göndərən sistem timeout-a düşməsin
Response Code	Qaytarılan HTTP status kodu	Qəbul edildi, amma hələ emal olunmayıb → `202`

Webhook node: hadisə qəbulu və API kimi cavab

📚 Mənbələr və sənədlər