Что использовать в качестве полезной нагрузки для разработчиков в Google In-App Billing API?

Question

В учебном классе по продаже встроенных в Android продуктов предлагается использовать полезную нагрузку при оформлении запроса на покупку:

Пятый аргумент содержит строку "Полезная нагрузка разработчика", которую вы можете использовать для отправки дополнительной информации о заказе (это может быть пустая строка). Как правило, это используется для передачи строкового токена, который однозначно идентифицирует этот запрос на покупку. Если вы укажете строковое значение, Google Play вернет эту строку вместе с ответом на покупку. Впоследствии, когда вы делаете запросы об этой покупке, Google Play возвращает эту строку вместе с информацией о покупке.

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

На странице " Реализация покупки IAB" есть аналогичная рекомендация с дополнительным предложением проверить значение полезной нагрузки на вашем собственном безопасном сервере:

Рекомендация по безопасности. Когда вы отправляете запрос на покупку, создайте токен String, который однозначно идентифицирует этот запрос на покупку, и включите этот токен в developerPayload. В качестве токена можно использовать случайно сгенерированную строку. Получив ответ о покупке из Google Play, обязательно проверьте подпись возвращаемых данных, идентификатор заказа и строку developerPayload. Для дополнительной безопасности вы должны выполнить проверку на своем собственном защищенном сервере. Убедитесь, что orderId является уникальным значением, которое вы ранее не обрабатывали, и строка developerPayload соответствует токену, который вы отправили ранее, с запросом на покупку.

Глядя на исходный код приложения Trivial Drive, которое Google использует для демонстрации API, я обнаружил следующее предупреждение:

* WARNING: Locally generating a random string when starting a purchase and
* verifying it here might seem like a good approach, but this will fail in the
* case where the user purchases an item on one device and then uses your app on
* a different device, because on the other device you will not have access to the
* random string you originally generated.
*
* So a good developer payload has these characteristics:
*
* 1. If two different users purchase an item, the payload is different between them,
*    so that one user's purchase can't be replayed to another user.
*
* 2. The payload must be such that you can verify it even when the app wasn't the
*    one who initiated the purchase flow (so that items purchased by the user on
*    one device work on other devices owned by the user).
*
* Using your own server to store and verify developer payloads across app
* installations is recommended.

Поэтому из всех этих сообщений звучит как плохая идея использовать случайное число / строку для полезной нагрузки. Кроме того, после прочтения последнего предупреждения звучит плохая идея передавать идентификатор устройства в качестве полезной нагрузки, поскольку он будет отличаться для одного и того же пользователя на разных устройствах. Так что же следует использовать для полезной нагрузки разработчика?

Мое приложение предоставляет локальные функциональные возможности, к которым пользователь может получить доступ без необходимости входа в какую-либо службу. Таким образом, нет понятия "пользователь", и нет компонента на стороне сервера. Запрос на покупку в приложении предназначен для обновления, которое удаляет рекламу из приложения. Имеет ли смысл для приложения, подобного этому, использовать функцию полезной нагрузки, или мне лучше просто использовать для нее пустую строку и оставить ее подверженной повторным атакам?

Answer 1

Мои знания о покупке InApp получены из более старой библиотеки v2. Я не работал с новейшей версией 3. Тем не менее, надеюсь, я все еще могу быть полезным.

Да, использование полезной нагрузки разработчика в качестве дополнительной функции безопасности, безусловно, поможет, однако, стоит вам или нет, вероятно, более субъективно, чем объективная дилемма. В моем случае в моем клиенте уже был сервер, так как после покупки через приложение клиенты должны загружать 200 МБ файлов. Мы использовали полезную нагрузку разработчика для хранения информации о файле, разрешенном для загрузки. Эта информация имела решающее значение в сообщении приложению, как обрабатывать загруженные файлы.

Мы по-прежнему обеспечили дополнительную безопасность, переопределив местный verifyPurchase() метод с вызовом сервера. IE, предоставляя наш собственный nonce для проверки. Делать это локально не очень безопасно.

Что касается вашей ситуации, я говорю, что это вопрос риска против стоимости. Каков риск того, что ваше приложение будет взломано и клиенты будут обходить покупки по сравнению со стоимостью внедрения дополнительной безопасности. Если ваше приложение загружается более 100000 раз, у вас есть достаточный риск. Если более 1 миллиона раз, тогда существует высокий риск. Если только несколько тысяч, то пиратство, вероятно, пропустит ваше приложение. Если вы выбираете дополнительную безопасность, вам нужно настроить и запустить сервер, а затем добавить весь код и подтверждение связи, необходимые для приложения и сервера. Все это потребует времени и денег. Особенно в оплате за сервер в течение срока службы вашего приложения.