Комментарии 4
Как утверждает документация на сайте Apple, нам достаточно проверить только поле status с присланного нам json.
Ничего подобного документация не утверждает. Задача сервера сводится к проверке, что рецепт был подписан самим эпплом, и возврату этого рецепта в json.
Вы никакой информации на сервер о принадлежности этого рецепта не передаёте. Откуда ему знать ваш это был рецепт или нет?
Естественно, проверка соответствия bundle_id лежит на вашей совести, как и всех остальных параметров.
если вы в своей базе данных найдете идентичное значение этого поля — то это фрод
Или просто у вас очень преданный пользователь и он совершил вторую покупку. Предыдущая покупка из рецепта никуда не исчезнет.
Под рецептом я имею ввиду receipt, конечно, который на самом деле никакой не рецепт, а вовсе даже квитанция, просто я привык его так называть :)
Ничего подобного документация не утверждает. Задача сервера сводится к проверке, что рецепт был подписан самим эпплом, и возврату этого рецепта в json.
Вы никакой информации на сервер о принадлежности этого рецепта не передаёте. Откуда ему знать ваш это был рецепт или нет?
Я согласен с вашим утверждением. Apple проверяет подписан ли ими receipt. Однако большинство разработчиков не учитывают тот факт, что нужно проверять другие поля и проверяют исключительно лишь поле status. Я написал это чтобы подчеркнуть другим разработчикам проверять и остальные поля, так как сам ранее не учитывал этот момент и следствием этого стало то, что в нашей игре могли купить нашу валюту с помощью ложных транзакций.
Или просто у вас очень преданный пользователь и он совершил вторую покупку. Предыдущая покупка из рецепта никуда не исчезнет.
Мы тестировали на реальных in-app purchase в игре с одного и того же устройства, и поле original_transaction_id было всегда разное (оно уникальное).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защита in-App Purchase iOS от ломалок с помощю сервера