Понимание того, как подписываются события Stripe Webhook
Подписка на события веб-перехватчика Stripe, чтобы получать уведомления о платежах? После реализации вашего кода пришло время убедиться, что он работает идеально, связав его с некоторыми тестовыми примерами. В этой статье я напишу о том, почему тестирование обработчиков веб-хуков Stripe требует особого внимания и как их тестировать.
Эта статья написана независимо от языка. Это должно быть применимо к любым языкам программирования или платформам.
Понимание того, почему тестирование обработчиков веб-хуков Stripe отличается
Я делю вебхуки на две категории: безопасные и небезопасные.
Для небезопасных веб-перехватчиков события отправляются сторонними провайдерами, не давая нам возможности проверить подлинность событий, что, по сути, делает нас уязвимыми для различных атак (атака повторного воспроизведения, атака спуфинга).
Чтобы смягчить проблемы безопасности с небезопасными веб-перехватчиками, сторонние поставщики услуг применяют различные стратегии, позволяющие нам (интеграторам услуг) проверять подлинность полученных событий веб-перехватчиков, которые я классифицирую как безопасные веб-перехватчики. В случае Stripe, по крайней мере, с версией API 2019–03–14, все события веб-перехватчиков подписываются симметричным ключом, известным как Секрет конечной точки.
Вы, наверное, видели примеры кода, предоставленные Stripe, демонстрирующие, как проверять подлинность событий в их документации Проверка подписи веб-перехватчика.
Чтобы протестировать обработчики веб-перехватчиков, вполне вероятно, что вы имитируете события веб-перехватчиков и отправляете их своим обработчикам, как если бы Stripe делала это в производственной среде. Чтобы гарантировать, что «законное» событие веб-перехватчика Stripe может быть создано для целей тестирования, крайне важно понять, как Stripe подписывает полезные данные веб-перехватчика.
Понимание того, как Stripe подписывает полезные нагрузки Webhook
Как я уже упоминал, при реализации обработчиков веб-хуков мы должны иметь возможность проверять подлинность получаемых событий. Для этого Stripe использует следующий алгоритм при отправке события:
Во-первых, подпись генерируется из текущего времени и полезной нагрузки и подписывается с помощью симметричного ключа (секрет конечной точки Stripe) с использованием HCMA SHA256:
Совет. Я не рекомендую использовать настоящие секреты конечной точки в тестовой среде. Учитывая тот факт, что мы предоставляем секрет конечной точки нашим обработчикам веб-перехватчиков, использование любой случайной строки должно работать
Во-вторых, подпись объединяется с отметкой времени и передается как значение заголовка HTTP Stripe-Signature:
Как только вы поймете, как Stripe подписывает свои события веб-перехватчика, вы можете начать писать несколько тестовых примеров.
Совет. Библиотеки Stripe поставляются с закрытым методом для создания подписей. Изучение исходного кода должно дать вам хорошее представление о том, как реализовать генерацию подписи с помощью выбранного вами языка программирования
Получение примеров событий веб-перехватчика из Stripe
На панели инструментов Stripe вы должны иметь доступ к функции «Отправить тестовый веб-хук» при настройке конечных точек. Эта функция имитирует реальную полезную нагрузку, которую отправляет Stripe, но вместо этого использует поддельные данные. Используя образцы полезной нагрузки с панели управления, я создал PayloadFactory, который генерирует настраиваемые события веб-перехватчика для имитации различных реальных сценариев.
Со всеми ингредиентами и правильным рецептом вы сможете протестировать обработчики веб-перехватчиков, имитируя реальный сценарий.
Бонус: проблема доверия с событиями Webhook
При прослушивании событий веб-перехватчиков мы доверяем поставщику услуг отправлять нам подлинные и законные данные. События веб-перехватчика считаются надежными, когда мы можем проверить подлинность полезной нагрузки. Однако для поставщиков услуг, которые не предоставляют такой возможности, которые я называю этими веб-перехватчиками небезопасными, означает ли это, что мы не должны использовать их веб-перехватчики?
Ответ варьируется. Если интеграция с веб-перехватчиками — единственный вариант для поддержки наших бизнес-требований, у нас нет выбора. В этом случае я рекомендую НЕ полагаться на какие-либо полезные нагрузки событий. Да, вы не ослышались!
В случае использования веб-перехватчиков, не прошедших проверку подлинности, мы прослушиваем возникновение событий. Если произошло событие, и поставщик услуг уведомил нас, мы должны использовать первичный идентификатор (любой идентификатор), предоставленный в полезной нагрузке, чтобы повторно запросить фактическое состояние/данные у нашего поставщика услуг. Тем самым мы исключаем возможность любых потенциальных спуфинговых атак.
А как насчет Stripe Webhook? Теперь вы спрашиваете, имея возможность проверять подлинность событий веб-перехватчика и тот факт, что подпись генерируется из полезной нагрузки события, мы можем быть уверены в получаемых нами событиях. Конечно, это не применимо, если секрет нашей конечной точки раскрыт 😅
Я надеюсь, что эта статья поможет! Не стесняйтесь поделиться им с друзьями 🤗 Это не аффилированный пост. Я приветствую любые конструктивные отзывы.
Первоначально опубликовано на https://melvinkoh.me.
