Самая частая проблема — Id ресурса генерирует сервер в ответ на запрос Post, если говорить о http apu. External ID — костыль для обхода этого факта.
Не совсем согласен с такой постановкой вопроса — internal_id и external_id решают разные задачи. Internal_id должен больше удовлетворять потребностям самой системы, где создается, external_id — потребителям API. У нас была интеграция, где сервис вынуждал нас генерировать internal_id на нашей стороне, предоставив в документации алгоритм генерации — это неудобно + это распыляет бизнес логику системы на внешних потребителей. Если представить, что internal_id используется, например, для шардинга данных в базе, то мы не сможем сменить логику генерации\шардинга не затронув потребителей API, которые поддержали генерацию id на своей стороне. Текстовый external_id — лучший выбор для потребителя, захочет — положит туда uuid в строковом представлении, а захочет — человекочитаемую альтернативу.
По-моему первый пункт, это про тех, кто документацию не прочитал. И никогда тут проблем не возникало
Проблемы возникают тогда, когда у нас нет возможности однозначно идентифицировать созданный нами объект во внешней системе, но есть возможность создать такой же. В таких кейсах, если external_id обеспечивает уникальность только определенное время, мы вынуждены сохранять на своей стороне timestamp первой попытки создания (перед отправкой запроса), а в случае отвала, при последующих попытках проверять находимся ли мы в интервале, когда external_id еще не превратился в тыкву. При должном невезении и проблемах в сети с такой интеграцией легко отхватить множество объектов, которые нужно обрабатывать руками через тех-поддержку.
Про защиту https сертификатом, это не совсем понял, кто и что защищает, когда методы открыты наружу.
Отправитель колбека вынуждает получателя сформировать свою подпись полученной модели и вернуть её отправителю. Если это форма защиты — то мне не понятен механизм атаки. Кажется, сейчас уже подавляющее большинство платежных систем интегрируются исключительно по https, на ваш взгляд, этого не достаточно, чтобы идентифицировать получателя колбека?
сервер ничего не отвечает, если не проходит формальная проверка (mime не тот, авторизация не прошла и т.п.). Просто игнорирует
А можете чуть подробнее? Как именно «игнорирует»? 404, 408?
по-моему любые платежные данные запрещено сохранять в транзитной системе в любом виде, аудит не пройдет
Да, интересный вопрос, как эта неназванная платежная система проходила аудит.
А если такая необходимость сохранять подобные данные все таки есть, то система не должна хранить ключ для дешифровки данных
В этом ведь и суть: платежная система отдавала интегратору хэш номера карты как её идентификатор для дальнейшего использования, ну и маскированный номер, до кучи.
Подписать контент коллбека — более чем уместно. Передавать в ответе свою подпись этого контента, на мой взгляд, несколько избыточно. Если злоумышленник смог скомпрометировать подпись отправителя, модифицировал контент и заставил получателя считать, что коллбек достоверный, то он вполне сможет при взаимодействии с отправителем эмулировать, например, отвал по таймауту — это даст получателю время на обработку подмененных данных. Я не встречал сервисов, где факт отвала по таймауту при получении коллбека был бы достаточным основанием, например, для блокировки транзакции, о которой передается уведомление.
Не совсем согласен с такой постановкой вопроса — internal_id и external_id решают разные задачи. Internal_id должен больше удовлетворять потребностям самой системы, где создается, external_id — потребителям API. У нас была интеграция, где сервис вынуждал нас генерировать internal_id на нашей стороне, предоставив в документации алгоритм генерации — это неудобно + это распыляет бизнес логику системы на внешних потребителей. Если представить, что internal_id используется, например, для шардинга данных в базе, то мы не сможем сменить логику генерации\шардинга не затронув потребителей API, которые поддержали генерацию id на своей стороне. Текстовый external_id — лучший выбор для потребителя, захочет — положит туда uuid в строковом представлении, а захочет — человекочитаемую альтернативу.
Проблемы возникают тогда, когда у нас нет возможности однозначно идентифицировать созданный нами объект во внешней системе, но есть возможность создать такой же. В таких кейсах, если external_id обеспечивает уникальность только определенное время, мы вынуждены сохранять на своей стороне timestamp первой попытки создания (перед отправкой запроса), а в случае отвала, при последующих попытках проверять находимся ли мы в интервале, когда external_id еще не превратился в тыкву. При должном невезении и проблемах в сети с такой интеграцией легко отхватить множество объектов, которые нужно обрабатывать руками через тех-поддержку.
Отправитель колбека вынуждает получателя сформировать свою подпись полученной модели и вернуть её отправителю. Если это форма защиты — то мне не понятен механизм атаки. Кажется, сейчас уже подавляющее большинство платежных систем интегрируются исключительно по https, на ваш взгляд, этого не достаточно, чтобы идентифицировать получателя колбека?
А можете чуть подробнее? Как именно «игнорирует»? 404, 408?
Да, интересный вопрос, как эта неназванная платежная система проходила аудит.
В этом ведь и суть: платежная система отдавала интегратору хэш номера карты как её идентификатор для дальнейшего использования, ну и маскированный номер, до кучи.