برای یک وبهوک ردیاب، اصالت پیام و مدیریت بازپخش را با استفاده از مکانیزم واقعی ارائهدهنده تأیید کنید. دریافت JSON یا نام آشنای رویداد، بهتنهایی اصالت پیام را ثابت نمی‌کند.
از روش تأیید پشتیبانی‌شده استفاده کنید
در صورت ارائه، الزامات امضای مستند یا احراز هویت را دنبال کنید. سرآیند امضا را اختراع نکنید یا فرض نکنید که فقط HTTPS منبع پیام را حل میکند.
پردازش رویداد را محدود کنید
از شناسه‌ها و زمان‌نشان‌های مستند برای مدیریت تکرار یا بازپخش استفاده کنید. اطلاعات محرمانهٔ دسترسی را محافظت کنید و فقط یک اتصال نرم‌افزاری مجاز را آزمایش کنید.
| موضوع بررسی | مدرک یا دادهٔ لازم | کاربرد در تصمیم |
|---|---|---|
| منبع | تأیید مستند | رد فرضیات غیر پشتیبانی‌شده |
| رویداد | شناسه و معنی | اعتبارسنجی قرارداد |
| بازپخش | قانون تازگی یا حذف تکراری پشتیبانی‌شده | ثبت محدودیت‌ها |
| راز | ذخیره‌سازی تأیید‌شده | در خارج از لاگ‌ها نگه دارید |
خانهٔ خالی در این کاربرگ، سؤال بی‌پاسخ است؛ آن را نتیجهٔ مثبت یا منفی فرض نکنید. مدرک موجود را از ادعا و فرض جدا نگه دارید.
یک مثال فرضی
فرض کنید همان رویداد تأیید‌شده دوباره تحویل داده شود. تأیید و مدیریت تکرار بررسی‌های جداگانهای باقی می‌مانند.
امضای معتبر و جلوگیری از بازپخش را جدا بررسی کنید
روش احراز، معنای شناسه و قاعدهٔ تازگی را از مستندات همان اتصال بگیرید. اعتبارسنجی را با دادهٔ آزمایشی مجاز انجام دهید و رازها را در نمونه، لاگ یا مرورگر قرار ندهید. این مثال وجود وبهوک یا نام سرآیند امضای رهگارد را تأیید نمی‌کند.
مطالعهٔ تکمیلی: کلید API ردیاب را کجا نگه داریم؟ مرورگر جای راز سازمانی نیست و رویداد تکراری در اتصال ردیاب؛ پردازش idempotent چه کمکی میکند؟.
برای بررسی دستگاه و مسیر رسمی خدمات، به رهگارد و فروشگاه ردیاب خودرو مراجعه کنید؛ امکانات و شرایط همان مدل را پیش از سفارش تأیید کنید.
هنوز دیدگاهی ثبت نشده. اولین نفر باشید!