Bagikan melalui

Validasi titik akhir dengan skema CloudEvents

  • Artikel

Webhook adalah salah satu dari banyak cara untuk menerima acara dari Azure Event Grid. Ketika peristiwa baru siap, layanan Event Grid memPOST permintaan HTTP ke titik akhir yang dikonfigurasi dengan informasi peristiwa di isi permintaan.

Seperti banyak layanan lain yang mendukung webhook, Event Grid mengharuskan Anda membuktikan kepemilikan titik akhir Webhook Anda sebelum mulai mengirimkan acara ke titik akhir tersebut. Persyaratan ini mencegah pengguna berbahaya membanjiri titik akhir Anda dengan acara.

Validasi titik akhir dengan CloudEvents v1.0

CloudEvents v1.0 mengimplementasikan semantik perlindungan penyalahgunaannya sendiri menggunakan metode OPSI HTTP. Saat Anda menggunakan skema CloudEvents untuk output, Event Grid menggunakan perlindungan penyalahgunaan CloudEvents v1.0 sebagai menggantikan mekanisme peristiwa validasi Event Grid.

Perlindungan penyalahgunaan CloudEvent v1.0

Sistem apa pun yang memungkinkan pendaftaran dan pengiriman pemberitahuan ke titik akhir HTTP sewenang-wenang dapat berpotensi disalahgunakan sedemikian rupa sehingga seseorang secara jahat atau tidak sengaja mendaftarkan alamat sistem yang tidak mengharapkan permintaan tersebut dan di mana pihak yang mendaftar tidak berwenang untuk melakukan pendaftaran tersebut. Dalam kasus ekstrem, infrastruktur pemberitahuan dapat disalahgunakan untuk meluncurkan serangan penolakan layanan terhadap situs web sewenang-wenang.

Untuk melindungi pengirim agar tidak disalahgunakan dengan cara seperti itu, target pengiriman yang sah perlu menunjukkan bahwa pengirim setuju dengan pemberitahuan yang dikirimkan kepadanya.

Mencapai perjanjian pengiriman diwujudkan menggunakan jabat tangan validasi berikut. Jabat tangan dapat segera dijalankan pada waktu pendaftaran atau sebagai permintaan "preflight" segera sebelum pengiriman.

Penting untuk dipahami bahwa jabat tangan tidak bertujuan untuk menetapkan konteks autentikasi atau otorisasi. Ini hanya berfungsi untuk melindungi pengirim agar tidak diberitahu ke pendorongan ke tujuan yang tidak mengharapkan lalu lintas. Meskipun spesifikasi ini mengamanatkan penggunaan model otorisasi, mandat ini tidak cukup untuk melindungi situs web sewenang-wenang dari lalu lintas yang tidak diinginkan jika situs web tersebut tidak menerapkan kontrol akses dan karenanya mengabaikan Authorization header.

Target pengiriman HARUS mendukung fitur perlindungan penyalahgunaan. Jika target tidak mendukung fitur ini, pengirim DAPAT memilih untuk tidak mengirim ke target, sama sekali, atau hanya mengirim dengan tingkat permintaan yang sangat rendah.

Permintaan validasi

Permintaan validasi menggunakan metode HTTP OPTIONS . Permintaan diarahkan ke URI target sumber daya yang tepat yang sedang didaftarkan. Dengan permintaan validasi, pengirim meminta target izin untuk mengirim pemberitahuan, dan dapat menyatakan tingkat permintaan yang diinginkan (permintaan per menit). Target pengiriman akan merespons dengan pernyataan izin dan tingkat permintaan yang diizinkan. Berikut adalah beberapa bidang header untuk dimasukkan dalam permintaan validasi.

WebHook-Request-Origin

Header WebHook-Request-Origin HARUS disertakan dalam permintaan validasi dan meminta izin untuk mengirim pemberitahuan dari pengirim ini, dan berisi ekspresi Sistem Nama Domain (DNS) yang mengidentifikasi sistem pengiriman, misalnya eventemitter.example.com. Nilai dimaksudkan untuk secara ringkas mengidentifikasi semua instans pengirim yang bertindak atas nama sistem tertentu, dan bukan host individu.

Setelah jabat tangan dan jika izin diberikan, pengirim HARUS menggunakan Origin header permintaan untuk setiap permintaan pengiriman, dengan nilai yang cocok dengan header ini.

Contoh:

WebHook-Request-Origin: eventemitter.example.com

Respons validasi

Jika dan hanya jika target pengiriman memungkinkan pengiriman peristiwa, target harus membalas permintaan dengan menyertakan WebHook-Allowed-Origin header dan WebHook-Allowed-Rate . Jika target pengiriman memilih untuk memberikan izin dengan panggilan balik, target akan menahan header respons.

Jika target pengiriman tidak mengizinkan pengiriman peristiwa atau tidak mengharapkan pengiriman peristiwa dan bagaimanapun menangani metode HTTP OPTIONS, respons yang ada seharusnya tidak ditafsirkan sebagai persetujuan, dan oleh karena itu jabat tangan tidak dapat mengandalkan kode status. Jika target pengiriman sebaliknya tidak menangani metode HTTP OPTIONS, itu HARUS merespons dengan kode status HTTP 405, seolah-olah OPTIONS tidak didukung.

Respons OPTIONS HARUS menyertakan header yang Allow menunjukkan metode POST yang diizinkan. Metode lain DAPAT diizinkan pada sumber daya, tetapi fungsinya berada di luar cakupan spesifikasi ini.

WebHook-Allowed-Origin

Header WebHook-Allowed-Origin HARUS dikembalikan ketika target pengiriman setuju untuk pengiriman pemberitahuan oleh layanan asal. Nilainya HARUS berupa nama asal yang disediakan di WebHook-Request-Origin header, atau karakter tanda bintang tunggal ('*'), yang menunjukkan bahwa target pengiriman mendukung pemberitahuan dari semua asal.

WebHook-Allowed-Origin: eventemitter.example.com

Atau

WebHook-Request-Origin: *

Penting

Untuk informasi selengkapnya tentang perlindungan penyalahgunaan, lihat Perlindungan penyalahgunaan di HTTP 1.1 Web Hooks untuk spesifikasi pengiriman peristiwa.

Konten terkait

Lihat artikel berikut ini untuk mempelajari cara memecahkan masalah validasi langganan peristiwa: Memecahkan masalah validasi langganan peristiwa.