Защита in-App Purchase iOS от ломалок с помощю сервера

[sadsanta]

Как утверждает документация на сайте Apple, нам достаточно проверить только поле status с присланного нам json.

Ничего подобного документация не утверждает. Задача сервера сводится к проверке, что рецепт был подписан самим эпплом, и возврату этого рецепта в json.
Вы никакой информации на сервер о принадлежности этого рецепта не передаёте. Откуда ему знать ваш это был рецепт или нет?

Естественно, проверка соответствия bundle_id лежит на вашей совести, как и всех остальных параметров.

если вы в своей базе данных найдете идентичное значение этого поля — то это фрод

Или просто у вас очень преданный пользователь и он совершил вторую покупку. Предыдущая покупка из рецепта никуда не исчезнет.

[sadsanta]

Под рецептом я имею ввиду receipt, конечно, который на самом деле никакой не рецепт, а вовсе даже квитанция, просто я привык его так называть :)

[VGaldemar]

Ничего подобного документация не утверждает. Задача сервера сводится к проверке, что рецепт был подписан самим эпплом, и возврату этого рецепта в json.
Вы никакой информации на сервер о принадлежности этого рецепта не передаёте. Откуда ему знать ваш это был рецепт или нет?

Я согласен с вашим утверждением. Apple проверяет подписан ли ими receipt. Однако большинство разработчиков не учитывают тот факт, что нужно проверять другие поля и проверяют исключительно лишь поле status. Я написал это чтобы подчеркнуть другим разработчикам проверять и остальные поля, так как сам ранее не учитывал этот момент и следствием этого стало то, что в нашей игре могли купить нашу валюту с помощью ложных транзакций.

Или просто у вас очень преданный пользователь и он совершил вторую покупку. Предыдущая покупка из рецепта никуда не исчезнет.

Мы тестировали на реальных in-app purchase в игре с одного и того же устройства, и поле original_transaction_id было всегда разное (оно уникальное).

[mefikru]

Более развернуто